Скрам

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

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

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

Из этого опыта команда разработки узнала, как инструменты инспекции и адаптации скрама влияют на его некоторые практики. Первоначально команда считала, что ежедневный скрам – лишь короткая 15-минутная встреча, на которой участники будут синхронизировать свою работу и планировать день. Однако результатом этого события должно стать критически важное состояние: команда разработки точно знает, что происходит, а что – нет. Без инженерных практик, ведущих к такому пониманию, команда не сможет достоверно синхронизировать свою работу. Следующие несколько недель участники команды и я изучали инженерные практики, которые можно было применять в проекте. Я помог команде лучше понять среду разработки и наладить процессы, необходимые для работы по скраму. Я также помог понять некоторые полезные правила экстремального программирования, в частности коллективное владение кодом, стандарты кодирования и парное программирование[21].

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

Учимся самоорганизации

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