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

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

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

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

Из этого опыта команда разработки узнала, как инструменты инспекции и адаптации скрама влияют на его некоторые практики. Первоначально команда считала, что ежедневный скрам – лишь короткая 15-минутная встреча, на которой участники будут синхронизировать свою работу и планировать день. Однако результатом этого события должно стать критически важное состояние: команда разработки точно знает, что происходит, а что – нет. Без инженерных практик, ведущих к такому пониманию, команда не сможет достоверно синхронизировать свою работу. Следующие несколько недель участники команды и я изучали инженерные практики, которые можно было применять в проекте. Я помог команде лучше понять среду разработки и наладить процессы, необходимые для работы по скраму. Я также помог понять некоторые полезные правила экстремального программирования, в частности коллективное владение кодом, стандарты кодирования и парное программирование [21] В оригинале эти правила звучат так: «Use collective ownership. Code must be written to agreed standards. All production code is pair programmed». Подробнее о них вы можете узнать по ссылке www.extremeprogramming.org/rules.html . .

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

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

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

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

Что стало результатом ретроспективы спринта? Многие в Service1st были рады помочь друг другу. Когда кто-то отставал, другие участники команды были рядом. Некоторые программисты были рады сидеть рядом с тестировщиками, потому что еще в процессе кодирования могли понять полный набор тестов, которые впоследствии будут применены к системе. Все были довольны, а очевидный прогресс достигнут уже через два спринта после начала цикла создания релиза. Один программист был в восторге оттого, что ему пришлось общаться и работать с проектировщиком, с которым он не обменялся и фразой за три года работы в Service1st.