Разоблачение шести мифов о гибкой разработке продукта

Организации применяют agile подход по многим причинам:

  • одни надеются на повышение производительности и сокращение времени выхода на рынок;
  • другие для более успешных продуктов;
  • третьи применяют agile, чтобы расширить сотрудничество между разработчиками и бизнес людьми, улучшить качество или повысить удовлетворенность работой команды.

И, конечно же, многие организации используют agile в надежде достичь некоторого сочетания этих преимуществ, однако, преимуществ столько же, сколько ошибок.

Это интригующий миф, потому что scrum является старейшим agile подходом, истоки scrum лежат в разработке физических продуктов. Некоторыми из оригинальных проектов по scrum были фотокопировальные машины, автомобиль Honda и фото-камеры.

Agile в наши дни используется для всех форм разработки продуктов, от физических продуктов до облачных решений. Помимо продуктовой разработки, agile успешно используют:

  • маркетинговые команды для планирования и проведения кампаний;
  • адвокаты для управления делами и рабочей нагрузкой;
  • команды по организационной трансформации, в частности при переходе на agile;
  • команды руководителей для управления своими организациями;
  • семьи для улучшения времени, которое они проводят вместе;
  • пары при планировании свадьбы.

Любой проект с высокой степенью уникальности (вы не делали это раньше раз так десять) и сложности хорошо подходит для применения agile подходов.

Если вас смущает отсылка к программному обеспечению в опубликованных документах, таких как Agile Manifesto, просто замените на слово «продукты». Замените, например, рабочее программное обеспечение на рабочие продукты и прочитайте еще раз: Рабочие продукты, важнее исчерпывающей документации. Это идеально подходит. Почему? Потому что agile работает со всеми видами продуктов, программное обеспечение является лишь одним из них.

Данный миф существует, потому что большинство менеджеров тратит много времени на те вещи, которые они не должны делать, в agile они или нет. Например, менеджеры часто работают на уровне назначения задач конкретным людям. Когда менеджеры узнают что это то, что они не должны делать в agile им кажется, что у них не осталось работы.

Нет: часть работы не была забрана. Такие активности, как назначение задач конкретным людям никогда не должна быть самой важной частью работы менеджера

Менеджеры должны быть сфокусированы на создании среды и культуры, которые необходимы команде для развития. Их время не должно расходоваться на такие мелочи, как кто будет работать над какой задачей.

Питер Друкер — ведущий теоретик 20-го века в менеджменте, наиболее известный идеей управления по целям и созданием аббревиатуры SMART для постановки целей (цель должна быть конкретной, измеримой, достижимой, значимой и привязанной ко времени), сказал, что у менеджеров есть пять видов обязанностей:
1) постановка целей;
2) организация людей и работы;
3) мотивация и коммуникация;
4) измерение;
5) развитие людей

Конечно, в некоторых компаниях некоторые из обязанностей уменьшены, однако, развитие людей — может быть крайне важной обязанностью менеджера.

За многие годы существования agile ни одна из компаний не принимала решения об увольнении всех менеджеров. Да, некоторые менеджеры стали scrum-мастерами, некоторые Владельцами продуктов, тем не менее в agile есть место для менеджеров.

Не удивительно, что в данный миф больше всех верят сами стэйкхолдеры.
Команда разработки понимает, что внесение изменений в неподходящее время обходится дорого.

Давайте рассмотрим ситуацию с заказом еды в ресторане

Вы говорите официанту, что хотите курицу. Затем сразу же говорите, «Нет, лучше лосося». В данном случае изменение вам ничего не стоит.

Однако, если вы измените своё мнение позже, это будет вам чего-то стоит. Если вы скажите официанту, что хотели бы лосося вместо курицы после того, как кухня уже начала готовить, это будет стоить приготовленного впустую блюда (за которое ресторан может вас попросить расплатиться)

Стоимость становится более очевидной, если вы съедите половину курицы до того, как скажите официанту, что хотели бы вместо курицы лосося.

Изменения, которые стэкхолдер вносит в спринт схожи с изменением блюда на ужин. Если изменения внесены в правильное время, то стоимость изменения будет маленькой или её вообще не будет. Однако, если это произошло в неверное время — стоимость будет высокой.

Быть agile не означает убрать всю стоимость изменений, которые вносят стэкхолдеры, однако, хорошие agile команды могут снизить стоимость таких изменений.

Для этого у команд:

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

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

Участник agile команды должен быть способен делать всё — самый популярный миф об agile командах.

Этот миф подразумевает, что если вы наняли величайшего в мире администратора баз данных Oracle, вы хотите, чтобы этот администратор баз данных был также замечательным Java разработчиком. И ваш удивительный Java разработчик должен быть полностью опытным в тестировании на случай, если в одном спринте не требуется много Java разработки.

Это абсолютно не так.

Agile командам не надо, чтобы каждый обладал всеми компетенциями, командам нужно, чтобы ценили тех, кто обладает несколькими компетенциями.

Чтобы понять ложность этого мифа, давайте рассмотрим пример с модным рестораном

В ресторане есть Шеф-кондитер, который умеет делать выпечку, десерты, хлеб и другие хлебобулочные изделия. Его роль звучит как высококвалифицированная, но специализированная. Другой специализированной ролью на кухне может быть Соусье́, который отвечает за соусы, за всё, что подается с соусом, также за тушение и обжарку в соусах.
На хорошо организованной кухне было бы неплохо, если бы Шеф-кондитер мог помочь Соусье́, возможно, нарезав немного лука, но ни Шеф-кондитер, ни Соусье́, не способны полностью выполнять работу друг друга.

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

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

Баланс может быть достигнут в большинстве команд, даже если несколько её участников владеют только одной компетенцией.

Большинство хороших agile команд планируют, однако, это планирование часто менее заметно, чем у команд с традиционными проектами, т. к. у agile команд отсутствует предварительная фаза планирования. Вместо этого хорошие agile команды проводят планирование как серию небольших повторяющихся действий, которые гарантируют, что их планы всегда отражают реалии текущей ситуации. Таким образом, команды разрабатывают планы так же, как они разрабатывают продукты: путем инспекции и адаптации.

Любая agile команда планирует на тот горизонт, который необходим для принятия важного решения.

На самом деле, несмотря на этот миф, agile командам проще создавать надежные планы, потому что она знает насколько быстро производит продукт.

Рассмотрим традиционную команду с этапами анализа, дизайна, проектирования, написания кода и тестирования. Если повезет, эта команда может отложить принятие плана до конца этапа дизайна и проектирования. Однако и в тот момент эта команда не будет знать, насколько быстро она будет писать код и тестировать, т. к. она еще не выполняли ни одного из этих действий.

В отличие от традиционных команд, agile команда проделывает все процессы разработки каждый спринт. Каждый спринт включает в себя немного анализа, дизайна, проектирования, написания кода и тестирование. Такой подход помогает понять как быстро команда превращает идею в новую функциональность.

Пришло время разоблачить последний миф: миф о том, что agile команда не создаёт архитектуру и дизайн своего продукта.

Agile команда определенно создаёт архитектуру и дизайн своего продукта и это происходит инкрементально. Такой подход позволяет команде инспектировать и адаптировать архитектуру и дизайн, для того, чтобы они стали самыми лучшими.

Это означает, что нет предварительной фазы, во время которой принимаются все архитектурные решения. Вместо этого архитектура продукта появляется со временем.

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

Архитектура не просто появляется в один день, она появляется постепенно и управляется командой, чаще участниками команды с необходимыми архитектурными компетенциями.

Это означает, что при гибкой разработке у продукта есть базовая архитектура, которая в дальнейшем разрабатывается по мере развития продукта. Архитектура не разрабатывается полностью до начала создания продукта.

Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted

Первая публикация перевода: http://kanban.club/all/razoblachenie-shesti-mifov-o-gibkoy-razrabotke-produktov/

Partner & AgileCoach @ScrumTrek Certified coach & mentor ICF

Partner & AgileCoach @ScrumTrek Certified coach & mentor ICF