Как только команда решила рискнуть идеей, что гибкий подход будет, по крайней мере, лучше контролируемого хаоса статус-кво, терминология Agile начинает приобретать новое значение. Внезапно то, что просто менеджер говорил людям, что нужно делать, и команда, пытающаяся выполнить всю работу в срок, становится минным полем новых лейблов, процессов, ролей и инструментов. Это может пугать как менеджеров, так и членов команды.
Если вы хотите освежить в Agile , вы можете взглянуть на Agile Manifesto , где основные принципы Agile изложены людьми, которые кодифицировали эту концепцию. Для получения более подробной информации о двух подходах, обсуждаемых в этом эссе, вы можете посетить Scrum Methodology и Everyday Kanban , два сайта, которые предоставляют хороший обзор Scrum и Kanban. Вы также можете просмотреть некоторые другие статьи, опубликованные здесь, на SitePoint, о гибких подходах к управлению рабочим процессом.
Выбор процесса
Одно из первых решений — какой из вариантов agile наиболее подходит для команды.
Есть много популярных подходов, которые были формализованы, в дополнение к индивидуальным вкусам, которые в конечном итоге принимают многие компании.
Может быть сильный импульс к выбору подхода, который предлагает наименьшее количество отличий от того, что на самом деле не работало до сих пор.
Для некоторых компаний «стать гибким» означает разбрасывать вокруг себя несколько новых названий и терминов, не меняя при этом способа работы и не называя его гибким. Стоит дать вашей команде возможность сначала следовать законному гибкому рабочему процессу, обращая внимание на то, что работает и для кого.
Два самых популярных подхода к гибкому рабочему процессу — это Scrum и Kanban. Поскольку они оба являются гибкими, между процессами и инструментами, которые вы используете при реализации, есть много общего. Но Scrum и Kanban предоставляют разный набор преимуществ, оптимизированных для разных приложений.
Итерации или Ломтики
Хотя Scrum и Kanban являются законными и полными способами структурирования гибкого процесса, и есть преимущества (и недостатки при выборе одного из них над другим), стоит начать с чистой формы любого из подходов, прежде чем пытаться настроить их.
Оба подхода развивались и развивались на протяжении многих лет, и независимо от того, насколько глубоко вы погружаетесь в сорняки собственных офисных джунглей, маловероятно, что требования вашего проекта выходят за рамки того, для чего они были разработаны.
Для групп, желающих выпускать новые версии продукта в соответствии с регулярным графиком, и при этом адаптироваться к постоянно меняющимся рынкам, Scrum является отличным выбором.
Scrum сочетает в себе четкий набор ролей, ритуалов и артефактов, которые могут быть приняты и использованы немедленно.
Scrum достаточно универсален, чтобы обслуживать команды от пяти до пяти человек и может охватывать тысячи организаций.
Он поддерживает автономию для разработчиков, прозрачность для менеджеров и подотчетность для организации в целом.
Благодаря тому, что команда берет на себя согласованный контракт на ограниченный по времени спринт, а затем выполняет итерацию в зависимости от того, насколько хорошо все прошло, Scrum позволяет команде непрерывно адаптироваться, не мешая самостоятельности каждого члена команды.
Команды, работающие в сервисном режиме, часто предпочитают Канбан, а не Скрам.
В то время как Scrum оптимизирован для регулярной доставки итераций продукта клиентам, Kanban поддерживает постоянный поток независимых улучшений и оптимизаций.
Одним из ключевых преимуществ Kanban является то, что он сосредоточен на контроле объема работы, выполняемой командой в любой момент времени.
В то время как Scrum и Kanban извлекают выгоду из четко определенных историй, которые могут быть закончены и доставлены независимо, Scrum оставляет команду решать, над чем работать одновременно, в то время как Kanban сосредотачивается на ограничении количества элементов, которые в команде находятся в процессе выполнения.
Разница может показаться незначительной, особенно если смотреть на доску канбан и доску Scrum рядом.
Ключевым отличительным фактором является то, что Scrum измеряет устойчивые уровни производительности с точки зрения скорости команды и контролирует количество гибких очков, которые команда обязуется набрать во время спринта.
Канбан контролирует устойчивую работу и ограничивает количество историй, над которыми команда будет работать одновременно.
прозрачность
И Scrum, и Kanban приняли практику ежедневных встреч, во время которых члены команды сообщают о том, что они сделали со времени последней встречи, что они планируют сделать до следующей, и есть ли у них какие-либо блокировщики. мешая им работать в полную силу. В обоих подходах разработчики — единственные, кто должен отчитываться во время ожидания, в то время как владельцы продуктов и менеджеры обращают внимание и используют время сразу после завершения, чтобы следить за конкретными проблемами.
Скрам дает команде полный спринт, чтобы решить, как самостоятельно управлять работой, прежде чем размышлять, в то время как Канбан тщательно контролирует рабочий процесс в команде каждый раз, когда начинается новая история.
Это имеет серьезные последствия для совместной работы менеджеров, владельцев продуктов и разработчиков.
С Kanban команда может динамически корректировать уровень выполняемой работы, чтобы избежать простоя или переутомления разработчиков, и это то, что может быть отслежено руководством.
В Scrum команда самостоятельно корректирует незавершенную работу, основываясь на количестве историй, которые они посвятили спринту, с целью заставить каждую историю соответствовать их согласованному определению выполненного.
Ритм
Ритм Scrum согласовывается командой в зависимости от типа выполняемой работы и обычно длится от двух до четырех недель.
Каждый спринт, команда проходит ряд ритуалов, чтобы продемонстрировать ценность, которую они предоставили, учиться на том, что работало хорошо, а что могло бы пойти лучше. Затем они передают новый набор историй для следующего спринта.
Поскольку в Scrum используются временные итерации, ритуалы включаются в процесс.
Канбальные итерации гораздо более гибкие.
В Канбан решение о том, когда приостанавливать рабочий процесс ради размышлений и согласия, может приниматься по дате, вехе или другим метрикам, согласованным группой, до начала работы.
Риск для команды Kanban заключается в том, что нерегулярность процесса может побудить их пропустить или уделить мало внимания размышлениям, необходимым для ускорения и улучшения гибкого процесса.
Создание гибкой работы
Для вашей команды важно тщательно продумать, какой подход наиболее целесообразен, учитывая то, что вы пытаетесь достичь.
Если вы разрабатываете продукты, вы можете найти Scrum более вероятным выбором. Если вы предоставляете услуги, возможно, Канбан подойдет вам лучше.
Разные команды в разных обстоятельствах требуют разных подходов.
К счастью, в основе agile лежит ожидание того, что ваша команда узнает из того, что работает, чтобы вы могли принимать решения о том, что сохранить и что изменить, если вы адаптируетесь гибко.
После того, как команда эффективно и гибко проработала достаточно долго, чтобы знать свои собственные ритмы, законный гибкий процесс может адаптироваться к широкому спектру реализаций.
Но самоосознание, необходимое для того, чтобы воспользоваться преимуществами гибкости agile, не следует рассматривать как лицензию для выбора аспектов agile из того или иного подхода и для попытки создать что-то новое с самого начала.
Я рекомендую вам попробовать свой любимый вкус agile в чистом виде в течение нескольких циклов, прежде чем решить, подходит ли он вам.
Если вы делаете это добросовестно, всегда будет возможность отразить и пересмотреть ваш подход на следующей ретроспективе.