Меня зовут Екатерина Шалапанова, в DataArt я работаю с 2008 года, занимаюсь в основном управлением проектами. Иногда, правда, совмещаю эту роль с ролью системного аналитика. В индустрии с 2000 года, начинала карьеру программистом и незаметно для себя переродилась в менеджера, которой интересно заниматься смежными областями. Сразу уточню, что мое мнение может не совпадать с позицией компании, которую я тут представляю.
Сразу оговорю, что под Agile подразумеваю в основном-таки Scrum, хотя в курсе существования других подвидов. Рассуждения эти, по моим ощущениям, более или менее применимы ко всем гибким процессам, т. е. проектам без фиксированного scope в начале работ и с уверенностью, что потом команда вырулит. Речь ниже пойдет о том, почему же команда не всегда выруливает.
У меня достаточно большой опыт в индустрии заказной разработки, плюс я очень люблю посидеть на чужих ретроспективах.
Итак: почему Agile не работает?
На самом деле, каждый проект несчастен по-своему, но, если копнуть глубже, все можно свести к трем основным причинам:
- Это неправильная команда, и она делает неправильный Agile.
- Agile плохо совместим с окружающей проект средой (т. е. компанией).
- Этот проект по природе не совместим с Agile.
Зачастую достаточно и одной причины, чтобы Agile-проект не выжил, но, когда у нас комбинация из нескольких, конец немного предсказуем.
Дальше — по несколько строк про каждую из этих причин.
Это у вас Agile неправильный
«Неправильный Agile» звучит, конечно, как оксюморон — как может быть однозначно правильным или неправильным подход, в основе которого лежит понятие гибкости?
Все просто – команда не совсем понимает суть подхода и не делает вещей, необходимых для успеха проекта.
Прежде чем идти дальше уточню, что под «командой» имею в виду не только разработчиков с тестерами и прочими технарями, а всех, кто так или иначе вовлечен в проект: конечные пользователи и их представители, менеджеры разного уровня, product owner, project sponsors и т. п.
Для успешного проекта недостаточно крутых программистов (тестеров, дизайнеров, DBA...), а нужны еще, во-первых, вовлеченность пользователей и вменяемый product owner; во-вторых — четкая синхронизация усилий, которая выражается и в применении правильных практик (всех этих вот берндаунов, таскбордов, демов, континиус интегрейшенов и ретроспектив), и в распространении информации и о прогрессе каждой user story, и о смысле проекта как такового.
Если сказать, что Agile — способ мысли, прозвучит пафосно, но, возможно, не совсем неверно. Как ни странно, я не помню ни одного успешного Agile-проекта, где участники не разделяли бы идеи Agile-манифеста (иногда даже не читая самого манифеста).
Еще составляющая, которую не могу не упомянуть, — взаимное уважение всех участников команды. Мы должны уважать заказчика, заказчик должен уважать нас, команда должна прислушиваться к мнению каждого члена и иметь в виду его интересы.
Но все вот это будет бесполезно, если у команды нет понимания общей цели и общего критерия успеха. И глобальной цели, и целей краткосрочных.
Только понимая цель проекта и признаки ее достижения, команда способна принимать правильные решения в ежедневной деятельности. Начиная с того, какие истории брать в итерацию, кончая тем, какой будет приоритет у багов (что важнее пользователям нашего продукта — внешний вид или скорость), или какую историю будем доделывать, если до конца итерации всего два дня, а работ — на три.
Не стоит забывать, что у членов команды есть еще и личные цели, и если помогать коллегам их достигать, удовольствие от совместной работы будет еще усиливаться. Пример — при выборе из двух примерно равных и одинаково незнакомых технологий выбираем ту, которую давно хотел изучить один из членов команды.
Итак, если есть ощущение «неправильного Agile»:
- Начать с высокоуровневого целеполагания — убедиться, что и мы, и пользователи понимаем однозначно критерии успеха проекта (и нет, это не в срок поставить весь скоуп по оговоренной цене. Это скорее «пользователям очень надо, чтобы решилась вот эта проблема, для чего мы хотим сделать возможными вот эти use case»). Очень полезны также будут хотя бы базовые знания разработчиков в доменной области и их представление о пользователях.
- Разобрать с командой практики и технологии процесса. Показать, как ежедневное честное обновление статуса помогает в достижении глобальных целей проекта.
- Убедиться на всякий случай, что мы не забыли такие ключевые вещи, как acceptance criteria, early demos, ретроспективы и обратная связь.
Agile плохо совместим с окружающей проект средой (компанией заказчика)
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
(Agile manifesto)
Если компания давно уже как-то работает, менять сложившийся процесс бывает сложно а зачастую и невозможно (например, если по закону предприятие обязано объявить конкурс и зафиксировать требования и деньги, то...). Фиксированные требования и цена — явные признаки V-модели, и при работе, например, с российскими госкомпаниями у вас никакого чистого Agile не получится.
Просто потому, что если действовать, будто «готовность к изменениям важнее следования первоначальному плану» и «сотрудничество с заказчиком важнее согласования условий контракта», в конце проекта вам выкатят неустойку за недопоставленный функционал.
Иногда все не так жестко, и приходится бодаться не с внешними силами, а с какими-то внутренними ограничениями, типа требования следовать шаблонам при написании спецификаций (несовместимые с концепцией user story) или выдавать в определенном виде ежемесячный отчет о ходе проекта. При таких порядках декларация «работающий продукт важнее исчерпывающей документации» может вызвать недоумение у верхнего менеджмента.
С другой стороны, совсем вот брать и выкидывать старые правила, потому что они «не Agile», тоже не стоит. Есть всяческие полезные, хоть и занудные и бумагозатратные процедуры типа передачи кода в поддержку, или какой-нибудь внутренний или внешний аудит по безопасности продукта…
Итого, если есть осознание, что окружающая среда не совсем дружелюбна к Agile:
- Делим процессы вокруг на три группы: полезные (которые нужны чтобы код потом выжил в уже сложившейся инфраструктуре: security testing, configuration guides и т..д.), те, с которыми можно ужиться (какие-нибудь репортинги, шаблоны, требования к оформлению кода по ГОСТ или по унаследованным от процедурных языков корпоративным стандартам), и те, которые не совместимы с Agile совсем.
- Первое превращаем в таски, добавляем в backlog, оцениваем, вздыхаем, что внезапно слегка вырос скоуп, и радуемся, что вытащили это на свет, и теперь примерно понятно, что делать.
- Насчет вторых вступаем в переговоры с теми, кто за них отвечает в компании. Можно попробовать найти компромисс: согласовать более удобный нам шаблон или договориться о более подходящих KPI.
- Самая большая проблема, конечно же, с третьими. Если уж так получилось, что вы ввязались в Agile-проект, зафиксировав на бумаге какие-то жесткие рамки, как только осознали масштабы бедствия, надо собирать заинтересованные стороны, включая заказчиков, чтобы придумать, как минимизировать ущербы и выйти с минимальными потерями. В конце концов, может случиться чудо, и у вас получится написать такое допсоглашение, которое изменит скоуп и сроки на те, что получились в итоге.
Этот проект по природе не совместим с Agile
Как ни тяжело Agile-евангелистам осознавать, но в мире есть много задач, в которых никакой Agile не будет работать.
Самым ярким, конечно же, будет пример написания софта, управляющего космическими аппаратами — ну вот сложно раз две недели демонстрировать заказчикам посадку зонда на комету, получая в ответ замечания, что именно с точки зрения ученых-физиков стоило бы сделать по-другому.
Еще один яркий пример — какой-нибудь телеком. Когда вы пишете прошивку для телефона, вам совершенно не нужны демо имплементации каждого следующего класса сообщений GSM протокола потенциальным пользователям нового телефона.
Еще хороший пример неприменимости конкретно Scrum — всяческие команды поддержки, когда внезапно прилетает тикет от юзера с нулевым приоритетом, и все бросают всё и чинят. Никакой предсказуемости и ритмичности уже не будет.
С другой стороны, даже если мы разрабатываем космические аппараты, мобильные телефоны или программируем бытовую технику, найдутся задачи, которые можно и нужно делать Agile, показывая промежуточные результаты потенциальным пользователям.
Итак, мы начали делать в режиме Agile проект, который не совместим с идеей:
- Прекратить пытаться делать Agile и начать строить более подходящий процесс. При этом совершенно необязательно отказываться от каких-то элементов процесса, которые ассоциируются с Agile, но работают везде.
- V-модель с ее, на первый взгляд монструозной трассировкой требований до кода и от кода до тесткейса, работает как надо в случаях, для которых предназначена. Если что-то не подходит для творящего под iPhone стартапа, это не значит, что это плохо.
- Может иметь смысл почитать про концепции ITIL, им уже 20 лет, и многие работают именно в них. В некоторых случаях Service Desk можно скрестить с Kanban, и получить на самом деле работающий true Agile-процесс.
- Бывают еще всяческие индустриальные практики и собственные разработки больших компаний, которые могут подойти, особенно если вы решаете задачу, похожую на то, для чего они созданы.
Напоследок очень хочется добавить, что серебряной пули, конечно же, не существует. И наверняка в вашем конкретном случае все может быть немножечко не так.
Спасибо за внимание.
