Для понимания некоторых аббревиатур и терминов приведу небольшой справочник.
Спринт 1
История
Нельзя держать все в голове. Для управления крупным проектом просто необходимы инструменты контроля.
Льюис Фрид
Введение
При прохождении этого спринта вы узнаете об истории Agile и курьезных примерах его применения. В качестве ценного результата сможете использовать знания в споре, на корпоративной вечеринке или на семинаре. Без истории не узнать настоящего.
1.1. Первый Agile
Творческий подход может означать всего лишь то, что больше нет возможности поступать так, как обычно.
Рудольф Флеш
Кто был в начале?
В ИТ-проектах у истоков Agile стояли Даррелл Ригби, Джефф Сазерленд (автономная исследовательская группа Skunk works в LockheedMartin Corporation, см. врезку на с. 19), Хиротака Такеучи и др. Эта первая тройка известна и сейчас.
Д. Ригби – партнер бостонского офиса консалтинговой компании Bain & Company (www.bain.com), входящей в большую тройку консалтинговых компаний вместе с McKinsey & Company и Boston Consulting Group. Он возглавляет глобальные экспертные группы компании по инновациям и розничной торговле и публикует статьи.
Дж. Сазерленд – генеральный директор, основатель, тренер, консультант консалтинговой и образовательной фирмы Scrum Inc. (www.scruminc.com).
Х. Такеучи преподает на кафедре стратегии Гарвардской школы бизнеса.
Сама история…
Еще в 1990-х гг. в ответ на преобладающие в то время неповоротливые (по мнению пользователей) методы управления разработками ПО был создан ряд «гибких» подходов: RAD (быстрая разработка приложений, 1991 г.); DSDM (метод разработки динамических систем, 1994 г.); Скрам (1995), Crystal Clear и экстремальное программирование (XP) (1996); FDD (Feature driven development, 1997 г.) и др. Их уже тогда называли гибкими, хотя все они возникли до публикации Agile-манифеста, официально объявившего миру об Agile.
Как родился Agile-манифест? 11–13 февраля 2001 г. на лыжном курорте The Lodge at Snowbird в горах Юты 17 «организационных анархистов» и одновременно авторитетнейших разработчиков ПО собрались, чтобы просто пообщаться, покататься на лыжах, поесть, расслабиться и попытаться прийти к общему знаменателю в поисках альтернативы негибким процессам и основанным на документации разработкам ПО.
Почему Snowbird в горах Юты?
Джим Хайсмит – президент компании Information Architects, Inc., автор книги Adaptive Software Development: A Collaborative Approach to Managing Complex Systems («Адаптивная разработка ПО: совместный подход к управлению сложными системами»), а также один из отцов-основателей Agile-манифеста, вспоминал, что «очень серьезные баталии проходили при обсуждении места проведения! Были серьезные возражения против Чикаго в зимнее время года: холодно и нечего делать. В Юте тоже холодно, но есть чем заняться, по крайней мере тем, кто катается на лыжах. В Ангилье на Карибских островах жарко и весело, но дорого добираться. В конечном счете Snowbird и катание на лыжах победили».
Почему Agile?
Почему Agile, а не, например, Light? Потому что Алистер Коберн, также один из участников, счел неподходящим термин light («легкий»): «Я не возражаю, что методологии могут называться легкими или тяжелыми, но я не уверен, что хочу, чтобы на меня ссылались как на легковесного участника конференции легковесных методологов. Это как-то ассоциируется с горсткой худых, дистрофичных, легковесных людей, пытающихся вспомнить, какое сегодня число».
Гибкость за пределами ИТ
Термин Agile manufacturing появился также в начале 1990-х, когда представители промышленности, правительства и научных кругов США собрались вместе (и конечно, не на горнолыжном мероприятии), чтобы выяснить, как сделать Штаты конкурентоспособными в производстве. Озвученные идеи первоначально были описаны как «гибкое производство», а позже как «гибкость предприятия». В 1991 г. группа в составе 15 руководителей из 13 компаний разработала стратегию 21st Century Manufacturing Enterprise Strategy и создала Agile Manufacturing Enterprise Forum. В 2001 г., в год создания Agile-манифеста, Рик Доув, один из участников форума, публикует Response Ability: The Language, Structure, and Culture of the Agile Enterprise, где описывается, как подготовить организации к реагированию на меняющуюся среду.
Skunk works
Авиастроительная компания LockheedMartin Corporation создала около завода пластмассы исследовательскую лабораторию с очень сильным запахом. Сотрудники лаборатории сами назвали себя Skunk works, дословно «скунсодельня», «вонючая фабрика», и впоследствии это имя было формально закреплено за лабораторией. Skunk works – одна из первых автономных исследовательских групп, созданная внутри компании для сложной творческой задачи – проекта радикальных инноваций в области конструкции самолетов. Группа работала практически без контроля сверху, со своим бюджетом, в состоянии секретности по отношению ко всей организации, и стала одной из первых гибких команд.
1.2. Agile: ценности и принципы
Обыденная, повторяющаяся, знакомая с давних пор текущая производственная деятельность стремится вытеснить новую, эпизодическую стратегическую деятельность.
Закон планирования Грешема
Agile-манифест
К моменту своего рождения Agile-манифест закрепил уже накопившуюся массу знаний и подходов к управлению разработками в виде четырех ценностей.
1. Люди и взаимодействие гораздо важнее процессов и инструментов.
2. Работающее ПО важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, все-таки больше ценится то, что слева. Такое замечание сопровождает все варианты Agile-манифестов в других разделах.
В своих дополнительно разработанных 12 принципах Agile-манифест провозгласил следующее.
1. Наивысший приоритет – удовлетворение потребностей заказчика с помощью регулярной и ранней поставки ценного ПО.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающее ПО следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее.
7. Работающее ПО – основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота как искусство минимизации лишней работы крайне необходима.
