Стандартная Agile-практика не для стартапов

Почему обычные Agile-процессы, такие как Scrum и Extreme Programming, могут заставить стартапы сосредоточиться не на том, что им действительно необходимо?

Когда большинство людей думают об обычной Agile-практике сегодня, они думают о гибриде Scrum/Extreme Programming. Это происходит примерно так:

1. Владелец продукта создает бэклог пользовательских историй, описывающих ваш минимально жизнеспособный продукт — наименьший продукт, который, по вашему мнению, будет успешным на рынке (истории пришли из Extreme Programming, бэклоги из Scrum).

2. Приоритизируется бэклог с наивысшим приоритетом в первую очередь (что сложно, потому что нам нужно все это, по крайней мере, мы почти уверены, что делаем это).

3. Используется сеанс планирования спринта, чтобы спланировать детали работы на две недели (но мы безнадежно оптимистичны, поэтому часто завышаем план до трех недель и более).

4. Затем начинается двухнедельный спринт (название Scrum для ограниченного по времени цикла разработки, который может длиться от одной недели до четырех).

5. Каждый день проводится совещание (которое на самом деле похоже на отчет о состоянии для людей, которые испытывают стресс из-за того, что разработка продвигается недостаточно быстро).

6. Каждый день перемещаются стикеры по доске задач (которая больше похожа на доску Канбан).

7. Используются какой-нибудь инструмент отслеживания, чтобы отслеживать невыполненную работу и прогресс (и показывать диаграммы выгорания, которые по какой-то причине люди очень не любят создавать вручную).

8. Используются строгая приемка, такая как разработка через тестирование, автоматические приемочные тесты и непрерывная интеграция (но откажитесь от этого, когда кажется, что мы не успеем все сделать вовремя).

9. Когда истории заканчиваются, тестер тщательно тестирует их, а владелец продукта просматривает их (но обычно мы передаем кучу готовых историй тестировщику в последний день спринта и говорим ему протестировать все это, а затем смотрим на тестировщика).

10. В конце 2-х недель остановится и проведят обзор спринта, где мы кратко покажем, что мы сделали, и размышляем над тем, как мы могли бы улучшить (но мы тратим много времени на споры о том, действительно ли все сделано «сделано-сделано», потому что нам нужна высокая скорость, а потом мы оправдываемся, почему мы не смогли выполнить 3 недели работы за 2 недели).

Повторяйте шаги 2-10, пока не закончите или не закончатся деньги, в зависимости от того, что наступит раньше. Такое наше резюме этой технологии.

Но процесс – это не навык.

Понять процесс — это не то же самое, что сделать его хорошо. И требуется некоторое время, чтобы развить навыки и дисциплину, необходимые для предсказуемой работы с высоким качеством. Но, к счастью, с обычным Agile-процессом, таким как Scrum, вы сможете останавливаться и размышлять о том, где вы действительно отстой, каждые пару недель, и вы увидите, что со временем это становится лучше.

Обычная практика Agile сегодня использует ограниченные по времени циклы разработки, чтобы достаточно структурировать процесс планирования работы, выполнения работы, а затем остановки для оценки и корректировки курса. Этот простой цикл выполнения использует скорость, с которой мы разрабатываем программное обеспечение, в качестве наиболее заметной метрики. И это имеет смысл, учитывая ключевые принципы Agile (упомянутые в Agile Manifesto): «Работающее программное обеспечение является основным мерилом прогресса».

Если вы собираетесь хорошо работать, вам нужно накачать свои основные Agile-мышцы.

Но весь этот акцент на скорости работы приводит людей к мысли, что это все, о чем Agile-процессы. Нельзя ждать слишком многого от технологий. Вежде нужен здравый смысл.