Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]
- Название:Скрам [Гибкое управление продуктом и бизнесом] [litres]
- Автор:
- Жанр:
- Издательство:Литагент Альпина
- Год:2019
- Город:Москва
- ISBN:978-5-9614-2860-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres] краткое содержание
Автор рассказывает, как эффективно управлять сложными, громоздкими проектами и изменяющимися требованиями к продукту; упрощать организационную структуру с помощью самоуправляемых команд разработки; получать более четкие описания требований и внятную обратную связь от клиентов и заказчиков.
Вы узнаете, как эффективнее планировать работу над проектом, научитесь избегать ошибочных действий, используя регулярную инспекцию, а также увеличивать отдачу от инвестиций.
Скрам [Гибкое управление продуктом и бизнесом] [litres] - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Ирен попросила участников команды разработки сообщить о конкретных пройденных тестах и конкретных выявленных ошибках, попросила определить тесты для каждой ранее закодированной функции и добавить их в бэклог спринта. Она также попросила команду создать метрики тестирования и дефектов. Ирен хотела, чтобы команда разработки знала количество запланированных тестов, пройденных тестов, выявленных ошибок, исправленных ошибок и количество ошибок, которые останутся неисправленными в конце спринта. Она хотела, чтобы участники команды понимали уровень качества создаваемого ими продукта. Ирен учила команду, которая ранее всегда рассчитывала на группу тестировщиков, брать ответственность за тестирование и качество продукта на себя.
Перед следующим ежедневным скрамом Ирен разместила обновленный бэклог спринта на стене в комнате команды. Когда каждый участник команды сообщал о конкретных тестах и ошибках, над которыми работал, Ирен проверяла, чтобы они были указаны в бэклоге спринта. Она продолжала делать это на каждом ежедневном скраме, помогая команде фиксировать работу с тем уровнем детализации, который необходим для понимания происходящего. Команде разработке и Ирен удалось отслеживать тенденции дефектов: количество ошибок увеличивалось или уменьшалось; появлялись ли новые ошибки в результате исправления известных.
Рассказ каждого участника команды разработки в ходе ежедневного скрама должен быть конкретным. Обязательства перед командой реальны, только если их можно оценить. В отсутствие специфики команда Ирен скрывалась за многозначительной общей фразой «исправление ошибок», поэтому участники не могли планировать или синхронизировать свою работу.
Команда разработки была в восторге от того, что больше не находится под ограничениями чужого плана, в восторге от возможности заняться написанием кода, в восторге от возможности доказать, сколько может сделать за один спринт. Этот восторг и волнение привели к тому, что команда забыла о важных инженерных практиках.
Ирен научила команду управлять собой. Команда разработки должна была понять все аспекты выполняемой работы и часто сопоставлять их со своими задачами, чтобы в конце спринта поставить набор полноценных завершенных функций. Самоорганизация команд не означает отсутствие управления. Для управления собой команда должна создавать план работ и отчеты на его основе. Детали плана и отчетов должны быть достаточно конкретными, иначе они становятся бессмысленными. Команда должна иметь возможность синхронизировать свою работу.
Скрам-команда самоорганизуется: она берет на себя ответственность за планирование своей работы. Бэклог спринта – наглядное проявление этой ответственности команды. Я видел, как команды из трех очень опытных инженеров не использовали бэклог спринта, поставляя надежную рабочую функциональность по планам, хранящимся только в их головах. Тем не менее большинству команд разработки необходимо продумать и записать, что они делают, чтобы участники могли обращаться к плану по ходу работы. Ежедневный скрам синхронизирует работу участников только в случае, если работа тщательно продумана. В противном случае ежедневный скрам бесполезен.
Скрам-мастер должен обучать команду разработки и обеспечивать следование «принципу сашими». Иногда команды пытаются срезать углы. Иногда участники настолько привыкли к водопадным процессам разработки, что рассматривают тестирование как чужую проблему. Механизм определения того, выполняет ли команда всю необходимую работу, – бэклог спринта. Скрам-мастер должен убедиться, что задачи по тестированию отдельно указаны в бэклоге спринта до поры, пока команда не поймет значение слова «завершено». Как только команда осознает и привыкнет к тому, что разработка функциональности включает в себя анализ, проектирование, кодирование, тестирование и документацию, все эти уникальные водопадные подзадачи могут быть объединены в одну задачу бэклога спринта.
Выводы
Скрам работает только в том случае, если все характеристики проекта прозрачны для частых инспекций и адаптаций. Такие события, как обзор спринта и ежедневный скрам, и такие артефакты, как бэклог спринта и бэклог продукта, сохраняют все прозрачным для инспекции. Такие правила, как запрет на внешние отвлечения команды разработки во время спринта, не позволяют адаптациям превращать осмысленное движение к цели спринта в беспорядочное шатание, поскольку чрезмерная адаптация перегружает проект.
Скрам-мастер должен поддерживать прозрачность на достаточном уровне детализации. В MegaEnergy результаты от применения скрама стали заметны благодаря существующим механизмам отчетности. Рут смогла сделать обучение скраму легким для руководства, потому что использовала их язык. В MegaBank команда Хелен говорила с Джимом на одном языке, на котором и разработала понятный ему формат отчета. Только тогда Джим смог увидеть прогресс проекта. Чтобы обеспечить прозрачность в этих двух случаях, скрам-мастеру потребовалось адаптировать скрам к особенностям организации.
В примере с Service1st команда разработки сначала не обновляла бэклог спринта, скрывая отсутствие надлежащего планирования. Затем команда не внесла в бэклог спринта достаточно деталей, скрывая отсутствие прогресса в тестировании и исправлении ошибок и подрывая ценность ежедневных скрамов. Чтобы обеспечить прозрачность, скрам-мастеру потребовалось показать команде, насколько разработка и поддержание в актуальном состоянии бэклога спринта важны для самоорганизации. Бэклог спринта – это созданный командой план спринта.
Скрам-мастер должен быть бдительным. Если он не понимает, что происходит, этого не понимают и все остальные. Убедитесь, что все прозрачно. Найдите способ объяснить скрам на понятном для каждого языке. Некоторые люди хотят понять скрам и будут отслеживать прогресс проектов в терминах скрама. Другие готовы разбираться в проекте, только используя традиционную терминологию. Адаптация скрама к их словарю облегчает переход от традиционных процессов к скраму.
Глава 8
Команда разработки
Продуктивность скрама основана на простом подходе: сначала делай самые важные вещи и выполняй их очень эффективно. Владелец продукта упорядочивает требуемую и актуальную работу по приоритету в бэклоге продукта. Посмотрим, как команда оптимизирует свою производительность. Для упрощения предположим, что количество строк кода в день или количество функциональных единиц [19] Мера оценки количества бизнес-функциональности, которую информационная система предоставляет пользователю. Впервые предложена Аланом Альбрехтом в IBM в 1979 году. Для каждого функционального требования пользователя определяется количество элементов, относящихся к каждой из пяти категорий: ввод, вывод, запрос, внутреннее хранение, внешний интерфейс. Суммарная сложность функции оценивается в «функциональных единицах».
на один человеко-месяц являются хорошими метриками производительности. В скраме команда разработки сама определяет, как максимизировать свою производительность. Вся ответственность по планированию спринта и его исполнению целиком лежит исключительно на команде. Скрам-мастер и другие могут информировать, направлять команду, советовать ей, но ответственность за управление собой лежит на команде разработки.
Интервал:
Закладка: