Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер Страница 20
Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер читать онлайн бесплатно
Скрам-мастер – это масло, смазывающее маховик работы любой команды. Он работает вместе с командой, поэтому из первых рук получает информацию о том, как идет разработка проекта, и старается найти способы, как улучшить этот процесс.
Самая важная часть работы Скрам-мастера – это быть инструктором в вопросах гибких подходов для владельца продукта и команды, а иногда даже для организации, а также фокусироваться на долгосрочном планировании, эффективных отчетностях и получении обратной связи.
Если Владелец продукта – это мозг проекта, то Скрам-мастер отвечает за ежедневное функционирование проекта, создавая наилучшее окружение для работы команды. Главная задача – убедиться в том, что команда способна справиться с настоящей работой.
Блистательный эффект
Скрам-мастера – невоспетые мастера на все руки: посредники, помощники, советники и разрешители проблем.
Хороший Скрам-мастер делает работу над проектом намного проще.
В Agile «команда разработки» – собирательное понятие, обозначающее всех, кто нужен, чтобы работа была выполнена. Основная роль команды – взять идеи из журнала требований и претворить их в жизнь. Команда способна самоорганизоваться – это означает, что каждый участник полагает остальных профессионалами, способными выполнять свою работу хорошо без дополнительного микроменеджмента.
Команда разработки – это двигатель проекта, это талантливые и многоплановые люди, полностью сосредоточенные на выпуске продукта. Ключевой способностью команды является обладание смежными навыками – это означает, что ситуации, когда кто-то один способен сделать работу в одиночку, должны возникать редко: члены команды используют свои знания, чтобы помогать друг другу.
Само собой, команда разработки должна быть мотивирована на наилучшие результаты. Контроль работы осуществляется самими членами команды, и никто, кроме самой команды, не знает, может ли она работать еще лучше. У Владельца продукта есть видение проекта, Скрам-мастер предоставляет необходимую помощь, но за результаты своей работы члены команды отвечают перед собой и друг другом.
Блистательный эффект
Собирать огромную команду неэффективно и нерационально. Общение, отношения и, следовательно, работоспособность команды страдают, если она слишком велика. «Руководство по Скраму» советует оптимальный размер команды в шесть человек – плюс-минус трое; время от времени эти рекомендации варьируются.
Исследования подтверждают эту мысль, так что не позволяйте команде разрастись до двузначного числа.
События в Скраме простые, однозначные и всегда ограничены по времени. Они предназначены для создания структуры для проверки и адаптации участников к рабочему процессу без добавления бессмысленных формальностей. Скрам декларирует, что для правильной работы необходимо выполнить все пять мероприятий; отсутствие любого из них означает, что вы работаете не по методологии Скрам, и приводит к неэффективным методам работы, отсутствию прозрачности и путаницам. Обычно, если команда разочарована неким Скрам-событием и оно кажется бесполезным, это значит, что что-то идет не так.
Пять Скрам-событий:
• спринт – общий цикл для остальных событий;
• планирование спринта – происходит в самом начале работы;
• ежедневная летучка (дейли Скрам) – происходит каждый день (без исключений);
• обзор итогов – проводится в конце спринта;
• ретроспектива – подводит итоги.
Спринт – жестко фиксированный по времени, от одной до четырех недель, временной период (time-box) для всех остальных Скрам-событий. Обычно команды выбирают длину спринта в две недели, но идеальной продолжительности нет – во всех вариантах будут присутствовать и плюсы, и минусы. Если есть сомнения, лучше начать с одно- или двухнедельного спринта и посмотреть, как пойдут дела.
Спринты могут рассматриваться как возможность реализовать мини-проекты или могут быть обычной практикой в большом проекте по разработке, но не стоит часто изменять продолжительность новых спринтов. Поначалу ориентируйтесь на постоянство. Спринт начинается с решения о том, что именно поступает в работу, и заканчивается подведением итогов о созданном продукте. Ретроспектива поможет команде оценить результативность совместной работы и предложить улучшения.
Блистательный совет для сохранения времени
В «Руководстве по Скраму» не упоминаются пользовательские истории – у владельца продукта могут быть и другие способы объяснить свои идеи. Пользовательские истории в основном просто самый популярный метод.
Не распыляйтесь, тратя время на другие варианты, – идите по проторенному пути.
Планирование происходит в начале каждого нового спринта. Это возможность для команды просмотреть пользовательские истории, которые Владелец продукта уже уточнил и распределил по приоритетности, и решить, в каком порядке обрабатывать задания. Все обсуждения насчет сложности, рисков, размера, трудозатрат, бизнес-ценности и прочих нюансов проходят на этом этапе. Цель команды – во всем разобраться и прийти по этим вопросам к согласию.
Главной характеристикой планирования является то, что основное управление отдано команде, а Скрам-мастер только помогает. Раньше руководитель проекта просто говорил команде, что должно быть сделано и когда, в то время как планирование в Agile позволяет команде решать, что должно быть снято из списка приоритетных задач, что позволяет специалистам планировать реальные сроки выполнения.
Это не значит, что нужно выбрать легкую цель, – Скрам-мастер для того и работает вместе с командой, чтобы сложная конечная цель была достижимой, – но последнее слово все равно остается за командой, если они говорят, что за данное время невозможно выполнить больше задач.
Также во время планирования нужно убедиться в том, что каждая задача в журнале требований должна быть проверена на понимание перед включением в спринт. Очень важно, чтобы бизнес отметил этот момент до того, как работа начнется, – любые недопонимания нужно устранять; именно для этого тут и присутствует Владелец продукта. Старайтесь не начинать спринт с сомнительных обещаний.
И как только пользовательские истории, которые войдут в спринт, согласованы – для команды и Скрам-мастера заканчивается время обсуждений и раздумий и начинается работа.
Блистательный пример
Команда разработки решает, какой объем работы войдет в спринт, но Владелец продукта и Скрам-мастер тоже принимают в этом участие.
• Начните с четкой цели спринта. Всем должно быть ясно, в чем эта цель заключается и как может быть измерена.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Comments