Особенно трудно бывает, когда традиционный проект выполняется по принципу «вначале детальные требования» (big requirements up front, BRUF). Представьте себе все эти многочисленные этапы, через которые должен пройти проект, прежде чем попасть к разработчику. В типичном водопадном проекте разработка BRUF выглядит примерно так.
• Руководитель проекта должен определить объем работы, чаще всего исходя из бизнес-требований или документированных целей.
• Руководитель проекта должен «подписаться» под объемом работ.
• Бизнес-аналитик должен изучить цели и объем работ, а затем выяснить у пользователей и других стейкхолдеров, как они планируют использовать создаваемый продукт и какая проблема решается.
• Бизнес-аналитик продумывает варианты использования, функциональные требования и т. д.
• Программист принимает требования и делает оценки работ.
• Менеджер проекта принимает требования и оценки, строит график и согласовывает его со стейкхолдерами и руководством.
Эта длинная цепь событий должна произойти, прежде чем начнется разработка. Неудивительно, что такая «игра в испорченный телефон» мешает разработчикам получить правильную информацию.
Такая проблема характерна не только для водопадных команд. Даже команды, практикующие личное общение, будут сталкиваться с непониманием и недостаточной коммуникацией. Ведь общение лицом к лицу эффективно, но менее конкретно, чем письменная коммуникация. В результате устных переговоров три человека могут подумать, что достигли консенсуса, а на самом деле имеют три разных мнения о предмете обсуждения.
Известная поговорка гласит: «Солнечный свет – лучшее дезинфицирующее средство». Она может казаться сомнительной с точки зрения медицины, но это очень хороший совет для проектных команд. Лучший способ узнать, создает или нет команда ценное программное обеспечение, – это как можно чаще поставлять работающее ПО пользователям. Это называется обзором (или прозрачностью) и также относится к коммуникации.
Ежедневные митинги – это эффективный инструмент создания прозрачности, потому что он решает проблемы коммуникации. Если эти проблемы происходят, то становятся видимыми. Возьмем, к примеру, ситуацию, когда три разных человека уверены, что договорились, но все имеют разное представление о предмете договоренности. Что делать, если каждый из них начнет делать разные функции, которые нужно будет интегрировать в конце спринта? Такие мелкие неурядицы, вызывающие дополнительные проблемы, накапливаются, если их своевременно не устранять. Они возможны на протяжении всего проекта и приводят к постоянному ухудшению качества кода, который создает команда. Небольшое недоразумение становится причиной дефекта или даже двух. Если они обнаружены поздно, то придется делать заплатки либо большие изменения в коде. Именно так происходит во время длительного проекта: качество кода со временем ухудшается.
Но результаты будут другими, если этим трем людям достаточно 15 минут ежедневного общения, чтобы задать друг другу три вопроса.
• Что я сделал с момента нашей последней встречи?
• Что я планирую сделать к нашей следующей встрече?
• Какие препятствия есть на моем пути?
Когда члены команды каждый день рассказывают о своей работе, многие проблемы, вызванные недопониманием, успевают заявить о себе прежде, чем станут трудноустранимыми (и дорогостоящими!). Когда каждый член команды контролирует работу остальных, они сохраняют взаимопонимание по поводу целей проекта и того, как их достичь.
Во время ежедневных планерок каждый рассказывает, какую задачу сейчас решает, а остальные вносят предложения по улучшению работы. Если предложения удачные, то на следующий день работа будет сделана лучше. Команда также может обнаружить, что сотрудник трудится не над той задачей. Обычно это вызвано проблемами с коммуникацией. Команда меняет план работы в нужном направлении уже на следующий день. Такие изменения называются адаптацией. Ежедневный цикл обзора, контроля и адаптации позволяет командам непрерывно получать обратную связь о ходе проектов и улучшать качество ПО. Это одна из наиболее важных особенностей Scrum. Scrum-команды принимают решения, основываясь на опыте ведения проектов и на реальных, известных фактах[34].
Такая обратная связь исключает из scrum-команды «посредника», которым может быть менеджер проекта, не принимающий в нем непосредственного участия. Таким образом снижается ущерб от игры в испорченный телефон, сохраняется время при одновременном повышении качества. Этот цикл называется петлей обратной связи, и команда может его использовать, чтобы поддерживать выполнение проекта и быть уверенной: все одинаково понимают суть вопроса.
В подобной ситуации программистам не всегда удобно «наблюдать» за работой товарищей по команде. Однако даже самые заядлые интроверты, как правило, к этому привыкают и с нетерпением ждут ежедневных митингов. Потому что это самый эффективный способ управления коммуникацией и формирования единого понимания командной работы.
Речь идет о размышлениях умного, скептически настроенного командно-административного менеджера проекта, которые выглядят примерно так: «Хорошо, мы так сделали. Команды не утверждают, что наперед знают все о своих scrum-проектах. Коммуникация и общее понимание важны для команды. Но работу нужно выполнять и необходимо определить, кто этим займется. Как это происходит на практике? Какова реальная механика работы с задачами программирования, администрирования баз данных, тестирования или другими задачами, которые мы можем внести в свой список для работы?»