Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

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

Команды в Service1st встречались каждый день. Скрам-мастер нескольких команд Алисия решительно и профессионально организовывала ежедневные скрамы, помогая командам завершить их в течение 15 минут. Поскольку команды заранее договорились об этом формате, она гарантировала, чтобы каждый ответил на три вопроса:

1. Что я сделал с момента последнего ежедневного скрама, чтобы помочь команде достичь цели спринта?

2. Что я планирую сделать сегодня и до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?

3. Мешает ли что-то мне или команде достичь цели спринта?

Во время отпуска Алисии ее замещал другой скрам-мастер – Джордж. Ему понравилось, насколько гладко прошел ежедневный скрам, но тем не менее его не покидало чувство, будто что-то упущено. Через несколько дней он заметил, что почти не слышал просьб или предложений о помощи. Не было никаких комментариев, которые ему пришлось бы просить обсудить позже, чтобы успеть за 15 минут.

Немного понаблюдав, Джордж догадался, в чем причина. Сообщая о прогрессе, участники команды разработки смотрели на Джорджа, а не на других участников. Они делали это, потому что отчитывались Джорджу, в котором видели своего менеджера проекта. Несмотря на уверения в обратном, участники команды все еще чувствовали, что Джордж отвечает за проект, и относились к ежедневному скраму как к собранию по статусу проекта, на котором они отчитываются. Они не верили, что ежедневный скрам – это событие, во время которого они синхронизируются друг с другом.

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

Извлеченные уроки

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

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

Собравшись, я повторил для команды концепцию готового к поставке инкремента продукта. Каждый спринт команда разработки обязуется превращать выбранный элементы продукта в такой инкремент. Для того чтобы функциональность была готовой к поставке пользователям, она должна быть чистой. Участники команды хотели знать, что я имел в виду под «чистой». Без дефектов? Я ответил утвердительно, добавив, что чистый код не содержит как ошибок, так и заумных программистских трюков, а также соответствует стандартам кодирования и прошел рефакторинг для удаления любых дублей и изменения плохо структурированного кода, он прост для чтения и понимания. Если код удовлетворяет всем этим требованиям, система более устойчива и проще поддерживается. Если нет, то код станет раздутым, нечитаемым и сложным для отладки, а разработка функциональности в будущих спринтах занимает все больше времени. Я также напомнил участникам, что скрам требует прозрачности. Когда команда разработки демонстрирует функциональность владельцу продукта и заинтересованным лицам на обзоре спринта, они имеют полное право предполагать, что работа завершена. Завершена – значит, не только код написан, но и написан в соответствии со стандартами, легко читается, претерпел рефакторинг. Значит, компонент протестирован, автоматический тест написан и пройден, функциональность проверена. Если это не так, команде нельзя демонстрировать функциональность, потому что в этом случае зрители будут предполагать другое.

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

Участники команды смотрели на меня смущенно. Они рассказали, что без особенных обстоятельств или указания они собирают систему только в конце шестимесячного цикла разработки релиза. Используя скрам, они планировали начать собирать систему с последней недели месячного спринта. Тогда-то они и приступили бы к чистке кода. Это откровение застало меня врасплох. Когда участники команды сообщали во время ежедневного скрама, что конкретная функция готова, ее код еще даже не был добавлен в единый репозиторий, система не была собрана и протестирована. Я уточнил, так ли это. На встрече неожиданно повисла тишина. Все осознали: есть проблема. Один участник команды разработки, Джареш, поделился, что обычно он дорабатывает локальную копию кода от 5 до 10 дней и только потом отправляет изменения на сервер. Он поинтересовался, как часто он может возвращать [20] На английском языке эти операции систем контроля версий называются update/check-out и commit/check-in. Разработчики не переводят их на русский язык. измененный код в единый репозиторий? Я спросил, как он понимает, что вносимые им изменения не противоречат коду, над которым работают другие разработчики при столь редких синхронизациях с базовой версией? Джареш ответил, что, если будет возвращать изменения кода часто, ему придется устранять разногласия между фрагментами кода ежедневно, а внося изменения на сервер только после завершения разработки функции, он может производить такую корректировку лишь один раз.