Эджайл и технические коммуникации: командный подход (часть 1)

03.03.2014

Продолжаем публикации из данной серии. Сегодня мы узнаем, какие ошибки можно допустить даже при введении принципов скрама в команде. Своим опытом поделилась Алисса Фокс, директор по производству информации и программному менеджменту в компании NetIQ, Хьюстон, США.

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

Моя компания работает по методу скрама в течение уже нескольких лет, и за это время мы реализовали некоторые не особо полезные и нужные практики. Кроме того, у нас были некоторые сбои в доставке продуктов. Эти факторы подтолкнули нас взглянуть на неэффективные процессы и внести некоторые изменения.

Самодостаточные подразделения и разделение ответственности: наши старые подходы к скраму

Мы работали на самом базовом уровне скрам-команд, но многие из наших команд разделялись по  функциональным областям. Такие команды стали самодостаточными функциональными подразделениями, и эти подразделения не позволяли всей команде видеть общую картину того, что мы строили. Часто Отдел разработки на ранней стадии работы встречался с командой Менеджмента продукта, чтобы получить подробное описание требований или определить пользовательские истории (user story, также их называют «пожеланиями пользователя»), и только затем шёл к командам Управления качеством и Информационного развития. Или Отдел разработки разрабатывал свои опытные образцы, а Отдел управления качеством проводил свои тесты, но они не всегда совпадали, потому что не было четко определенных критериев приемлемости для каждой пользовательской истории.

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

Отделы разработки, качества и информационного развития вместо того, чтобы работать как единая команда, чтобы разрабатывать, тестировать и документировать пользовательские истории в едином спринте, Отделы разработки и информационного развития зачастую отставали от других команд. Вместо того, чтобы приписывать пользовательской истории статус «готово», мы, как правило, писали «готово», когда отдел разработки заканчивал свою работу, и «готово-готово», когда историю тестировали и документировали. Статус «готово-готово» звучит глупо, но он описывает, как задачи для пользовательских историй рассматривались ранее – то есть, использовалось два разных этапа «готово» что идёт против идеалов эджайл-команды.

Мы покончили с «готово-готово»: наш новый подход к скраму

Мы прошли основную переподготовку, а также провели множество бесед с командой Менеджмента продукта. Мы свежим взглядом посмотрели на наш подход к скраму и задачам. Теперь, когда мы планируем релиз и заполняем список функций и задач, вся команда точно понимает, что мы делаем (и не делаем). Вся команда принимает на себя ответственность за завершение всех аспектов каждой истории пользователя, в том числе задач тестирования и документирования.

Что еще более важно, вся команда соглашается, что история пользователя не считается готовой, пока она не разработана, не протестирована, все ошибки не исправлены, и история не задокументирована. Этот мысленный процесс побуждает команду планировать задачи тестирования и документирования, чтобы работать в том же спринте, что и задачи разработки, а не плестись позади. В результате, у нас теперь есть одно определение «готово», и оно означает, что история пользователя была разработана, протестирована и задокументирована. Если любой из этих пунктов не выполнен, история считается «неготовой». Для получения дополнительной информации о том, что означает «готово», см. «7 Принцип эджайла: Готово значит ГОТОВО» на http://www.allaboutagile.com/agile-principle-7-done-means-done/.

(продолжение следует)

Источник: Agile and Tech Comm: The Whole Team Approach

Тэги: Алисса Фокс, командная работа, организация работы, эджайл