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

Обнаруживаемые ошибки вносились в систему отслеживания дефектов. Одни ошибки команда тестирования находила при регрессионной проверке создаваемого инкремента продукта. Другие были ошибками Y2K и выявлялись в ходе их постоянного поиска для снижения возможных последствий неправильной работы программного обеспечения в связи с этой проблемой. Третья группа ошибок возникала при установке и тестировании релизов Y2K на площадках заказчиков. Изначально Medcinsoft намеревалась исправить все ошибки и дефекты вплоть до финальной версии релиза Y2K, запланированной к выпуску 1 октября 1999 года. Но такой план был отвергнут клиентами. Они хотели как можно скорее обезопасить себя, «задраив люки» задолго до начала 2000 года. Чтобы успеть в более сжатые сроки и повысить целостность каждого релиза, Джуди анализировала новые дефекты перед ежедневным скрамом, а затем добавляла все критические и высокоприоритетные ошибки в бэклоги спринтов различных команд, работавших над этим релизом. Этим действием Джуди явно нарушала правило скрама, согласно которому никакая внешняя работа не может добавляться в спринт команды после его начала. Тем не менее другая практика скрама – «руководствуйся здравым смыслом» – одержала верх, поскольку поставка новых релизов без незамедлительного устранения дефектов просто впустую потратила бы время клиентов и спровоцировала бы дополнительные проблемы.

Джек установил скрам-командам следующие правила для управления своим временем и работой, сказав, что задачи Y2K имеют наивысший приоритет. Если они выделили только 50 % своего времени на задачи спринта, а оставшиеся 50 % времени работали над другими вещами, то о последних можно забыть, пока не будут исправлены все ошибки и дефекты Y2K. Если команда разработки была загружена задачами Y2K на 100 %, то участники команды должны пойти в остальные команды и пригласить других инженеров помочь устранить все ошибки Y2K до последней.

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

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

Когда я рассказал эту историю на встрече скрам-мастеров в Милане в июне 2003 года, Мел Пуллен отметил, что считает практику скрама скрамов противоречащей принципам самоорганизации и самоуправления скрама. Иерархические структуры навязаны руководством, утверждал Мел, а не теми, кто фактически выполняет работу. Почему бы не дать каждой команде выяснить, с какими другими командами нужно сотрудничать и координировать работу и где команды зависимы? Либо скрам-мастер сможет указать на зависимость от другой команды, либо команда разработки сама столкнется с зависимостью в процессе работы. Наткнувшись на зависимость, команда может отправить участника в качестве «цыпленка» на ежедневный скрам другой команды, работающей над зависимостью. Если никто не работает над этой зависимостью, команда может попросить владельца продукта создать соответствующий элемент бэклога продукта с высоким приоритетом. Скрам-мастер может либо позволить первой команде самостоятельно решить проблему зависимости, либо помочь сформировать другую команду для этого.

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

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

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