Перевод оригинальной статьи Майка Кона Six Agile Product Development Myths — Busted
Организации внедряют Аджайл-подходы по многим причинам. Некоторые стремятся достичь большей производительности и сократить время поставки на рынок. Другие хотят выпускать более успешные продукты. В то же время третьи внедряют Аджайл-подходы, чтобы усилить взаимодействие между разработчиками и бизнесом, повысить качество и поднять удовлетворенность участников команды своей работой.
И, конечно, многие организации хотят быть Аджайл в надежде достичь какой-либо комбинации этих преимуществ.
Однако при том, что у Аджайл философии есть много преимуществ, похоже, что и заблуждений не меньше. В этой статье я хотел бы разрушить шесть мифов о разработке Аджайл-продуктов.
Миф №1: Аджайл предназначен только для разработки ПО.
Это любопытный миф, так как старейший подход — это Скрам, и он появился в области разработки физических продуктов. Первые проекты Скрама были связаны, к примеру, с производством копировальных аппаратов, автомобилей Honda и камер.
В настоящее время Аджайл используется для разработки любого продукта — от физических до облачных интернет-сервисов.
Но помимо разработки Продукта (как оборудования, так и программного обеспечения) Аджайл успешно применяется:
- командами маркетинга для планирования и осуществления кампаний;
- адвокатами для управления судебными делами и загрузкой;
- исполнителями организационных трансформаций, в частности, при переходе на Аджайл;
- командами высшего руководства для управления организациями;
- семьями для лучшей организации совместного проведения времени;
- парами, планирующими свадьбы.
Конечно, Аджайл можно применять и во многих других сферах. Любой проект с высокой степенью сложности и уникальности (то есть который вы не делали до этого сто раз) отлично подойдет для Аджайла-подхода. Если вас смущают упоминания «программного обеспечения» в опубликованных документах, например в Аджайл Манифесте, просто замените это словосочетание на слово Продукт. Например, рабочее программное обеспечение на рабочий Продукт и прочтите снова: [Мы ценим] рабочие Продукты больше, чем сложную документацию. Звучит лучше, не так ли? Почему? Потому что Аджайл философия работает для всех видов продуктов, а программное обеспечение — лишь один из них.
Миф №2: Менеджерам нет места в Аджайл-мире.
Думаю, это миф еще жив потому, что слишком много менеджеров тратят вревя, занимаясь вещами, которыми им не следует заниматься, независимо от того, есть Аджайл или нет.
Например, менеджеры часто спускаются до уровня назначения задач отдельным сотрудникам. А когда понимают, что в философии Аджайла им этого делать не надо, они чувствуют себя так, будто у них отняли часть работы.
Нет, никто ничего не отбирал. Назначение задач не должны быть важнейшей частью их работы.
Менеджерам нужно сосредоточиться на создании условий и атмосферы, необходимых для успеха команды. Они не должны отвлекаться на такие мелочи, как принятие решений, кто над какой задачей будет работать.
Питер Друкер был, пожалуй, ведущим теоретиком в области менеджмента в двадцатом веке. Он наиболее известен благодаря идее управления по целям (MBO) и создания акронима SMART для обозначения целей, согласно которому цель должна быть конкретной (Specific), измеримой (Measurable), достижимой (Acceptable), уместной (Realistic) и ограниченной во времени (Time-bound). Друкер выделил пять видов задач для руководителей:
- ставить цели;
- организовывать людей и работу;
- мотивировать и общаться;
- давать оценку;
- развивать людей.
Конечно, в каких-то организациях некоторые из этих обязанностей можно сократить, но другие (в частности, развитие людей) станут при этом еще важнее.
За все годы моей работы в мире Аджайла и Аджайл-организациях еще никто не принимал решения уволить всех руководителей. Да, некоторые менеджеры сменили роли и стали Скрам-мастерами или Владельцами Продуктов, но место для них все же есть.
Миф №3: Стейкхолдеры могут вносить изменения, когда захотят.
Не удивительно, что миф о том, что стейкхолдеры могут вносить изменения в любое время, когда захотят, наиболее популярен среди самих стейкхолдеров.
Участники команды разработки понимают, что введение изменений в неподходящий момент может дорого обойтись.
Представьте, что заказываете обед в ресторане. Вы говорите официанту, что хотите попробовать цыпленка. А потом сразу добавляете: «Нет, приготовьте мне лучше лосося».
В этом случае изменение ничего не стоит.
Однако все будет иначе, если вы передумаете позже. Когда вы попросите официанта заменить в вашем заказе цыпленка на лосося уже после того, как на кухне начали готовить птицу, это будет стоить цены потраченных продуктов (которую ресторан вполне может включить в ваш счет).
Стоимость становится еще более очевидной, если вы съели половину цыпленка прежде, чем сообщить официанту, что хотите вместо него лосося.
Стейкхолдер, который вносит изменение в ходе итерации, подобен посетителю ресторана, который меняет цыпленка на лосося. Если изменение вводится в нужный момент, оно может ничего не стоить или стоить мало. Если же оно вводится в неподходящий момент — у него будет соответствующая цена.
Аджайл-команда не может исключить всей стоимости, которую придется заплатить за изменения, которые вносят стейкхолдеры. Однако хорошая Аджайл-команда может снизить цену изменения, независимо от того, когда оно было внесено. Вот основные способы это сделать:
- короткие итерации;
- небольшие Элементы Бэклога Продукта;
- скорейшее завершение работы над каждым Элементом Бэклога Продукта, как правило, путем минимизации количества Элементов, одновременно находящихся в работе.
Ничего из вышесказанного не означает, что команды не должны приветствовать изменения, которые вносят стейкхолдеры. Некоторые из них могут быть очень важны. Однако пользу от каждого изменения необходимо сопоставлять с его ценой, которая не всегда равна нулю.
Миф №4: Каждый участник Аджайл-команды должен быть универсалом.
По неизвестной мне причине одним из популярных мифов об Аджайле стало то, что каждый участник команды должен уметь делать все.
Этот миф подразумевает, что если вы наняли лучшего в мире администратора баз данных Oracle, то вы хотите, чтобы он был еще и прекрасным разработчиком JavaScript. Кроме того, ваш чудесный JavaScript-разработчик должен быть еще и профессионалом в тестировании безопасности, если в какой-то итерации не надо будет много разрабатывать на JavaScript.
Это совершенно неверно.
В Аджайл-командах необязательно, чтобы каждый обладал всеми профессиональными навыками. Однако что должно цениться в Аджайл-командах, так это участники, обладающие навыками в разных областях.
Чтобы понять, насколько ложен этот миф, давайте представим себе хорошо организованный ресторан высшего класса. После просмотра многочисленных телевизионных кулинарных шоу я узнал, что в таком ресторане может быть шеф-кондитер. Он умеет профессионально готовить печенье, десерты, хлеб и прочую выпечку.
Это высокопрофессиональная, но узкоспециализированная роль. Другим узким специалистом на кухне может быть соусье, который готовит соусы, подливы и тому подобное.
На хорошо организованной кухне будет неплохо, если шеф-кондитер сможет помочь соусье, например, нарезать лук, если вдруг возникнет такая внезапная потребность. Но ни от шефа-кондитера, ни от соусье никто не ожидает, что кто-то из них сможет полностью выполнять работу за другого.
В современном мире сложных технологий невозможно ожидать от участников, чтобы они были настоящими профессионалами во всех областях работы, которыми занимается команда. Однако в хороших Аджайл-командах ценятся многофункциональные участники.
Несколько таких участников помогают с балансом между разными областями работы. Иными словами, иногда бывает, что команде требуется выполнить больший объем тестирования, чем обычно. Присутствие еще одного или двух участников команды, которые могут присоединиться к задаче, очень сильно помогает.
Этого можно достичь в большинстве команд, даже если некоторые участники специализируются лишь в одной области.
Миф №5: Аджайл-команды не планируют (или не умеют планировать) работу.
Большинство хороших Аджайл-команд занимаются планированием. Однако это планирование часто бывает менее заметным, чем в традиционных проектах, потому что в Аджайл-командах нет явного этапа планирования.
Вместо этого хорошие Аджайл-команды проводят планирование в виде серии небольших повторяющихся активностей, которые позволяют убедиться, что их планы всегда отражают реальность текущей ситуации.
Таким образом, команды разрабатывают планы так же, как они разрабатывают продукт: пересматривают и вносят исправления.
Планирование не должно охватывать срок больший, чем требуется для принятия важных решений. Однако в большинстве организаций и команд на том или ином уровне есть план для оценки того, что предстоит сделать в дальнейшем.
На самом деле, несмотря на этот миф, у Аджайл-команд процесс создания надежных планов упрощен, потому что они раньше получают инсайт о том, насколько быстро они производят программное обеспечение.
Представьте себе традиционную команду с этапами анализа, разработки, кодирования и тестирования. При благополучном стечении обстоятельств, такая команда может отложить утверждение плана до окончания этапа разработки. Но в этот момент участники команды еще не знают, как быстро они справятся с кодированием и тестированием, так как они еще не начинали ни одну из этих активностей.
В то же время Аджайл-команда «подкручивает рукоятку» всего процесса разработки на каждой итерации. Каждая итерация включает в себя понемногу от анализа, разработки, кодирования и тестирования. Это позволяет Аджайл-команде быстрее и более полно понять, как скоро они смогут превратить идеи в фичи.
Миф №6: Аджайл-команды создают продукт без проектирования.
Пришло время развеять наш заключительный миф о том, что Аджайл-команды не занимаются проектированием и разработкой Продукта.
Конечно, занимаются. Но, аналогично инкрементному планированию, Аджайл-команды проектируют и разрабатывают продукт постепенно. Это позволяет им пересматривать и максимально улучшать архитектуру и дизайн.
Это означает, что нет явного этапа, во время которого принимаются все архитектурные решения. Вместо этого архитектура Продукта появляется с течением времени.
Это достигается тем, что члены технической команды сначала фокусируются на тех аспектах продукта, которые они считают наиболее рискованными. Например, если поставка Продукта с необходимой производительностью представляет сложность, команда и Владелец Продукта принимают решение начать работу над функциональностью раньше, чтобы снизить этот риск.
Таким образом, появляющаяся архитектура Аджайл-продукта также используется намеренно. Она не возникает вдруг в какой-то определенный день, а проявляется постепенно и зависит от намерений участников технической команды.
Это означает, что у Аджайл-продуктов есть архитектура, на которой они базируются. Однако решения об этой архитектуре принимаются по мере необходимости в ходе реализации проекта, а не на начальном этапе.
