Что такое spike в agile
Spike
Definition of a Spike:
Spike is the name for a timeboxed user story or Task that is created in order to research a question or resolve a problem. Spikes focus on gathering information and finding answers to a questions, rather than producing a shippable product.
Synonyms for a Spike:
Proof of Concept, PoC
Use of Spikes:
A Spike is created when a user story or task cannot be estimated well enough until the team has done further research or investigation. The result of a spike is an estimate for the original user story so that the sprint can move forward.
Benefits of Spikes:
Scrum Master Trainings
Product Owner Trainings
Author
Sohrab Salimi
Scrum Academy GmbH
Sohrab is a long-standing Certified Scrum Trainer (CST) and CEO of the Scrum Academy GmbH based in Cologne. He is a trained medical doctor and worked for Bain & Company as a consultant and as a CIO at SE-Consulting, among others, before founding the Scrum Academy. As a consultant and trainer, he has been supporting companies from a wide range of industries for over a decade on topics related to agile transformation, innovation and organizational development.
Related articles
How do you implement innovation at your organisation and what does it take to really innovate? Tendayi Viki explains it at agile100
Why do some organisations fail? Alexander Osterwalder explained at the agile100 what it takes to build invincible companies!
End Leadership Mistakes and transform your agile Transformation that it works! Expert Jesse Fewell explains your difficulties while transforming!
Остров, о котором забыл Scrum
На оригинал данной статьи я наткнулся случайно, разгребая почту и наткнувшись на новостную рассылку от ScrumAlliance. Тема метрик Scrum команд и непосредственно кода, меня интересует уже давно. Особенно любопытно, что с этими метриками делать дальше, и первостепенно — зачем они вообще нужны?
В данной работе автор поднимает важнейшую тему для молодых Scrum команд — почему со временем теряется продуктивность и как сохранить ее в долгосрочной перспективе?
Cкучные предисловия я припас для своего уютного блога, а тебе хаброчитатель предлагаю ознакомиться с самой сутью.
Чтобы расширить свой кругозор, а также получить ответ на свои внутренние вопросы, добро пожаловать под кат…
The Land that Scrum Forgot
Что не так со многими Scrum проектами? Почему сначала производительность команды подскакивает, а потом начинает падать? Почему некоторые Scrum команды периодически отказываются от Scrum? Что происходит?
Как один из тех, кого позвали чтобы спасти Scrum команды от подобного отречения, я говорю вам, что проблема не в том, что команды теряют мотивацию. Часто проблема в том, что программное обеспечение, которое команды разрабатывают становится сложнее и с ним становится сложнее работать.
Scrum дает вам быстрый старт! Это отлично. Часто первые спринты сталкиваются с первыми особенностями Scrum’а. Менеджеры и заказчики счастливы. Команда работает блестяще, и она тоже счастлива. Все счастливы и видят в Scrum огромный успех.
Это повторяется в следующей и в следующем за ним спринте. Производительность высока. Система постепенно строится, а весь функционал уже работает. Ожидания созданы. Планы построены. Энтузиазм парит над Scrum. Достигнута гиперпродуктивность!
Одна из причин гиперпродуктивности это маленький размер кодовой базы. Малой кодовой базой проще управлять. Исправления легко вносить; новые функции легко добавлять.
Но код растет быстро; и когда кодовая база становится больше, ее становится тяжело поддерживать. Программисты значительно замедляются из-за ухудшения кода. Команды «сдуваются» до невозможного из-за огромного груза плохо написанной системы. Если об этом не позаботились заранее, гиперпродуктивная Scrum команда впадает в болезнь, которая убивает множество софтверных проектов. Они породили беспорядок (Прим. пер.: mess).
«Подождите!» — слышу как говорите вы. «Я думал что Scrum нужен чтобы усилить команду! Я полагал, что команда сделает все возможное, чтобы удостовериться в качестве. Я думал, что укрепленная Scrum команда не создаст бардак!»
Да, вы правы. Проблема в том, что даже укрепленная команда состоит по-прежнему из людей, и они работают за то, что им дают. Они будут награждены за качество? Или их наградят за продуктивность? Как много значимого команда получит за хорошее качество кода? Как многое они получают за поставку рабочего функционала?
Здесь нет ответа. Причина в том, что scrum команда создает беспорядок, потому что она укреплена и стимулирована его создавать. И Scrum команда может создавать его быстро, очень-очень быстро! Scrum команда гиперпродуктивна по части создания бардака. Пока вы не знаете об этом, беспорядок будет становиться «таким большим и таким глубоким, таким высоким, что вы не сможете его устранить. Выхода нет».
И когда это наступает, продуктивность падает. Мораль падает. Заказчики и менеджеры становятся злыми. Жизнь плоха.
Так как же стимулировать Scrum команду, чтобы она не делала беспорядка? Можем ли мы просто попросить не создавать его? Мы пробовали. Это не работает. Стимуляция работать быстрее основана на осязаемости результата. Но наградить команду за хороший код, если вы не знаете способа объективно оценить его, невозможно. Без однозначного способа измерить беспорядок, его нельзя прекратить создавать.
Нам нужно двигаться быстро и оставаться чистыми, при этом сохраняя скорость. Как стимулировать команду достигнуть две цели? Просто. Мы измеряем и то и другое и награждаем одинаково. Если команда двигается быстро, но работает грязно, она не получит вознаграждения. Если команда остается чистой, но двигается медленно, никакого вознаграждения. Если команда двигается быстро и сохраняет чистоту, то она поощряется!
Мы можем измерить беспорядок, внедряя инженерные дисциплины и практики, как например разработка через тесты (TDD), непрерывная интеграция (Continuous Integration), парное программирование, коллективное владение кодом и рефакторинг; т.е. инженерные практики экстремального программирования (XP).
Обычно лучше всего начать с TDD просто потому, что любая кодовая база без тестов беспорядочна, как бы чиста она не была. Это резкое заявление, но оно строго рациональное, появившееся из более старой дисциплины: бухгалтерии. Точно также как бухгалтер может ошибиться в расчетах, так и программист может допустить ошибку в программе. Так как же бухгалтеры предотвращают ошибку? Они делают все дважды.
Бухгалтеры используют двойную запись, которая является частью Международных стандартов бухгалтерской отчетности. Бухгалтеры, которые не придерживаются МСБО быстро меняют профессию или остаются на обочине. Двойная запись это простая практика повторения одной операции дважды — один раз на стороне дебета, другой на стороне кредита. Два этих значения следуют различным математическим операциям, однако в итоге их разность должна стать равна нулю. Любая отчетность, выполненная без двойной записи будет признана бухгалтерами мусором, вне зависимости от того насколько тщательно и аккуратно эта отчетность была выполнена.
TDD это аналог двойной записи только для программного обеспечения, и должна стать частью МСПГ (Международных стандартов практик программирования). Символы, которыми оперируют бухгалтера не менее важны для компаний, чем символы, которыми манипулируют программисты. Могут ли программисты тогда делать меньше работы, чем бухгалтера, чтобы обезопасить свой код?
Программисты, практикующие TDD создают большое количество автоматически тестов, которые поддерживают друг друга и являются регрессионным набором. Это то, что вы можете измерить! Измеряйте покрытие. Измеряйте число тестов. Измеряйте количество новых тестов в спринте. Измеряйте количество дефектов, о которых сообщается в каждом спринте и используйте это чтобы определить адекватность покрытия кода тестами (Прим. пер.: the test coverage).
Задача в том, чтобы повысить уверенность в наборе тестов до такого состояния, чтобы вы могли доставлять продукт (Прим. пер.: deploy the product) сразу, как набор тестов прошел. Поэтому измеряйте количество «других» тестов, которые как вы считаете необходимо проводить, и сделайте сокращение их количества приоритетным; особенно если это ручные тесты!
Набор тестов придает огромную силу. С ними вы можете осуществлять рефакторинги без страха. Вы можете вносить изменения в код без опасения сломать его. Если кто-то видит что что-либо неочевидно или выглядит грязно, он может исправить это без опасения неожиданных последствий.
Недокументированные системы, или системы, где документация не актуализирована в соответствии с продуктовым кодом (Прим. пер.: production code) беспорядочны. Модульные тесты, получаемые в ходе TDD являются документами, описывающими низкоуровневую архитектуру системы. Каждый программист, которому требуется знать как так или иная часть системы работает, может полагаться на чтение тестов, как на однозначное точное описание. Эти документы никогда не потеряют актуальность, до тех пор пока они отрабатывают.
Измеряйте размер тестов. Тестовые методы должны быть от пять до двадцати строк кода. Общее количество тестового кода должно быть примерно равно количеству продуктового кода.
Измеряйте скорость тестов. Тесты должны отрабатывать быстро; минуты, а не часы. Поощряйте за быстрые тесты.
Измеряйте хрупкость тестов (Прим. пер.: test breakage). Тесты должны быть разработаны таким образом, чтобы изменения в продуктовом коде приводили к небольшим поломкам тестов. Если большая часть тестов падает, когда изменяется продуктовый код, то тесты требуют рефакторинга (Прим. пер. test design needs improving).
Измеряйте Цикломатическую сложность. Функции, которые очень сложны (например, cc > 6 или близко к этому) должны быть подвергнуты рефакторингу. Используйте средства наподобие Crap4J, чтобы определить методы и функции, нарушающие это правило и имеющие наименьшее покрытие тестами.
Измеряйте размер функций и классов. Средняя функция должна иметь менее 10 строк кода. Функции длиннее 20 строк надо разбивать. Классы более 500 строк следует разбивать на два и более классов. Измеряйте корреляцию Брейтвэйта, она должна иметь значение более 2.
Измеряйте метрики зависимостей. Убедитесь, что нет циклических зависимостей. Убеждайтесь, что поток зависимостей идет в направлении абстрагирования, в соответствии с принципом обращения зависимостей и принципом стабильных абстракций (Прим. Принцип стабильных абстракций: пакеты, которые максимально неизменчивы, должны быть максимально абстрактными. Изменчивые пакеты должны быть конкретными. Абстрагированность пакета должна быть пропорциональна его изменчивости.).
Используйте средства статического анализа как FindBugs или Checksty, чтобы определить очевидные слабые места. Эти средства позволяют также находить и измерять количество дублируемого кода.
Внедрите непрерывную интеграцию. Настройте билд-сервер наподобие Hudson, Team City или Bamboo. Пусть сервер собирает систему каждый раз, когда разработчик добавляет код (Прим. пер.: commits some code). Прогоняйте все тесты на этой сборке и устраняйте неисправности непременно.
Подсчитывайте количество комитов в день. Это число должно быть больше, чем число разработчиков в команде. Поощряйте частые комиты.
Подсчитывайте число дней в которые сборки упали в этом месяце. Поощряйте за месяцы без падений. Измеряйте время, пока неисправности остаются неустраненными.
Истории тестирования (Прим. пер.:Story tests) это высокоуровневые документы, разрабатываемые бизнес-аналитиками и тестировщиками. Они описывают поведение системы с точки зрения заказчика. Эти тесты, написанные с помощью средств наподобие FitNesse или Cucumber, это требования которые надо соблюдать. Когда эти тесты прошли, команда знает что она закончила истории, которые этими тестами описаны.
Измеряйте «завершенность», запуская тесты на системе непрерывной интеграции и следите за историями тестирования, которые прошли или упали. Используйте это как основу показателя производительности и прогресса команды. Внедрите правило, что user story не считается законченной, пока соответствующая история тестирования не пройдет тест, и никогда не позволяйте ломаться тестам, которые уже прошли.
Практикуйте парное программирование. Измеряйте время, потраченное в парах и время программирования в одиночку. Команды, работающие парами работают чище. Они создают меньше беспорядка. Они дополняют друг друга, т.к. знают предметные области друг друга. Они обсуждают между собой реализацию и архитектуру. Они учатся друг у друга.
А как после всех этих измерений поощрять команду? Опубликуйте огромные плакаты на стене с метриками в столовой, в кулуарах или проектной комнате. Показывайте графики заказчикам и исполнителям и кричите о сосредоточенности вашей команды на качестве и продуктивности. Организуйте вечеринки по поводу достижения milestone’ов. Выдавайте небольшие поощрения или вознаграждения. К примеру, один менеджер, которого я знал, раздавал футболки каждому в команде, когда команда прошла отметку в 1000 модульных тестов в проекте. На футболках было имя проекта и слова «1000 модульных тестов».
Как охранять Scrum команду от снижения продуктивности? Как быть уверенным в том, что гиперпродуктивность не завязнет в трясине? Убеждайтесь в том, что гиперпродуктивная команда не создает беспорядка! Убеждайтесь в том, что они используют практики, которые порождают измеримый результат. Используйте этот результат, чтобы измерять качество кода, который команда создает; и стимулируйте поддержание этого кода чистым.
46 терминов из разработки, которые нужно знать UX-дизайнеру
Может показаться, что начинать работу в IT без технического бэкграунда сложно. Так вот, это правда. Если вы, как и автор оригинальной статьи, не занимаетесь разработкой, но хотите ориентироваться в её терминах, держите от нас руку помощи. Специально для всех начинающих дизайнеров, менеджеров и маркетологов в Лайв Тайпинг и за его пределами мы перевели эту статью. Надеемся, что она избавит вас от необходимости тайком от коллег гуглить незнакомые слова.
Agile, или гибкие методологии разработки
Техника пошаговой (итеративной) разработки софта. Agile — это общий термин для нескольких видов методологий ведения проекта. Все они направлены на то, чтобы выкладывать в релиз работающие версии приложения, как только они готовы. Это помогает понять, куда должен двигаться проект, приносят ли ему пользу новые фичи и какие стоит внедрить в следующей итерации.
По agile разработка идёт циклами (итерациями) по недели. Все участники процесса могут общаться друг с другом и высказывать предложения по проекту, пользователи тоже участвуют. Короткий срок итераций позволяет выпускать обновления быстро и видеть, как они влияют на проект. Этот метод хорош, когда у владельца продукта нет окончательного видения, как он должен развиваться. И долгая непрерывная разработка всех желаемых фич не даст этого понимания.
API (программный интерфейс приложения)
Документ, который регламентирует то, как веб- и мобильные приложения обмениваются друг с другом информацией. Например, приложение ищет, какая сейчас погода в Сиднее. Для этого оно отправляет запросы к API ресурса weather.com, а weather.com присылает приложению структурированный ответ. То, в каком формате приложение обращается к ресурсу и то, в каком формате ресурс присылает ответ, определяет API.
Система управления контентом, она же «админка». В ней администратор редактирует разделы, добавляет статьи, фото товаров, удаляет спамные комментарии. С CMS одного сайта может работать несколько человек.
Data Science или «наука о данных»
Это искусство видеть тенденции в процессах, описываемых большим количеством данных. Вооружившись этими озарениями, бизнес может проверять гипотезы и принимать стратегические решения.
DevOps
Технологическое решение, с помощью которого разработчики быстро собирают проект из отдельных частей и предоставляют продукт конечным пользователям. Это решение используется в разработки, так как помогает быстро тестировать проект и давать на него обратную связь. Такая возможность улучшает сотрудничество между командой разработки и пользователями.
Как это работает? На отдельном компьютере настроен сервер сборки — программа, которая собирает проект. Как только разработчики вносят изменения в проект, сервер узнаёт об этом и начинает сборку. Затем он присылает ссылку пользователю на почту или в мессенджер, пользователь переходит по ссылке и скачивает себе проект в виде работающего приложения.
Github или Гит
Технология позволяет мобильным приложениям с минимальной погрешностью определять местоположение смартфона. Исходя из того, где находится пользователь, приложение присылает ему соответствующий контент. Маячок использует технологию Bluetooth low energy (BLE).
JavaScript, или джаваскрипт
Язык программирования, который помогает делать интерактивными. HTML отвечает за структуру страницы, CSS — за стиль элементов структуры, Javascript — за их поведение.
MVP (Минимальный жизнеспособный продукт)
NFC (Технология ближней бесконтактной связи)
Способ беспроводной передачи данных от мобильного телефона другому устройству. Системы оплаты в одно касание, такие как Apple pay, работают по этому принципу.
Open (Создание программ с открытым исходным кодом)
Подход к созданию программного обеспечения, который предполагает, что создаваемый код будет доступен любому.
(Программное обеспечение как услуга)
Принцип работы приложений, при котором пользователи взаимодействуют с ними через интернет и им не нужно скачивать и поддерживать приложения. Это освобождает пользователей от комплексного программного обеспечения и управления оборудованием. При этом приложением может пользоваться большое количество людей.
Scrum (в разработке)
Итеративный управления разработкой продукта. Главные компоненты такие:
О том, как мы в Лайв Тайпинге применили scrum в тестировании, читайте в этой статье.
SEO, или «оптимизация под поисковые системы»
Процесс, в ходе которого вы проверяете, какую из двух версий предпочтут пользователи.
Аватар
Автоматическое тестирование
Тестирование приложения программными инструментами. Тестировать помогает либо код, который проверяет функцию и который разработчик сам пишет вместе с функцией, либо специальные программы. В последнем случае тестировщик указывает в программе, какую последовательность действий ей нужно выполнить.
Адаптивный
Сайт с такой вёрсткой, которая подстраивается к разрешению экрана разных устройств. Благодаря этому пользователи могут удобно пользоваться сайтом на мобильных устройствах.
(IP Address)
Проблема, заставляющая программу зависать, закрываться или давать неверный результат. Большинство багов появляется ошибок в коде.
Бэкенд (разработка)
Ветка проекта
Часть кода, над которой разработчик работает отдельно от основного проекта. Разработка по принципу «веток» помогает программистам создавать части проекта параллельно.
Виртуальная частная сеть (VPN)
Технология, которая позволяет создавать безопасное соединение с другой сетью через интернет.
Водопад
Модель управления процессом разработки, которая подразумевает, что этапы разработки должны идти единым последовательным блоком: следующая фаза начинается только тогда, когда завершена предыдущая, и так пока проект в виде не будет завершён. Водопад противопоставляется разработки, которая предполагает, что функциональные возможности в проекте будут наращиваться постепенно, в несколько циклов разработки.
Гибридное приложение
Запросы на включение изменений в коде (Pull Requests)
Запрос, который разработчик отправляет другим участникам команды, чтобы сообщить об изменениях в коде. Pull Requests применяются в разветвлённой системе работы над проектом, с их помощью разработчик сообщает, что хочет отправить изменения в главную ветку проекта на Github из своей локальной ветки. Лидер команды разработчиков принимает Pull Requests и просматривает изменения. Если они не требуют рефакторинга, он заливает их в главную ветку.
Итерация или итеративная разработка
Каскадные таблицы стилей (CSS)
Это язык, который описывает, как элементы HTML отобразятся на экране. HTML — отвечает за структуру страницы, CSS — за стиль элементов структуры, JavaScript — за их поведение.
Коммит (подтверждение изменения кода)
Коммит — это фиксирование состояния кода. Применение коммитов связано с разветвлённой системой работы над кодом и системой контроля версий. Его применение выглядит так: разработчик делает изменение в своей ветке, потом он делает коммит — подтверждает, что он внёс изменения, код при этом хранится локально. После этого разработчик делает пуш и отправляет код на сервер.
Коммит можно сравнить с операцией Ctrl+S в любом редакторе, но это не одно и то же. После того как разработчик подтверждает коммитом изменения в коде, локально вернуть исходное состояние уже нельзя — для этого нужно возвращаться к состоянию, которое хранится на сервере. Это возможно благодаря тому, что вся история коммитов хранится в проекте — для этого они и нужны.
Место для временного хранения информации в вычислительной среде. Смысл кэша в том, что система может брать из него информацию быстрее, чем из более обширного и медленного источника. Например, компьютер хранит в кэше имя пользователя и когда последний попытается войти в систему в следующий раз, компьютер вспомнит его быстрее.
Набор средств разработки (SDK)
Программы, которые разработчики используют для создания приложений. Для конкретного устройства или операционной системы нужно использовать свои конкретные SDK.
Парное программирование
Процесс, во время которого два программиста работают вместе: один пишет код, пока другой просматривает его и затем они меняются ролями.
Программа для управления взаимоотношениями с клиентами (CRM)
Программа, которая хранит контактную информацию клиентов, такую как имена, адреса и так далее. CRM используют, чтобы фиксировать и наблюдать статистику продаж в компании, следить за этапами общения с клиентом и многим другим.
Ретроспектива
Процесс, во время которого команда анализирует прошедшую итерацию, чтобы улучшить свою работу в следующей.
Рефакторинг кода
Процесс очистки существующего кода без изменения того, как он работает. Он необходим, например, чтобы улучшить читаемость кода или чтобы упростить его структуру.
Мессенджер для общения внутри команды. Мы в Лайв Тайпинге пользуемся им.
Спайк (Spike)
Процесс создания пробной версии проекта, которая помогает оценить, сколько времени нужно на разработку готового продукта.
Спринт
Установленный период времени, в который должен быть закончен оговоренный объём работы. Обычно спринт длится недели. Спринты применяют в scrum.
Технический долг
Попробуем объяснить этот термин через пример. Разработчику нужно добавить в проект код. У него есть для этого два пути: быстрый, но «грязный», и, более «чистый», но более затратный по времени (пример взят с сайта Agile Web Operations). «Грязный» способ сделает изменения в будущем сложнее, «чистый» — даст на выходе структурированный, читаемый, легко изменяемый код. Технический долг — это дополнительное время, которое понадобится на то, чтобы привести «грязный» код к «чистому» виду. Чем больше один разработчик заливает в проект «грязного» кода, тем сложнее будет другому разработчику дорабатывать проект и тем больше будет технический долг.
Хак (Hack)
Быстрое решение, которое устраняет проблему либо не совсем правильно, либо блестяще.
Хакатон
Это мероприятие, во время которого проводит один или несколько дней за поиском инновационной идеи. Цель хакатона — развивать креативность и помогать людям думать вне рамок.
«Хлебные крошки»
Способ визуально отобразить навигацию на сайте или в приложении. Он показывает, на какой вы сейчас странице и где в иерархии сайта она находится. Этот термин связан с понятием «путь», о котором мы писали в другой нашей статье с терминами для дизайнеров.
Чат-бот
Сервис, с которым вы взаимодействуете через интерфейс чата. Такое взаимодействие похоже на переписку с другом, за исключением того, что друг — компьютер, который на ваши сообщения отвечает стандартными фразами, действиями или нужной вам информацией.
Тестирование частей приложения — модулей или юнитов — изолированно. могут быть сделаны вручную, но чаще всего они делаются автоматизировано.