Все о SCRUM. Изучение, разработка, интеграция

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

Если у истории отсутствует условие приемки, это не ошибка, а новая пользовательская история. В бэклог вносятся только незначительные ошибки, которые не требуют дополнительного условия принятия.

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

• Ошибка в существующем коде

Если команда внедрила технику разработки через тестирование, она сначала пишет модульные тесты, которые воспроизводят ошибку (красный этап), а затем пишут код для прохождения тестов (зеленый этап). Таким образом, команда улучшает общее качество ПО.

19.5 Антипаттерны

19.5.1 Архитектор в башне из слоновой кости

Ситуация. Архитектор, принимающий важные решения, не состоит в команде и не участвует в коллективной работе.

Последствия. Команда вынуждена соглашаться со всеми решениями. Она демотивирована и теряет способность проявлять инициативу.

Как сделать лучше? В Scrum-команде отсутствует роль архитектора. Agility на практике означает, что эксперт может подавать пример и пачкать руки, при этом он активно сотрудничает с другими участниками команды.

19.5.2 Тест в следующем спринте

Ситуация. Начинающие Scrum-команды не завершают истории в течение спринта. Некоторые истории длятся спринтами!

Последствия. Участники команды должны возвращаться к коду, написанному в прошлом спринте.

Как сделать лучше? Такого рода проблема вызвана разделением ролей разработчика и тестировщика. Если тестировщик получает программное обеспечение для тестирования в самом конце спринта, в лучшем случае он обнаружит ошибки, которые уже не сможет исправить до завершения спринта. Скорее всего, он просто перенесет тесты на следующий спринт. Практики BDD и роение помогают избежать этой проблемы.

19.5.3 Работа в одиночку

Ситуация. Все участники команды работают по одному.

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

Как сделать лучше? Лучшим решением этой проблемы будет предложение другому участнику работать в паре.

Это залог успеха компании Menlo, систематизировавшей практику парного программирования. [Шеридан, «Joy, Inc.»].

19.5.4 Код, написанный на коленке

Ситуация. Те, кто разрабатывает ПО, иногда воспринимаются как исполнители. Их подталкивают к быстрому написанию кода в ущерб качеству.

Последствия. Накапливается технический долг.

Как сделать лучше? Постоянно развиваться в применении практик разработки.

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

Движение Software Craftmanship зародилось с целью продвижения этой идеи, которая была сформулирована в Манифесте Software Craftsmanship [60].

Чтобы идти дальше

Книги

‣ Ричард Шеридан «Работа мечты. Как построить компанию, которую любят», МИФ, 2014

‣ Ален Саке, Mettre en œuvre DevOps, Dunod, 2018.

‣ Corey Haines, Understanding the Four Rules of Simple Design

Онлайн-ресурсы

‣ Избранные статьи, переведенные веб-сообществом Les Traducteurs Agiles; https://www.les-traducteurs-agiles.org/livre-scrum-5ed/

‣ Блог Scrum, Agilité & Rock’n roll: http://www.aubryconseil.com/pages/Livre-Scrum

20 Kanban в дополнение к Scrum

Scrum кажется простым. Но вот уже двадцатую главу я стараюсь объяснить, как лучше его применить в работе. Kanban отчасти похож на него, и его столь же сложно описать. Он был создан Дэвидом Андерсоном несколько лет назад и с тех пор сильно изменился. Первоначально Kanban рассматривался как Agile-метод, основанный на концепции вытягивающей системы [61], которую впервые применила Toyota для разработки программного обеспечения. Сближение со Scrum дало гибридный термин ScrumBan, а также множество идей, изложенных в том числе в книге «Kanban & Scrum, Getting the best of both». В 2009 году я участвовал в переводе этой книги и докладывал эту тему на конференциях.