- PVSM.RU - https://www.pvsm.ru -
Меня зовут Екатерина Шалапанова, в DataArt я работаю с 2008 года, занимаюсь в основном управлением проектами. Иногда, правда, совмещаю эту роль с ролью ситемного аналитика. В индустрии с 2000 года, начинала карьеру программистом и незаметно для себя переродилась в менеджера, которой интересно заниматься смежными областями. Сразу уточню, что мое мнение может не совпадать с позицией компании, которую я тут представляю.
Сразу оговорю, что под Agile подразумеваю в основном-таки Scrum, хотя в курсе существования других подвидов. Рассуждения эти, по моим ощущениям, более или менее применимы ко всем гибким процессам, т. е. проектам без фиксированного scope в начале работ и с уверенностью, что потом команда вырулит. Речь ниже пойдет о том, почему же команда не всегда выруливает.
У меня достаточно большой опыт в индустрии заказной разработки, плюс я очень люблю посидеть на чужих ретроспективах.
На самом деле, каждый проект несчастен по-своему, но, если копнуть глубже, все можно свести к трем основным причинам:
Зачастую достаточно и одной причины, чтобы Agile-проект не выжил, но, когда у нас комбинация из нескольких, конец немного предсказуем.
Дальше — по несколько строк про каждую из этих причин.
«Неправильный Agile» звучит, конечно, как оксюморон — как может быть однозначно правильным или неправильным подход, в основе которого лежит понятие гибкости?
Все просто – команда не совсем понимает суть подхода и не делает вещей, необходимых для успеха проекта.
Прежде чем идти дальше уточню, что под «командой» имею в виду не только разработчиков с тестерами и прочими технарями, а всех, кто так или иначе вовлечен в проект: конечные пользователи и их представители, менеджеры разного уровня, product owner, project sponsors и т. п.
Для успешного проекта недостаточно крутых программистов (тестеров, дизайнеров, DBA...), а нужны еще, во-первых, вовлеченность пользователей и вменяемый product owner; во-вторых — четкая синхронизация усилий, которая выражается и в применении правильных практик (всех этих вот берндаунов, таскбордов, демов, континиус интегрейшенов и ретроспектив), и в распространении информации и о прогрессе каждой user story, и о смысле проекта как такового.
Если сказать, что Agile — способ мысли, прозвучит пафосно, но, возможно, не совсем неверно. Как ни странно, я не помню ни одного успешного Agile-проекта, где участники не разделяли бы идеи Agile-манифеста (иногда даже не читая самого манифеста).
Еще составляющая, которую не могу не упомянуть, — взаимное уважение всех участников команды. Мы должны уважать заказчика, заказчик должен уважать нас, команда должна прислушиваться к мнению каждого члена и иметь в виду его интересы.
Но все вот это будет бесполезно, если у команды нет понимания общей цели и общего критерия успеха. И глобальной цели, и целей краткосрочных.
Только понимая цель проекта и признаки ее достижения, команда способна принимать правильные решения в ежедневной деятельности. Начиная с того, какие истории брать в итерацию, кончая тем, какой будет приоритет у багов (что важнее пользователям нашего продукта — внешний вид или скорость), или какую историю будем доделывать, если до конца итерации всего два дня, а работ — на три.
Не стоит забывать, что у членов команды есть еще и личные цели, и если помогать коллегам их достигать, удовольствие от совместной работы будет еще усиливаться. Пример — при выборе из двух примерно равных и одинаково незнакомых технологий выбираем ту, которую давно хотел изучить один из членов команды.
Итак, если есть ощущение «неправильного Agile»:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
(Agile manifesto)
Если компания давно уже как-то работает, менять сложившийся процесс бывает сложно а зачастую и невозможно (например, если по закону предприятие обязано объявить конкурс и зафиксировать требования и деньги, то...). Фиксированные требования и цена — явные признаки V-модели [1], и при работе, например, с российскими госкомпаниями у вас никакого чистого Agile не получится.
Просто потому, что если действовать, будто «готовность к изменениям важнее следования первоначальному плану» и «сотрудничество с заказчиком важнее согласования условий контракта», в конце проекта вам выкатят неустойку за недопоставленный функционал.
Иногда все не так жестко, и приходится бодаться не с внешними силами, а с какими-то внутренними ограничениями, типа требования следовать шаблонам при написании спецификаций (несовместимые с концепцией user story) или выдавать в определенном виде ежемесячный отчет о ходе проекта. При таких порядках декларация «работающий продукт важнее исчерпывающей документации» может вызвать недоумение у верхнего менеджмента.
С другой стороны, совсем вот брать и выкидывать старые правила, потому что они «не Agile», тоже не стоит. Есть всяческие полезные, хоть и занудные и бумагозатратные процедуры типа передачи кода в поддержку, или какой-нибудь внутренний или внешний аудит по безопасности продукта…
Итого, если есть осознание, что окружающая среда не совсем дружелюбна к Agile:
Как ни тяжело Agile-евангелистам осознавать, но в мире есть много задач, в которых никакой Agile не будет работать.
Самым ярким, конечно же, будет пример написания софта, управляющего космическими аппаратами — ну вот сложно раз две недели демонстрировать заказчикам посадку зонда на комету, получая в ответ замечания, что именно с точки зрения ученых-физиков стоило бы сделать по-другому.
Еще один яркий пример — какой-нибудь телеком. Когда вы пишете прошивку для телефона, вам совершенно не нужны демо имплементации каждого следующего класса сообщений GSM протокола потенциальным пользователям нового телефона.
Еще хороший пример неприменимости конкретно Scrum — всяческие команды поддержки, когда внезапно прилетает тикет от юзера с нулевым приоритетом, и все бросают всё и чинят. Никакой предсказуемости и ритмичности уже не будет.
С другой стороны, даже если мы разрабатываем космические аппараты, мобильные телефоны или программируем бытовую технику, найдутся задачи, которые можно и нужно делать Agile, показывая промежуточные результаты потенциальным пользователям.
Итак, мы начали делать в режиме Agile проект, который не совместим с идеей:
Напоследок очень хочется добавить, что серебряной пули, конечно же, не существует. И наверняка в вашем конкретном случае все может быть немножечко не так.
Спасибо за внимание.
Автор: DataArt
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/agile/76929
Ссылки в тексте:
[1] V-модели: https://ru.wikipedia.org/wiki/V-Model
[2] Источник: http://habrahabr.ru/post/245605/
Нажмите здесь для печати.