Постигая Agile

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

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

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

Но результаты будут другими, если этим трем людям достаточно 15 минут ежедневного общения, чтобы задать друг другу три вопроса.

• Что я сделал с момента нашей последней встречи?

• Что я планирую сделать к нашей следующей встрече?

• Какие препятствия есть на моем пути?

Когда члены команды каждый день рассказывают о своей работе, многие проблемы, вызванные недопониманием, успевают заявить о себе прежде, чем станут трудноустранимыми (и дорогостоящими!). Когда каждый член команды контролирует работу остальных, они сохраняют взаимопонимание по поводу целей проекта и того, как их достичь.

Во время ежедневных планерок каждый рассказывает, какую задачу сейчас решает, а остальные вносят предложения по улучшению работы. Если предложения удачные, то на следующий день работа будет сделана лучше. Команда также может обнаружить, что сотрудник трудится не над той задачей. Обычно это вызвано проблемами с коммуникацией. Команда меняет план работы в нужном направлении уже на следующий день. Такие изменения называются адаптацией. Ежедневный цикл обзора, контроля и адаптации позволяет командам непрерывно получать обратную связь о ходе проектов и улучшать качество ПО. Это одна из наиболее важных особенностей Scrum. Scrum-команды принимают решения, основываясь на опыте ведения проектов и на реальных, известных фактах[34].

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

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

Последний ответственный момент

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