Текст книги "Постигая Agile"
Автор книги: Дженнифер Грин
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +12
сообщить о неприемлемом содержимом
Текущая страница: 5 (всего у книги 34 страниц) [доступный отрывок для чтения: 11 страниц]
С чего начинать при работе с новой методологией
Приняв решение о цели внедрения методологии, каждый член команды начинает обсуждать с остальными методы, идеи и перспективы. Это противоположность раздробленного видения. Глядя на ситуацию в целом, команды начинают понимать, как индивидуальные практики взаимодействуют друг с другом. Вот где Брюс, Дэн, Джоанна и Том хотели бы быть! Но они не знают, как туда попасть.
Когда команда впервые опробовала новые практики, она все еще не осознает, как они будут соотноситься с хорошо знакомыми ей методами. Понимание придет тогда, когда будет накоплен опыт работы с методологией. Такой способ работает, потому что Agile представляет собой комплексную систему, включающую успешно взаимодействующие практики, которую команды используют, чтобы стать продуктивнее. Внедрение полного набора практик поможет команде получить основу для изучения этих взаимодействий.
Но внедрение целой методологии – более сложный процесс, чем выбор практик, которые вписываются в текущий способ работы команды. Если команде удастся внедрить всю методологию сразу, то она будет иметь больше шансов получить максимальную отдачу от agile-усилий. Отчасти это связано с тем, что помимо уже знакомых методов каждый внедряет идеи, которые не представляются необходимыми в первую очередь.
Как вы помните, команда разработчиков музыкального автомата столкнулась с проблемами, потому что Брюс, Дэн, Джоанна и Том подошли к agile-практикам независимо друг от друга. Чтобы получить наибольшую отдачу от Agile, они должны были прежде всего обсудить каждый из этих методов с точки зрения их необходимости для проекта в целом и членов команды в частности. Но дело в том, что они не знают, как начать такое обсуждение. Как и многие команды, они сталкиваются с дилеммой: если они уже знают, как именно использовать agile-практики для проекта и как работать вместе, то незачем это обсуждать. Но поскольку они этого еще не знают, то проводить такого рода дискуссии на ранних стадиях трудно.
Решение проблемы – в 12 принципах, которые тесно связаны с ценностями Agile-манифеста. Вы узнаете о них в главе 3.
Ключевые моменты
Команда, которая фокусируется только на отдельных практиках, может упустить из виду более глобальные цели, такие как улучшение коммуникации и реагирование на изменения.
Agile-методологии – это набор практик в сочетании с идеями, советами и опытом сообщества специалистов-практиков.
Такие agile-методологии, как Scrum, XP и Lean, включают в себя большой набор практик, но они также акцентируют внимание на идеях, которые помогают удерживать внимание команды на достижении этих целей.
Agile-коучи часто используют метафоры в качестве инструмента, чтобы помочь своим командам учиться.
Часто задаваемые вопросы
Если в Agile-манифесте утверждается, что исчерпывающая документация не нужна, означает ли это, что мы не должны ничего документировать?
Это очень распространенный вопрос. Прочтите еще раз то, что написано в этом пункте манифеста:
Мы ценим ‹…› работающий программный продукт выше исчерпывающей документации.
Это не значит, что мы как практики agile-методологий не ценим исчерпывающую документацию. И мы, конечно, не думаем, что вы не должны писать никаких документов! Существует много полезной документации, которая не является исчерпывающей.
Это означает, что передача рабочего ПО в руки пользователей – это лучший способ узнать, насколько хорошо мы как команда добиваемся улучшений.
Но в наших проектах есть место и для записей. Мы будем документировать наш код, используя комментарии к коду (например, чтобы объяснить, почему мы приняли такое решение, или не пишем код другим способом, или используем иной алгоритм). Далее вы узнаете о документе под названием «пользовательская история». Он обычно написан на карточке и помогает вам, команде, пользователям и другим заинтересованным сторонам работать вместе, чтобы выяснить, что именно вы будете строить. Есть много других видов документации, в чем-то более подробных, чем те, которыми пользуются agile-команды.
Вы уверены? Я точно знаю, что Agile – это значит ничего не писать и не планировать, а сразу переходить к программированию. Разве это не эффективнее?
Один из самых распространенных мифов о гибкой разработке программного обеспечения заключается в том, что agile-команды ничего не планируют. Но на самом деле они проводят гораздо более тщательную работу по планированию, чем многие традиционные проектные команды. Однако разработчикам, пришедшим в Agile недавно, может показаться, что планирования практически нет, потому что в нем участвует вся команда – и никто не стонет (а ведь жалобы – это типичная реакция программистов в ответ на приглашение принять участие в планерке).
Scrum-команды, например, посвящают обычно целый рабочий день планированию тридцатидневной итерации. Кроме того, они проводят ежедневные совещания (обычно длящиеся 15 минут), на которых вместе рассматривают план. Для пяти человек в команде это составляет 40 человеко-часов планирования в начале итерации и еще столько же в течение ближайших 30 дней. Это гораздо больше, чем многие традиционные команды делают за 30 дней разработки программного обеспечения. Неудивительно, что scrum-команды выполняют такую работу точно в срок! При этом члены команды вовсе не считают, что планирование – это «скучно». Дело в том, что они вовлечены в процесс, заботятся о результате и чувствуют, что усилия, потраченные на планирование проекта, необходимы, чтобы остальные итерации протекали успешно.
(Вы подробнее узнаете о механизмах планирования scrum-проекта в главе 4.)
Но разработчику, видящему это со стороны, может показаться, что все это напоминает погружение прямо в проект без планирования. Если команда занята планированием всего один день в начале 30-дневной итерации, то, значит, на следующий день она уже может начать программирование (если для них это наиболее важно в данный момент). Поэтому нередко кажется, будто они практически не занимаются планированием, хотя на самом деле их усилия, выраженные в сумме потраченных на это часов, существенны.
Правда ли, что Agile подходит только очень опытным разработчикам, которые хорошо справляются с планированием?
Нет, Agile подходит для любого уровня мастерства. Планирование – это навык, а единственный способ улучшить его – практика. Иногда (можно утверждать, что довольно часто) даже опытным разработчикам приходится пересматривать свою оценку. Мы читали много историй о реально существующих командах, в которых младшие разработчики проделывали грандиозную работу по внедрению Agile и это помогало создавать программное обеспечение, выходящее далеко за пределы ожиданий компании.
Однако есть один нюанс: младшие разработчики в эффективных agile-командах недолго остаются на своих невысоких позициях. Может быть, это одна из причин, почему люди думают, что Agile подходит лишь опытным специалистам.
Если все члены команды (тестировщики, бизнес-аналитики, UX-дизайнеры, руководители проектов и т. д.) не используют agile-методологию, то могу ли я заниматься гибкой разработкой самостоятельно?
Да. Но, вероятно, это будет не очень эффективно. Когда люди говорят о введении agile-методологий только для разработчиков, значит, они собираются применять только отдельные ее методы. Разработчики получат импульс для улучшения собственной продуктивности, поэтому польза все равно будет (результат «лучше-чем-ничего»). Но команда не изменится и не поменяет взглядов на ведение проектов, а это серьезно ограничивает позитивное влияние гибкого мышления на производительность. Способ работы над проектом, при котором команда работает по сценарию Water-Scrum-Fall (гибридная модель создания ПО), оставляет у ее членов чувство неудовлетворенности agile-методологиями.
Если я не использую Scrum, XP, Lean или Канбан, то значит ли это, что моя команда не гибкая?
Конечно, нет. Существует много гибких методологий – мы сосредоточились на нескольких и используем их, чтобы раскрыть перед вами идеи Agile. К тому же одна из целей этой книги – помочь ответить на вопрос «Что такое Agile?». В дальнейшем мы расскажем вам о ценностях и практиках различных методологий. С их помощью вы поймете, что значит быть гибким, а также узнаете о том, как такие, казалось бы, разные методы могут быть гибкими.
Что вы можете сделать сегодня
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой):
• Запишите все методы, которые вы используете при создании программного обеспечения. Это может быть описание спецификации, проверка кода в системе контроля версий, использование диаграммы Ганта для документирования плана проекта или ежедневные митинги.
• Попросите кого-нибудь из вашей команды также составить перечень методов, которые вы используете. Сравните списки. Какие методы есть только в одном из них? Обсудите их. Можете ли вы в будущем найти разницу между двумя списками?
Где вы можете узнать больше
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы узнаете больше об agile-ценностях и принципах гибкой разработки программного обеспечения из книги Алистера Коберна «Быстрая разработка программного обеспечения» (М.: Лори, 2013).
• Вы можете узнать подробнее о том, как принципы соотносятся с практиками, в книге Джима Хайсмита Agile Project Management: Creating Innovative Projects (Addison-Wesley, 2009).
• Узнайте больше об agile-коучинге из книги Лиссы Адкинс Coaching Agile Teams (Addison-Wesley, 2010).
Подсказки
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• При работе с новой командой поговорите индивидуально с каждым из ее членов и постарайтесь понять, как видение зависит от его роли.
• Расспросите всех участников группы о ценностях Agile-манифеста: что они думают о них, какие считают важными, полагают ли, что эти ценности касаются всех.
• Команды часто испытывают по отношению к результату своей работы чувство «лучше-чем-ничего», но не могут описать это словами. Попросите членов команды привести примеры из своей практики, которые они считают никчемными или требующими значительных усилий, но не приносящими особой выгоды.
• Начните разговор об отдельных ценностях или методах Agile-манифеста – например, если команда рассказывает о «договоре», который они заключают со своими пользователями, то используйте его в качестве отправной точки для разговора об условиях этого договора вместо обсуждения обычного взаимодействия с клиентами. Помогите им понять, какой они делают выбор.
Глава 3. Agile-принципы
Нет единого рецепта создания превосходного программного обеспечения. Agile-команды признают это. Но есть идеи и правила, которые помогают делать верный выбор, избегать проблем или справляться с ними, когда они неизбежны.
Мы уже познакомились с четырьмя ценностями, изложенными в Agile-манифесте. Помимо них существует 12 принципов, которые должен использовать каждый agile-практик – член команды разработки программного обеспечения. Когда 17 авторов Agile-манифеста встретились в Snowbird, они зафиксировали в этом документе четыре главные, по их мнению, ценности. Но чтобы придумать 12 дополнительных принципов, им потребовалось больше времени. Алистер Коберн, подписавший манифест, вспоминал[19]19
См. в уже упоминавшейся книге Алистера Коберна «Быстрая разработка программного обеспечения».
[Закрыть]:
Группа из 17 человек быстро согласилась с выбором основных ценностей. Разработка же следующего уровня утверждаемых положений потребовала больше времени, чем то, которым мы располагали. Принципы, включенные в этот список, составляют набор текущих рабочих моментов.
Эти положения должны эволюционировать по мере того, как нам становится понятно, как именно люди воспринимают наши слова, а мы сами придумываем более точные выражения. Я буду удивлен, если эта версия не устареет вскоре после публикации книги. Ознакомиться с обновленным вариантом можно на сайте Agile Alliance.
Алистер был прав: манера подачи материала на сайте по языку и сути отличается от стиля этой книги. Язык всегда развивается, но идеи и принципы остаются неизменными.
В этой главе вы узнаете о 12 принципах гибкой разработки программного обеспечения: что они собой представляют, для чего нужны и как влияют на проект. На практическом примере мы покажем, как эти принципы применяются в жизни. Чтобы было легче учиться, разделим принципы на четыре части: поставка, коммуникация, выполнение и совершенствование, потому что они являются последовательными этапами. И хотя применение одного из них – эффективный способ узнать об остальных, каждый из этих принципов является самостоятельным.
12 принципов гибкой разработки программного обеспечения
1. Наш наивысший приоритет – это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.
2. Мы принимаем изменения в требованиях даже на поздних этапах реализации проекта. Agile-процессы позволяют использовать изменения для повышения конкурентоспособности продукта.
3. Мы стремимся поставлять полностью рабочее программное обеспечение каждые несколько недель, в крайнем случае – каждые несколько месяцев. Чем чаще, тем лучше.
4. Наиболее эффективный и действенный способ передачи информации – это встреча членов команды разработки ПО.
5. Представители бизнеса и команда разработки должны работать над проектом вместе.
6. Проекты строятся вокруг мотивированных людей. Создайте для них подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу.
7. Рабочее программное обеспечение – это главная мера прогресса проекта.
8. Гибкие процессы способствуют непрерывному развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп работы в течение неопределенного срока.
9. Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.
10. Простота – это искусство не делать лишней работы.
11. Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
12. Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий[20]20
Источник: agilemanifesto.org/principles.html (по состоянию на июнь 2014 г.).
[Закрыть].
Клиент всегда прав, не так ли?
Вернитесь к началу главы и перечитайте цитату. О чем говорит Генри Форд? О том, что людям надо предлагать то, что им действительно нужно, а вовсе не то, что они просят. У клиента есть потребность, и если вы создаете ПО, чтобы ее удовлетворить, то должны понять, способен ли он донести ее до вас. Как вы работаете с клиентом, который в начале проекта еще не знает, что ему нужна машина, а не очень быстрые лошади?
Это мотивация, выходящая за рамки 12 принципов: необходимо собрать команду, способную создать такое программное обеспечение, в котором пользователь действительно нуждается. Принципы зависят от идеи, которую мы закладываем при разработке проекта с целью получения некой ценности. Но понятие «ценность» сложное, потому что каждый понимает ценность программного обеспечения по-своему: люди ставят перед ПО совершенно разные задачи.
У вас в руках хороший пример воплощения этой идеи. Если вы читаете эту книгу на портативном устройстве для чтения электронной литературы, то значит, вы используете программное обеспечение, написанное для отображения книг на этом устройстве. Потратьте немного времени, чтобы подумать обо всех стейкхолдерах (заинтересованных лицах) проекта создания программного обеспечения для электронной книги.
• Как читатель вы хотите, чтобы программное обеспечение сделало книгу легкой для чтения. Вы заботитесь о том, чтобы можно было легко переворачивать страницы, выделять разделы, делать заметки, искать нужный текст и находить страницу, на которой остановились.
• Как авторы мы очень заботимся о том, чтобы слова, которые мы пишем, отображались корректно, пункты маркированного списка с отступом располагались так, чтобы вам было удобно его читать, а также чтобы вам было легко перемещать взгляд между основным текстом и сносками, а общее впечатление позволило получить удовольствие и знания от прочитанного.
• Нашего издателя O’Reilly волнует легкий способ дистрибуции этой книги и простота сбора позитивных читательских отзывов, а также продажи других книг.
• Продавец или розничный торговец, продавший вам эту книгу, хочет иметь возможность легко просматривать и покупать другую литературу, пригодную для торговли, быстро и легко скачивать ее для своих читателей.
Вы, наверное, сможете назвать еще больше стейкхолдеров и целей, важных для них. Каждая из целей представляет собою ценность для заинтересованной стороны.
Самые первые электронные книги не предлагали всех этих ценностей. Потребовалось много времени, прежде чем появилось программное обеспечение, способное удовлетворить эти требования читателей. И можно сказать с уверенностью, что ПО будет все лучше и лучше, потому что команды, работающие над его созданием, открывают для себя новые способы, позволяющие придавать ему новую ценность.
Легко понять ценность электронной книги задним числом. Гораздо труднее осознать ее на старте проекта. Давайте проведем мысленный эксперимент, чтобы исследовать это. Рассмотрим такой вопрос: как гипотетический читатель может узнать, что разработка программного обеспечения проводилась с использованием водопадного подхода?
«Делай так, как я говорю, а не так, как говорил»
Представьте, что вы в команде разработки самой первой портативной электронной книги. Техническая команда создала прототип устройства, которое имеет USB-порт для загрузки электронных книг и маленькую клавиатуру, позволяющую взаимодействовать с ним. Перед вашей командой стоит задача решить, какое программное обеспечение вы будете поставлять для этой электронной книги.
К сожалению, ваша компания имеет долгую историю создания ПО с использованием неэффективной, требующей подробной спецификации водопадной методологии. Поэтому первым делом ваш менеджер проекта организует большую встречу с участием всех, кого сможет найти. Ваша команда проводит несколько недель в переговорной комнате, встречаясь с топ-менеджерами компании, представителями издательства, которое хочет издавать электронные книги, ведущим менеджером по продажам из онлайн-магазина, желающего их продавать, и другими стейкхолдерами, которых нашел менеджер проекта и смог привести на встречу.
После нескольких дней интенсивных дискуссий ваши бизнес-аналитики смогли собрать воедино большую спецификацию с требованиями различных заинтересованных сторон, участвовавших в опросе. Была проделана тяжелая работа, но теперь у вас есть спецификации и все этому рады. Определен обширный пользовательский функционал, позволяющий предположить, что это будет самое передовое портативное устройство из всех доступных читателю. Появились функции сбора маркетинговой статистики для издателей, способные охватить все интернет-магазины и облегчающие процесс покупки книг. Есть инновационные функции для авторов с возможностью просматривать и редактировать свои работы, упрощая процесс публикации. Иными словами, предполагается поистине революционное программное обеспечение. После проведения всех подсчетов команда приходит к 15-месячному графику работ. Это кажется большим сроком, но все полны энтузиазма и уверены, что смогут довести дело до конца.
Перенесемся на полтора года вперед. Команда разработчиков электронной книги трудилась невероятно упорно, в том числе по ночам и в выходные дни, в результате чего распалось несколько семей. Такое колоссальное напряжение позволило выполнить проект точно по плану, практически день в день. (Это кажется невероятным! Но ради нашего воображаемого эксперимента попробуйте поверить, что так и произошло.) Каждое требование в спецификации реализовано, протестировано и исполнено. Команда очень гордится собой, и все заинтересованные стороны согласны, что получили именно то, что просили.
Итак, продукт выходит на рынок… и его ждет провал. Никто не покупает книгу, стейкхолдеры недовольны. Что же произошло?
Оказывается, ПО, актуальное всего полтора года назад, сегодня никому не нужно. За это время в отрасли произошли изменения, появились новые стандарты и отраслевой формат для электронных книг, которые не вошли в созданную ранее спецификацию. И теперь никто из интернет-продавцов не хочет размещать на своих ресурсах нестандартный формат. Команда создала отличный шаблон для интернет-магазина, но его интерфейс сильно проигрывает шаблонам, которые используют розничные продавцы в настоящее время. Поэтому он никого не привлекает.
Труд и усилия вашей команды по созданию специальной функции предварительного просмотра для авторов потрачены впустую, потому что эта функция уступает опции, разработанной конкурентами и позволяющей поддерживать документы MS Word и отправлять их по почте.
Какая неприятность! Спецификация, разработанная вашей командой в самом начале, имела большое значение для клиентов и была важна для всех как внутри компании, так и за ее пределами. Но теперь ПО, задуманное полтора года назад, потеряло свою ценность. Необходимость внесения некоторых изменений можно было обнаружить на ранних этапах проекта, но многое требовалось поменять с самого начала. Необходимая при водопадном подходе «подробная спецификация перед началом работы» лишает команду гибкости и не позволяет реагировать на изменения.
Так как же все-таки суметь удовлетворить потребности стейкхолдеров и запустить проект создания работающего программного обеспечения?
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
