Мурк Дотком Голосов: 1 Адрес блога: http://mourk.com/blog/ Добавлен: 2008-04-13 19:50:24 блограйдером ld100

Масштабируем Agile

В предыдущей статье, «Неправильный Scrum» я рассказал о примере низкой эффективности и хаосе, вызванных неправильным применением agile-методологий. Не секрет, что все они предназначены, в первую очередь, для небольших локальных команд. Но как же действовать командам немаленьким при распределенной разработке — в целом и при аутсорсинге — в частности?

Напомню, основными проблемами у нас были: низкое качество взаимодействия людей в распределенных командах, множество времени, тратящегося на коммуникацию, излишняя бюрократизированность отчетности из-за менеджмента в стиле «прикрой жопу, потом работай», слишком короткие итерации и слабая связь цикла разработки с циклом тестирования.

Существуют различные способы масштабирования гибких методологий — я расскажу о тех, которые применили мы, уже наученные горьким опытом Лжескрама.

1. Пожалуй, самое главное, что удалось сделать — разделить один большой проект на целый пакет мелких и средних проектов, таким образом, каждая рабочая группа, состоящая из 2-5 человек, стала заниматься одним и только одним проектом.
2. Вместе с разделением крупного проекта на мелкие изменилась и стратегия коммуникаций. Теперь команды разработки и их тимлиды регулярно взаимодействовали лишь с техническими руководителями в США, решая тактические вопросы и согласовывая API, а с локальными руководителями проектов вывяли текущие проблемы. В свою очередь, руководители проектов общались между собой и с высшим руководством сугубо о вопросах стратегии, рисков, интеграции проектов и изменения состава групп, а технические руководители между собой решали сложные архитектурные вопросы, утверждали API и следили за документированием технических решений. Отойдя от формальностей, можно сказать — главной задачей руководителей проектов и технических руководителей стало устранение преград на пути своих команд и интеграция проектов, но никак не отчетность.
3. Часть команд стали проводить регулярные стоячие совещания, что было простым и дешевым способом для участников проекта «находиться на одной волне» и выявлять реальные и потенциальные проблемы своевременно. Без разделения «1 проект — 1 команда» это было бы невозможно.
4. Длину итераций увеличили с одной до двух недель и стали планировать их так, чтобы в конце всегда оставался запас в пару дней. Это частично позволило избавиться от постоянной гонки, в которой все чувствуют себя проигравшими — когда работаешь в нормальном ритме, то и ошибок допускаешь меньше.
5. Оценки сроков и планы перестали «спускаться сверху»: теперь оценки сроков задач проводилась их непосредственными исполнителями под присмотром тимлидов, после чего согласовывалась с руководителем проекта и техническим руководителем, которые, как правило, срок увеличивали, учитывая дополнительные риски и сложности.
6. Стали использовать средства Continuous Integration. Полноценного TDD у нас все равно не получилось, но удалось заставить разработчиков тестировать свой код и более-менее стабилизировать качество билдов продукта.
7. Ввели т.н. «development blogs», куда разработчики (реально — тимлиды) должны были каждый день записывать свои достижения и проблемы, с которыми они столкнулись. Эти блоги на некоторое время стали главным средством коммуникации удаленных команд (ведь они находились в разных офисах), кроме того, это заставляло разработчиков писать! Впрочем, когда объем взаимодействия между разными командами уменьшился, от блогов мы отказались для большинства проектов.
8. Постепенно мы разработали различные автоматические средства отчетности и оценки сроков (используя идеи evidence based scheduling Джоэля Спольски), реализовав их как Jira plug-ins. Но постепенно отказались и от ежедневной формальной отчетности. Вести ее можно было разве что по собственному желанию, чтобы лучше ощущать «пульс проекта». Руководитель проекта теперь отвечал строго за успешное окончание каждой итерации, а не за успешное бумагомарание.
9. Стали проводить ретроспективы (к сожалению, они проводились между руководством разных проектов без участия разработчиков) в конце итераций. Это не произвело чуда, но помогло увидеть проблемы с разных точек зрения и, конечно же, не наступать на одни и те же грабли дважды.
10. Ввели еженедельную оценку оффшорных команд людьми из главного офиса в США, где каждый мог по пятибалльной шкале оценить уровень коммуникации, качества кода и адекватного восприятия документации. Локальные руководители проектов получали информацию и видели, кто какую оценку поставил. Многим поначалу казалось, что это сделано с целью найти козлов отпущения и показать «вот мы тут белые-пушистые, а они там за океаном бездельники и мудаки». На самом же деле, все эти оценки позволяли увидеть, кто конкретно не доволен взаимодействием, после чего не гадать — а связаться с этим человеком и узнать, чем именно он не доволен и совместно с ним улучшить рабочий процесс. Медленно, но уверенно все это получилось. Как всегда в распределенной разработке, главная трудность — коммуникация, а самый трудно контролируемый фактор — фактор человеческий.

Выводы

Пусть agile-процесс изначально и рассчитан под небольшие проекты и локальные команды — его вполне можно масштабировать. Главное для этого — открытость и смелость проектных команд и, в первую очередь, руководства.
Откажитесь от ложных целей вроде бюрократичной отчетности и стратегии прикрытия задницы, сконцентрируйтесь на получении необходимого вам продукта. Экспериментируйте с длительностью итераций, составом команд, способами взаимодействия и тестирования… Да, вы будете совершать ошибки, но суть гибкого адаптивного процесса в том, чтобы признавать свои ошибки, учиться на них и постоянно улучшать процесс, а не пытаясь скрыть ошибки и искать козлов отпущения. Технологии и процессы несовершенны, люди несовершенны, мир несовершенен… но это не означает, что не мы не должны учиться и улучшать качество своей работы.

А вы масштабировали agile-процесс? Если да, то как?