Я начинаю серию статей, посвященных образу мысли Agile. Американский институт PMI, законодатель мировых стандартов по проектному управлению, наконец, заметил существование Agile – гибких методов управления проектами. И выпустил по этому поводу несколько руководств:
- 6-ую версию PMBOK, где в каждом разделе рассказывается про методы и инструменты гибкой методологии управления проектами.
- Введение в Agile – Agile Guide.
- И книгу, направленную на создание в голове руководителей проектов того, что PMI называет Agile mindset (гибкий образ мысли) – «PMI-ACP Exam Prep: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam».
Коль скоро я со всей этой литературой, частично на русский язык не переведенной, внимательно ознакомилась, попробую выделить из нее самое ценное для читателей Инфостарта. Серия статей по Agile, которую я планирую здесь опубликовать, основана на двух вещах:
- на идеях и предложениях от адептов проектного управления PMI, изложенных в вышеупомянутой литературе;
- на практическом опыте приложения указанных выше идей и принципов к российским ИТ-проектам и проектам внедрения 1С, в частности.
Откуда вообще появился подход Agile? Почему нам приходится быть «пронырливыми»?
Майк Гриффитс, автор третьей из упомянутых в начале статьи книг PMI, выделяет следующие принципиальные различия между производственной работой (industrial work) и работой в информационной сфере (knowledge work):
Предложение «на подумать»:
Отметьте, какими чертами из упомянутых выше характеризуются задачи, которые вы решаете.
Посчитав, с какой стороны больше «плюсиков», вы сможете понять, она ближе к «производственной» или «информационной» эпохе. Поделитесь вашим ответом в комментариях, любопытно!
Мой личный ответ был примерно такой: когда мы говорим про задачи сопровождения продукта 1С – большая часть «плюсиков» оказывается в левой колонке. А когда речь идет про внедрение нового продукта, особенно не типового – сразу перемещаемся в правую колонку. Потому что левой колонки оказывается недостаточно. То есть классические подходы перестают работать, и приходится проявлять ту самую «пронырливость».
12 принципов Agile-манифеста
Итак, Agile родился как желание более эффективно выполнять «информационную работу». И для того, чтобы применять его на практике, нужно не просто регламентировать стэндап-совещания, канбан-доски и прочие атрибуты. Нужно суметь изменить взаимоотношения внутри команды и с заказчиками и сформировать тот самый «образ мысли Agile», о котором я веду сегодня речь. В чем же он заключается? Для этого давайте вернемся к истокам, к документам, которые придумал Agile Alliance, отцы-основатели гибкого подхода.
Манифест Agile я уже подробно разбирала в предыдущих статьях Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?. Здесь я не буду повторяться и перечислю 12 принципов Agile-манифеста, а также дополню их комментариями по реализации на практике, иначе не интересно.
1. Самое важное – удовлетворить потребности заказчика, регулярно и непрерывно поставляя необходимые ему продукты.
Антипример: «Мы собрали с заказчика требования, полная ерунда, но это его проблемы – все зафиксировано в контракте, и к нам не может быть никаких претензий».
Пример Agile: «Совещаемся с заказчиком в процессе работы, уточняя при необходимости требования, демонстрируя промежуточный результат (лучше не в текстовом описании, а в виде конкретных решений, которые можно "потрогать")».
2. Выпускайте работающий продукт как можно чаще, с периодичностью от пары недель до пары месяцев.
Антипример: Одна поставка в конце.
Пример Agile: В идеале – у нас несколько маленьких поставок, каждая с частью функционала, которые уже можно запускать в работу. Если невозможны промежуточные релизы, то используем моделирование и даем заказчику «поиграть» с будущим интерфейсом и протестировать в условиях, максимально приближенных к боевым.
3. Разработчики и представители бизнеса должны ежедневно сотрудничать от начала до конца проекта.
Антипример: Без комментариев.
Пример Agile: Придумываем, как мотивировать представителей заказчика к постоянному участию в проекте. Универсального и простого решения тут быть не может, в моей практике работают: человеческие дружеские отношения, упоминание в контракте, налаженное расписание, распоряжения высшего руководства, завязка KPI заказчика на успех проекта, приглашение заказчика в ресторан (ваши варианты в комментариях).
4. С радостью встречайте изменения требований, даже в конце разработки. С помощью Agile-процессов вы сможете укротить изменение как норовистого скакуна и, оседлав его, достичь конкурентного преимущества для заказчика.
Комментарий: Меня всегда восхищает этот принцип. Честно скажу, встречать с радостью получается... с трудом. Скорее, принимать как данность.
Антипример: Ситуация, когда одна сторона старательно прижимает другую к стенке. Например, заказчик настаивает на том, чтобы все переделать, «а иначе не подпишем акты». Или исполнитель, который не соглашается ударить лишний раз пальцем о палец под лозунгом «в контракте этого нет, мы этого делать не будем». Не люблю в такой ситуации обвинять одну сторону и обелять другую, просто можно констатировать, что люди «не договорились».
Пример Agile: При грамотно выстроенной системе допсоглашений, если из-за изменений требований исполнителю приходится делать двойную (тройную, четверную и так далее) работу, то она оплачивается, поскольку допсоглашение подписывается по каждой итерации отдельно.
5. Выполняйте проекты, привлекая мотивированных личностей. Создайте этим людям условия, дайте, что им необходимо, а затем доверьтесь – работа будет сделана.
Прокомментирую этот принцип в комплекте с еще одним, забегая вперед по списку:
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоуправляемых команд.
Комментарий: PMBOK ссылается на концепцию X и Y Дугласа Макгрегора.
Макгрегор исследовал связь производительности труда работников с тем, насколько им передают ответственность. Часть менеджеров (их он назван руководители X), были уверены что:
- люди изначально не любят трудиться и при любой возможности избегают работы;
- у людей нет честолюбия, и они стараются избавиться от ответственности, предпочитая, чтобы ими руководили;
- больше всего люди хотят защищенности;
- чтобы заставить работников трудиться, необходимо использовать принуждение, контроль и угрозу наказания.
А другая часть менеджеров (руководители Y), напротив, считала что:
- труд — процесс естественный, если условия благоприятные, работники не просто примут на себя ответственность, но будут стремиться к ней;
- если работники приобщены к организационным целям, они будут использовать самоуправление и самоконтроль;
- приобщение является функцией вознаграждения, связанного с достижением цели;
- способность к творческому решению проблем есть у многих, а интеллектуальный потенциал среднего человека используется лишь частично.
И, как нетрудно догадаться, производительность работников под началом менеджеров Y оказалась в итоге выше. Исследования Макрегора проводились в 1960-х годах, с тех пор концепции мотивации неоднократно развивались и совершенствовались. Но общая идея осталась неизменной – людям важно, чтобы им доверяли и делегировали ответственность.
Пример и антипример: Моя практика наблюдения за руководством проектами внедрения с точки зрения модели X и Y говорит о следующем:
- Инициативные и здравые сотрудники от «микроменеджмента» (то есть попытки руководить каждым их шагом) портятся и увольняются. Когда им даешь инициативу – система работает лучше.
- Бывает такое, что ленивые и бестолковые сотрудники, когда перестаешь их жестко контролировать, а предлагаешь проявлять инициативу, пытаются сесть на шею, то есть перестают что-либо делать. Для меня это, скорее, повод с сотрудником расстаться, чем переходить с модели Y на модель X.
(Вообще, тема мотивации сотрудников/коллег/заинтересованных сторон – благодатная и бесконечная. Возможно, надо на эту тему написать отдельную статью с примерами удачных и провальных инструментов).
6. Личное общение – самый эффективный и результативный способ обмена информацией как внутри команды, так и с окружающим миром.
Комментарий: Автор семейства методологий Crystal (фреймворк внутри семейства Agile) Алистер Кокбёрн ввел специальное понятие «осмотическая коммуникация» (от слова «осмос» – проникновение через непрочные стенки). Имеется в виду, что когда люди, работающие над проектом, физически находятся в одном помещении, то информация «фоном» витает в воздухе, и все окружающие невольно оказываются в теме. Что повышает общую продуктивность работы: когда ваши коллеги обсуждают вслух проблему, имеющую отношение к проекту, вы можете принять решение, пропустить беседу мимо ушей или послушать «вполуха» и, тем самым, расширить свое представление о происходящем.
Пример Agile: Мой опыт знакомства с проектами внедрения показывает, что когда представители заказчика и исполнители работают физически в одном помещении, то эффективность работы возрастает. Заодно заказчику наглядно видно, что исполнитель занят делом. У этого могут быть свои недостатки – например, повышается шанс, что сотрудника «схантят» в организацию исполнителя, и он перейдет к ним работать. Или, например, исполнителю сложнее скрывать от заказчика, что члены команды работают над несколькими проектами одновременно. Но речь не об этом.
7. Самый верный показатель прогресса — работающий продукт.
Пример Agile: Если вы исправно выдаете работающий продукт в конце каждой итерации (или нескольких итераций), то это лучше всего позволяет победить страхи заказчиков вроде «за что мы им платим, если неизвестно, сколько это будет стоить».
Антипример: В проектах внедрения 1С очень часто множество небольших поставок невозможно. То есть в теории возможно, но никому не нужно – клиент все-равно будет работать со старым продуктом, пока какая-то критическая масса функционала не будет реализована. Часто в такой ситуации приходится применять так называемые гибридные методы – например, WaterScrumFall.
8. Agile процессы настраивают на стабильный темп разработки, что дает возможность инвесторам, разработчикам и пользователям всегда работать в постоянном ритме.
Антипример: Очень часто на разработчиков наваливается заведомо больше работы, чем они могут успеть за нужное время. На практике это, увы, приводит к полной непредсказуемости результата. В период моей работы на НПК на предложение расставить приоритеты главный конструктор только отмахивался – все задачи приоритетные, все задачи срочные, все надо делать прямо сейчас (читай – отказывался от ответственности). В результате время поставки было категорически непредсказуемым.
Пример Agile: Про WIP-лимиты и ограничение времени поставки я рассказывала в статье Канбан в условиях российской действительности (см. разделы про WIP-лимиты, про измерение потока работ). Добавить к этому могу разве что замечание, что четкий ритм работы упрощает прогнозирование и взаимопонимание с коллегами.
Я как-то имела возможность сравнить работу двух команд разработчиков на одном предприятии – обе состояли из компетентных профессионалов. Только одна работала под началом одного архитектора, добилась четкого структурирования задач и одного канала их постановки. А другой приходилось разрываться между несколькими проектами, отрабатывать ситуацию частой смены приоритетов, простаивать из-за ожидания решений от смежников и т. п. – ни о каком ритме речи идти не могло. В результате эффективность работы команд различалась буквально в разы. Выходом стало обеспечение стабильного темпа работы и для второй команды.
9. Постоянное внимание к повышению мастерства и хороший дизайн повышают гибкость проекта.
Комментарий: Никто, я думаю, не станет спорить с тем, что «лучше быть богатым и здоровым, чем бедным и больным». В смысле, что лучше быть внимательным к повышению мастерства, и хорошо продумывать то, что мы делаем. Тем не менее, не у всех получается. Сталкиваясь в рамках своей профессиональной деятельности с разными командами разработки, я задумываюсь над вопросом, почему кто-то может? Мои версии примерно следующие:
Почему некоторые команды уделяют внимание хорошему дизайну?
- Потому что могут себе это позволить (а не находятся непрерывно в ситуации жесткого дедлайна, когда выдохнуть некогда, а все сроки сгорели еще вчера).
- Потому что есть внешний контроль. Например, практика code review – анализа кода. Она требует больших затрат, ибо приходится работать двум людям там, где вполне может справиться один. Зато позволяет поймать больше багов сразу, повышает самодисциплину разработчиков, взаимозаменяемость специалистов. Люди, конечно, могут сами себя мотивировать хорошо работать, но когда кроме внутренних мотиваторов есть еще и внешние, то всё работает лучше.
- Потому что есть выстроенная система. Когда организация находится на начальном уровне зрелости, проект внедрения вытягивается в условиях ограниченного бюджета за счет титанических усилий разработчика и аналитика – тут не до грамотной архитектуры.
10. Простота – искусство воздержаться от лишней работы – основа Agile.
Делаем, в первую очередь, то, что представляет для заказчика ценность. Подробнее про ценность для заказчика я собираюсь рассказать в следующей статье, а пока просто вспомню часто цитируемое исследование про частоту использования фич:
Идея водопада заключается в том, чтобы реализовать все фичи единым махом (как нужные, так и не очень). Идея инкрементального управления проектом – что, в первую очередь, делаются те фичи, которые используются всегда и часто, и уже потом все остальные. Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.
12. Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы.
Комментарий: В этом месте как раз кроется один из способов отличить Agile от «Тяп-ляп». Это – наличие в команде рефлексии, что можно сделать лучше и где можно совершенствоваться. И применение итогов этой рефлексии на практике!
Антипример: А вот здесь я не буду приводить в качестве примера компанию, которая – ай-ай-ай – ничего не рефлексирует и не пытается повышать результативность. А наоборот, вспомню организацию, которая твердо решила, что у них должен быть Agile, и все по правилам, поэтому всю систему мотивации отменяем, жесткое руководство заменяем на самоуправление, диаграммы Ганта выбрасываем в мусорную корзину и т. п. Почему же это антипример, спросите вы? Потому что попытка усовершенствовать все и сразу обречена на неуспех. Agile – это искусство двигаться небольшими шагами. Главное – в правильном направлении.
Коллеги, буду рада вашему опыту по теме. Каким образом в проектах внедрения получается проявлять «пронырливость»? Где не получается, а хотелось бы? Какими находками хочется поделиться?
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
