• Расспросите всех участников группы о ценностях Agile-манифеста: что они думают о них, какие считают важными, полагают ли, что эти ценности касаются всех.
• Команды часто испытывают по отношению к результату своей работы чувство «лучше-чем-ничего», но не могут описать это словами. Попросите членов команды привести примеры из своей практики, которые они считают никчемными или требующими значительных усилий, но не приносящими особой выгоды.
• Начните разговор об отдельных ценностях или методах Agile-манифеста – например, если команда рассказывает о «договоре», который они заключают со своими пользователями, то используйте его в качестве отправной точки для разговора об условиях этого договора вместо обсуждения обычного взаимодействия с клиентами. Помогите им понять, какой они делают выбор.
Глава 3. Agile-принципы
Если бы я спросил людей, чего они хотят, они бы сказали, что хотят более быстрых лошадей.
Нет единого рецепта создания превосходного программного обеспечения. Agile-команды признают это. Но есть идеи и правила, которые помогают делать верный выбор, избегать проблем или справляться с ними, когда они неизбежны.
Мы уже познакомились с четырьмя ценностями, изложенными в Agile-манифесте. Помимо них существует 12 принципов, которые должен использовать каждый agile-практик – член команды разработки программного обеспечения. Когда 17 авторов Agile-манифеста встретились в Snowbird, они зафиксировали в этом документе четыре главные, по их мнению, ценности. Но чтобы придумать 12 дополнительных принципов, им потребовалось больше времени. Алистер Коберн, подписавший манифест, вспоминал[19]:
Группа из 17 человек быстро согласилась с выбором основных ценностей. Разработка же следующего уровня утверждаемых положений потребовала больше времени, чем то, которым мы располагали. Принципы, включенные в этот список, составляют набор текущих рабочих моментов.
Эти положения должны эволюционировать по мере того, как нам становится понятно, как именно люди воспринимают наши слова, а мы сами придумываем более точные выражения. Я буду удивлен, если эта версия не устареет вскоре после публикации книги. Ознакомиться с обновленным вариантом можно на сайте Agile Alliance.
Алистер был прав: манера подачи материала на сайте по языку и сути отличается от стиля этой книги. Язык всегда развивается, но идеи и принципы остаются неизменными.
В этой главе вы узнаете о 12 принципах гибкой разработки программного обеспечения: что они собой представляют, для чего нужны и как влияют на проект. На практическом примере мы покажем, как эти принципы применяются в жизни. Чтобы было легче учиться, разделим принципы на четыре части: поставка, коммуникация, выполнение и совершенствование, потому что они являются последовательными этапами. И хотя применение одного из них – эффективный способ узнать об остальных, каждый из этих принципов является самостоятельным.
12 принципов гибкой разработки программного обеспечения
1. Наш наивысший приоритет – это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.
2. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.
3. Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае – каждые несколько месяцев. Чем чаще, тем лучше.
4. Наиболее эффективный и действенный способ передачи информации – это встреча членов команды разработки ПО.
5. Представители бизнеса и команда разработки должны работать над проектом вместе.
6. Проекты строятся вокруг мотивированных людей. Создайте для них подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу.
7. Рабочее программное обеспечение – это главная мера прогресса проекта.
8. Гибкие процессы способствуют непрерывному развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы в течение неопределенного срока.
9. Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.
10. Простота – это искусство не делать лишней работы.
11. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
12. Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий[20].
Клиент всегда прав, не так ли?
Вернитесь к началу главы и перечитайте цитату. О чем говорит Генри Форд? О том, что людям надо предлагать то, что им действительно нужно, а вовсе не то, что они просят. У клиента есть потребность, и если вы создаете ПО, чтобы ее удовлетворить, то должны понять, способен ли он донести ее до вас. Как вы работаете с клиентом, который в начале проекта еще не знает, что ему нужна машина, а не очень быстрые лошади?
Это мотивация, выходящая за рамки 12 принципов: необходимо собрать команду, способную создать такое программное обеспечение, в котором пользователь действительно нуждается. Принципы зависят от идеи, которую мы закладываем при разработке проекта с целью получения некой ценности. Но понятие «ценность» сложное, потому что каждый понимает ценность программного обеспечения по-своему: люди ставят перед ПО совершенно разные задачи.
У вас в руках хороший пример воплощения этой идеи. Если вы читаете эту книгу на портативном устройстве для чтения электронной литературы, то значит, вы используете программное обеспечение, написанное для отображения книг на этом устройстве. Потратьте немного времени, чтобы подумать обо всех стейкхолдерах (заинтересованных лицах) проекта создания программного обеспечения для электронной книги.
• Как читатель вы хотите, чтобы программное обеспечение сделало книгу легкой для чтения. Вы заботитесь о том, чтобы можно было легко переворачивать страницы, выделять разделы, делать заметки, искать нужный текст и находить страницу, на которой остановились.
• Как авторы мы очень заботимся о том, чтобы слова, которые мы пишем, отображались корректно, пункты маркированного списка с отступом располагались так, чтобы вам было удобно его читать, а также чтобы вам было легко перемещать взгляд между основным текстом и сносками, а общее впечатление позволило получить удовольствие и знания от прочитанного.
• Нашего издателя O’Reilly волнует легкий способ дистрибуции этой книги и простота сбора позитивных читательских отзывов, а также продажи других книг.
• Продавец или розничный торговец, продавший вам эту книгу, хочет иметь возможность легко просматривать и покупать другую литературу, пригодную для торговли, быстро и легко скачивать ее для своих читателей.
Вы, наверное, сможете назвать еще больше стейкхолдеров и целей, важных для них. Каждая из целей представляет собою ценность для заинтересованной стороны.
Самые первые электронные книги не предлагали всех этих ценностей. Потребовалось много времени, прежде чем появилось программное обеспечение, способное удовлетворить эти требования читателей. И можно сказать с уверенностью, что ПО будет все лучше и лучше, потому что команды, работающие над его созданием, открывают для себя новые способы, позволяющие придавать ему новую ценность.
Легко понять ценность электронной книги задним числом. Гораздо труднее осознать ее на старте проекта. Давайте проведем мысленный эксперимент, чтобы исследовать это. Рассмотрим такой вопрос: как гипотетический читатель может узнать, что разработка программного обеспечения проводилась с использованием водопадного подхода?
Представьте, что вы в команде разработки самой первой портативной электронной книги. Техническая команда создала прототип устройства, которое имеет USB-порт для загрузки электронных книг и маленькую клавиатуру, позволяющую взаимодействовать с ним. Перед вашей командой стоит задача решить, какое программное обеспечение вы будете поставлять для этой электронной книги.
К сожалению, ваша компания имеет долгую историю создания ПО с использованием неэффективной, требующей подробной спецификации водопадной методологии. Поэтому первым делом ваш менеджер проекта организует большую встречу с участием всех, кого сможет найти. Ваша команда проводит несколько недель в переговорной комнате, встречаясь с топ-менеджерами компании, представителями издательства, которое хочет издавать электронные книги, ведущим менеджером по продажам из онлайн-магазина, желающего их продавать, и другими стейкхолдерами, которых нашел менеджер проекта и смог привести на встречу.
После нескольких дней интенсивных дискуссий ваши бизнес-аналитики смогли собрать воедино большую спецификацию с требованиями различных заинтересованных сторон, участвовавших в опросе. Была проделана тяжелая работа, но теперь у вас есть спецификации и все этому рады. Определен обширный пользовательский функционал, позволяющий предположить, что это будет самое передовое портативное устройство из всех доступных читателю. Появились функции сбора маркетинговой статистики для издателей, способные охватить все интернет-магазины и облегчающие процесс покупки книг. Есть инновационные функции для авторов с возможностью просматривать и редактировать свои работы, упрощая процесс публикации. Иными словами, предполагается поистине революционное программное обеспечение. После проведения всех подсчетов команда приходит к 15-месячному графику работ. Это кажется большим сроком, но все полны энтузиазма и уверены, что смогут довести дело до конца.
Перенесемся на полтора года вперед. Команда разработчиков электронной книги трудилась невероятно упорно, в том числе по ночам и в выходные дни, в результате чего распалось несколько семей. Такое колоссальное напряжение позволило выполнить проект точно по плану, практически день в день. (Это