Усвоенные уроки одной кроссфункциональной команды разработки

Соавторы: Акжигитов Марат, Анимисов Алексей, Воронин Алексей, Косарчук Алексей, Поморцев Кирилл, Рахманов Александр, Рыбин Сергей, Сурменок Павел.

Заметка представляет собой список уроков, которые одна из команд разработки выучила за время от начала проекта до выпуска продукта версии 1.0.0 в течение 2012 года.

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

Внешние коммуникации

Используйте демонстрации для сбора отзывов, это не отчетное собрание

Ситуация

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

Решение

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

Выводы

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

Демонстрации не самый эффективный инструмент для получения обратной связи

Ситуация

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

Решение

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

Выводы

1. Хорошую обратную связь вы получите, если пользователь реально попробует использовать продукт.
2. Использование частых выпусков более эффективный инструмент для получения обратной связи о продукте от пользователей, чем демонстрации.

Используйте видеозаписи для обмена информацией

Ситуация

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

Кроме того, ожидались значительные трудозатраты команды на консалтинг при интеграции продукта другими командами разработки компании, когда пришлось бы множество раз повторно передавать одну и ту же информацию различным заинтересованным лицам.

Решение

Было решено попробовать каким-то простым способом фиксировать информацию, предоставляемую на демонстрациях так, чтобы все заинтересованные лица могли с нею ознакомиться в режиме offline и on-demand, то есть при возникновении необходимости. В итоге решили записывать видеоролики выступлений и публиковать их на портале проекта наравне с остальной информацией, описывающей продукт. Спустя какое-то время путем опроса заинтересованных лиц был зарегистрирован факт успеха данной формы публикации информации об изменениях в продукте и проекте. Несмотря на рост популярности демонстраций и количества посещающих ее заинтересованных лиц видеоролики также оказались востребованы. Кроме того, видеоролики стали использоваться для минимизации трудозатрат при подготовке новых членов команды.

Выводы

1. Видеозаписи демонстрации – эффективный способ offline-обмена информацией с заинтересованными лицами проекта.
2. Этот способ обмена информацией может быть применим и к другим мероприятиям: ввод в строй новых сотрудников, внутренние семинары, внешние мероприятия и т.п.

Процессы

Думайте о целях перед принятием решения

Ситуация

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

Решение

Для решения этой проблемы в процесс были встроены принципы работы “от целей”:

1. Было решено вернуться к стандартному формату оформления требований в виде пользовательских историй, так как формат: “Я, как (тип пользователя), хочу (поведение продукта), чтобы (цель)” – заставляет думать о целях (особенно раздел “чтобы”), для достижения которых и предлагается что-то делать.
2. Затем решение было масштабировано на планирование выпусков и итераций: команда, прежде всего, определяет цели, а потом уже формирует план работ (backlog), ориентированный на достижение этих целей.

Таким образом, вошедшее в привычку применение принципов решения проблем даже для небольших и, казалось бы, тривиальных проблем, решило эту проблему.

Выводы

1. Всегда думайте в рамках целей, когда выдвигаете требования или вырабатываете решения. Это поможет вовремя скорректировать ваши действия и избежать серьезных ошибок.
2. Получая от другого человека задание или запрос всегда убеждайтесь, что понимаете его цель. Если цель действий не раскрывается, активно интересуйтесь ею, мотивируйте человека сообщить ее.

Направляйте команду к правильным решениям, а не навязывайте готовые

Ситуация

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

Решение

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

Выводы

1. Старайтесь не спускать решения “сверху”, в каких отношениях подчинения вы бы не находились, а лучше ставьте понятные цели и полагайтесь на способности исполнителей (Y-менеджмент, “открытое кимоно” у Тома Демарко).
2. Автором и проводником изменений в проекте не может быть один человек. Изменения успешно внедряются только тогда, когда с ними не просто согласны все члены команды, но они участвовали в их выработке: даже если один член из команды уже имеет в кармане “серебряную пулю”, нужно дать возможность найти ее самой команде.

Работайте с требованиями гибко

Ситуация

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

Решение

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

Выводы

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

Не накапливайте долги по разработке

Ситуация

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

Решение

Было принято решение создавать документацию, как только в ней появляется необходимость, то есть непосредственно при внесении изменения в продукт. В критерии готовности (Definition of Done) реализованной пользовательской истории (User Story) было добавлено требование необходимости создания куска документации (Document Item), описывающей реализованное требование, который в дальнейшем используется для сборки итогового документа. Таким образом, был применен итеративный подход к созданию документации: постепенно, а не все сразу, но при этом сразу же, не откладывая. Постепенно это позволило полностью избавиться от накопленного долга по документированию и обеспечить принципиальную невозможность его появления в будущем, следовательно, стало проще планировать работы.

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

Выводы

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

Вносите мелкие изменения сразу при появлении необходимости в них

Ситуация

В ходе проекта команда приняла решение при появлении каких-либо проблем, в случае если их решение можно отложить на потом, фиксировать их в системе учета и потом уже отдельно планировать их решение. Причем данная практика применялась вне зависимости от величины (сложности) проблемы.

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

Решение

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

Выводы

Применяйте принцип Zero Inbox для небольших проблем, то есть решайте такие проблемы здесь и сейчас.

Подробнее о принципе Zero Inbox см. в статье Резюме докладов на Microsoft TechEd Russia 2011 в разделе “Успеть все! Секреты управления временем для ИТ-руководителей».

Рецензируйте любую выполняемую работу и создаваемые артефакты

Ситуация

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

Решение

Командой было принято решение о том, что любые задачи, над которыми ведется работа в рамках проекта, а также любые создаваемые артефакты должны проходить через рецензирование. Например:

• аналитик передает новое требование на рецензирование разработчику;
• тестировщик передает на рецензирование разработанный тестовый случай аналитику;
• менеджер передает разработанную им концепцию на рецензирование всей команде, получает отзывы и в соответствии с ними вносит изменения;
• инженер, внесший малейшее изменение в тестовое окружение, публикует информацию об этом через рецензирование его работы другим членом команды.

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

Выводы

1. Проводите через рецензирование любые работы и артефакты, создаваемые в рамках проекта.
2. Используйте рецензирование, в том числе и для обмена навыками и информацией об изменениях в проекте внутри команды.
3. Пропагандируйте среди коллег положительное влияние рецензирования на качество их работы.

Растите и изменяйте процессы и регламенты согласно текущим потребностям

Ситуация

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

Решение

Было решено найти варианты упрощения работы с рабочими элементами системы учета в процессе рецензирования и сократить состав задействованных участников до 1 члена команды и лидера команды разработки. Это позволило внести изменения, повышающие эффективность процесса рецензирования именно в тот момент, когда это потребовалось и в необходимом объеме.

Выводы

1. Процессы и регламенты создавайте и меняйте эволюционно согласно растущим потребностям, а не создавайте сразу и наперед.
2. При разработке процессов учитывайте экономику проекта, потому что слишком сложные и дорогие процессы мешают работе и не будут исполняться.
3. Не бойтесь менять процессы: это не разовый, а постоянно (регулярно) выполняемый акт в рамках принципа, описанного циклом Деминга.

Развитие команды

Выстраивайте правильную пирамиду развития людей

Ситуация

В начале проекта команда включала консультантов, которые были примерно одинаковы по накопленному опыту и компетенциям. Это упростило коммуникации на старте проекта: “равным” проще договориться – но при этом не было стандартной схемы развития группы в целом за счет индивидуального развития каждого, которое заключается в одновременной возможности каждому члену группы как учиться у кого-то более опытного, так и учить кого-то менее опытного.

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

Решение

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

Выводы

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

Уделяйте особое внимание развитию людей и процессов в команде

Ситуация

Если посмотреть на то, кем был каждый член команды до начала проекта и кем является на текущий момент, то можно увидеть, что за год работы каждый член и вся команда в целом сделала большой эволюционный скачок. Причем данный эффект был отмечен не только внутри компании, но и людьми извне (сообщество разработчиков по развитию инженерных практик Russian Software Craftsmanship Community, активными участниками которого являются члены команды).

Решение

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

Выводы

1. Не поддавайтесь рутине и авралу, обязательно уделяйте серьезное внимание вопросам развития команды и людей.
2. Используйте принципы Y-менеджмента и самоорганизации команды.
3. Используйте неформальную обратную связь для развития людей в команде.
4. Используйте ретроспективы для эволюции команды в целом и ее процессов.
5. Не стесняйтесь поднимать “острые” вопросы на ретроспективе.
6. Организуйте разбор ситуаций на ретроспективе в следующей последовательности: проблема/успех, причины, решения. Обязательно назначайте конкретных исполнителей за внедрение этих решений.

Систематизируйте ввод в строй нового сотрудника

Ситуация

При расширении команды возник вопрос о том, как вводить в проект новых сотрудников компании, а также каким образом сделать это эффективно и с минимальными трудозатратами для всей команды.

Решение

Для решения этой проблемы командой была разработана методика ввода в строй новых сотрудников, включающая в себя:

1. Выделение определенного члена команды в качестве ментора сотрудника, то есть члена команды, отвечающего за развитие нового сотрудника на период испытательного срока.
2. Программу обучения сотрудника на первые 2 недели работы, плавно вводящую нового сотрудника в проект, начиная от описания бизнеса компании, назначения и структуры проекта и заканчивая стандартами программирования.
3. Методику последующего обучения сотрудника на практике, включающую, например, парное программирование.

Эта методика была проверена на практике и получила положительный отзыв: как со стороны участников команды, так и со стороны обучаемых сотрудников.

Выводы

1. Систематизируйте ввод нового сотрудника в строй, начните этот процесс с целей и бизнеса проекта и плавно погрузите сотрудника в технические детали.
2. Планируйте работы по вводу в строй нового сотрудника явным образом, чтобы учесть трудозатраты команды и чтобы новичок не сидел без дела, потому что всем не до него.
3. Используйте специальные техники для более эффективной передачи знаний новым сотрудникам (например, парное программирование, обучающие видеозаписи и т.п.).

Инженерные практики

Автоматизация рутины повышает мотивацию

Ситуация

При разработке продукта особое внимание было уделено качеству. Команда изначально ориентировалась на автоматизацию тестирования и сборки продукта. Это делалось для того, чтобы:

1. Формализовать алгоритм выполнения данных действий и исключить возможность ошибки при периодическом его выполнении.
2. Получить значительную экономию времени за счет того, что после автоматизации данных действий члены команды не привлекаются к выполнению этих действий.

Практика подтвердила, что данное решение было правильным.

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

Решение

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

Выводы

1. Автоматизируйте любую рутинную деятельность команды, которую можно автоматизировать.
2. Автоматизация исключает возможность появления ошибок, экономит время в будущем.
3. Мотивация разработчиков или тестировщиков повышается, если их рабочее время посвящено выполнению интересных задач по разработке или исследовательскому тестированию, а не только выполнению рутинной деятельности.

Старайтесь контролировать среду разработки и тестирования

Ситуация

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

Решение

Команда обеспечила себе максимально возможный при существующих ограничениях контроль среды тестирования, к примеру: тестовое окружение на виртуальном окружении, независимом от инфраструктуры других команд разработки, аналогично сборочный конвейер, внедрила собственную систему управления конфигурациями инфраструктуры (Configuration Management Database, CMDB). Все это позволило быстрее решать проблемы с тестированием продукта.

Выводы

1. Старайтесь создавать условия для полного контроля среды тестирования разработчиками продукта.
2. Оценивайте риски, связанные с использованием инструментов, которые вам не подконтрольны.

Целесообразность проведения больших объемов работ по пересмотру кода решайте коллективно

Ситуация

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

Решение

Было принято решение о том, что целесообразность проведения крупного refactoring здесь и сейчас определяется коллективно всей командой разработки. И, как минимум, выделяется в отдельную задачу для визуализации и контроля работ по ней.

Выводы

1. Принимайте коллективное решение о целесообразности крупного refactoring здесь и сейчас.
2. Выделяйте отдельные задачи для этих целей для визуализации и контроля хода работ по refactoring.