"У нас Agile". В эти слова говорящие их вкладывают самое разное. Многие делятся, что "у нас в компании слово Agile - модное, но никому непонятно, что оно значит". В ходе своей профессиональной деятельности я волею судеб неплохо изучила как матчасть, так и практический опыт реализации проектов по самым разным методологиям. И здесь я хочу попробовать поговорить про то, использование каких инструментов, мероприятий и технологий следует из решения работать по гибким методам. И с какими сложностями/подводными камнями можно столкнуться при их использовании.
Немного на эту тему я уже говорила в статьях Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?, а здесь попробую тему развить дальше.
Очевидно, что общие принципы гибких методологий записаны на имеющихся в открытом доступе скрижалях - в Agile манифесте. Честно скажу, при первом же прочтении Agile манифеста его тезисы лично мне захотелось поделить на две категории: "Спасибо, капитан Очевидность" (например, - Работающий продукт — основной показатель прогресса) и "Ну-ну, свежо предание, но верится с трудом" (например, - Над проектом должны работать мотивированные профессионалы)...
Поэтому интересен, на мой взгляд, не сам манифест, а те конкретные предложения по организации работы, которые из него следуют - в плане внедрения ценностей, инструментов, ролей, мероприятий и прочая… Давайте я попробую здесь обобщить конкретные выводы из Agile-манифеста. И приглашаю начинающих и опытных РП продолжить дискуссию, которую мы начали вчера на вебинаре, посвященном сопоставлению гибких и классических подходов к управлению проектами. А именно -
В чем сильные и слабые стороны тех или иных инструментов/ценностей/подходов Aglie?
Как многие читатели уже знают, я увлекаюсь парусным яхтингом (не путать с яхтингом Романа Абрамовича), поэтому, наверное, люблю морские образы и метафоры. И в ходе вебинара мы попробовали рассмотреть разные инструменты через призму метафоры парусной яхты:
- Парус: Что является движущей силой для выбранного инструмента? Что мы выигрываем, когда у нас получается применить тот или иной инструмент?
- Ветер: Что наполняет наши паруса? За счет чего у нас получается работать с тем или иным инструментом?
- Якорь: Что тянет нас на дно? Какие недостатки стоит иметь в виду?
- Рифы: Какие риски нам надо учесть, когда мы работаем с теми или иными инструментами?
Итак. Давайте устроимся поудобнее и почитаем, что же предлагают принципы Agile-манифеста? Лично я нашла в нём 6 основных тезисов:
I. Готовность к изменениям
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
II. Сотрудничество
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как представителей бизнеса с командой, так и внутри команды.
III. Частота и ритмичность
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
IV. Ценный продукт
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Работающий продукт — основной показатель прогресса.
- Простота — искусство минимизации лишней работы — крайне необходима.
V. Главное - это люди
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
VI. Думаем, как работать лучше
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
А теперь давайте посмотрим, что же из этих тезисов следует на практике.
I. Готовность к изменениям
Читаем манифест:
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Что из этого следует на практике?
- Гибкие контракты - потому что когда мы формулируем требования в процессе работы, мы не можем на старте знать весь объем работ. (как из этого выкручиваться - я уже писала в статье Контракты Agile: как заключать договора в условиях расползания содержания).
- Бэклог в виде "хотелок" бизнес-заказчика, изменяемый на протяжении всего проекта - вместо ТЗ, написанного на старте
- Готовность к переделкам - они сразу закладываются в стоимость контракта (хотите без переделок - работайте по водопаду, только тогда не грустите, что получили на выходе совершенно не то, что хотели)
- Планирование по кусочкам - вместо планирования всего на старте
На вебинаре мы рассмотрели тему планирования по кусочкам - в чем плюсы и минусы когда мы реализуем его на практике?
II. Сотрудничество
Читаем Agile-манифест дальше:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
И
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как представителей бизнеса с командой, так и внутри команды.
Что из этого следует?
Мероприятия Agile: Stand-Up совещания и Демонстрации
Инструменты: Канбан-доски (кому интересно про Канбан - см. мою статью Канбан в условиях российской действительности)
Мы успели рассмотреть только три принципа из 12. Продолжение разбора принципов Agile-манифеста следует в дальнейших статьях - сегодня мы не затронули темы “Частота и ритмичность”, “Ценный продукт”, “Главное - это люди”, “Как работать лучше”...
Подключайтесь к дискуссии - пишите в комментариях - по вашему опыту применения - в чем сильные/слабые стороны и подводные камни инструментов/мероприятий Agile?
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
Продолжение: Agile в проектах 1С: где-то между невозможно и неизбежно. Часть вторая.
