Масштабируем Scrum (но не так, как вы подумали)
Уже более года я работаю с клиентами, у которых есть проблемы с масштабированием Agile. Но не тот вид проблем, о котором все говорят: один продукт и множество команд. Нет, всё это время я пытался придумать способ, как быть, если у вас одна команда, которая поддерживает множество продуктов с разными архитектурами, заказчиками, технологиями и прочим. И вот чему мне удалось научиться. Я гуглил и гуглил, спрашивал людей, читал книги, в которых предположительно должна была описываться подобная ситуация, но не особенно преуспел. Очевидно, я читал какие-то не те книги, блоги, твиты и тому подобное, потому что по данной теме нашлось не так уж много. Если вы посмотрите печально известное видео моего коллеги Хенрика Книберга «Владение продуктом в двух словах», то всё покажется довольно простым. Однако иногда жизнь совсем не так проста, как 15-минутное видео. В чём проблема?Сам факт, что вашей команде приходится разрабатывать и поддерживать несколько продуктов, приводит ко множеству проблем. Некоторые из них попроще, некоторые посложнее. Наиболее лёгкие в решении проблемы - это, например, понимание среды разработки. Разные языки программирования, разные среды тестирования и сборки, разные способы развёртывания продукта и т.д. Подобного рода проблемы решить довольно просто. Постарайтесь сделать работу над разными продуктами настолько однородной, насколько это возможно. Документируйте то, что трудно запомнить, минимизируйте стеки разных технологий, где это возможно, и т.д. Конечно, это будет непросто, поскольку разные продукты могут относиться к разным поколениям. И нет ничего необычного в том, что одна команда поддерживает гремучую смесь систем на основе PL/SQL, C#, VB, Java, JavaScript и Rails. Самая большая проблема, с которой мне доводилось иметь дело, заключалась не в технологиях. Она была в том, что команда, работающая над несколькими продуктами, имеет тенденцию переставать быть командой, распадаясь на несколько отдельных единиц. Например, Джейн проработала в этой компании десять лет, она прекрасно знает PL/SQL-систему, поэтому она решает всё, что связано с этой системой. А Джо нравится Rails, и он так и норовит забрать себе всю работу, с этим связанную. Список можно продолжать. Рано или поздно у людей появляются свои любимчики, и они забывают, как работать с другими системами. Хуже того, иногда менеджмент или, возможно, владелец продукта сами пытаются привить такое поведение: «О’кей, Джейн у нас самая опытная по PL/SQL, ей с этой системой и работать». Прощайте, самоорганизация и страховочные варианты. В итоге вы получаете не команду, а группу людей, работающих над разными вещами, которые по недоразумению сидят вместе. Планёрки становятся весьма утомительными, потому что всех интересуют лишь свои части работы. Остальное время, пока одни пытаются вести осмысленную дискуссию, другие смотрят в телефон или щёлкают по клавиатуре. Они теперь работают в отдельных, несвязанных между собой подкомандах. Владелец продукта становится владельцем командыРекомендации скрама разрабатывались для одной команды программистов, одного владельца продукта и собственно одного продукта. Если же у вас много продуктов, для владельца продукта становится трудным, если не невозможным, держать руку на пульсе всех пожеланий заказчиков, всех видений и сценариев, детализируя при этом пользовательские истории, высчитывая экономическую выгоду - в общем, занимаясь всем тем, что входит в обязанности владельца продукта. Чтобы команда не сломалась на переключении задач, важно, чтобы все понимали, на чём фокус текущего спринта. Поэтому приоритеты становятся ещё важнее, чем обычно, - но не столько приоритеты между пользовательскими историями внутри продукта, сколько приоритеты между самими продуктами. Это приводит к тому, что владелец продукта превращается больше во владельца команды, в том смысле, что он оберегает команду, расставляя приоритеты до того, как начнётся планирование спринта. Он должен удостовериться, что все заказчики обращаются к нему, а не непосредственно к команде. Кроме того, он должен убедиться, что все заинтересованные стороны согласны с приоритетами между продуктами. Предлагаемое решение: уплотнение времениПредположим, у вас есть четыре продукта, которые поддерживает одна команда, а длина одного спринта - две недели. Если вы будете работать только над одним продуктом за раз, то каждый продукт окажется в центре внимания примерно раз в два месяца. И это «гибкая разработка»? Хуже того, мне доводилось видеть спринты одной системы, которые были сорваны багом, обнаруженным при боевой эксплуатации другой. Естественно, заказчики той первой были в ярости и требовали, чтобы команда в следующий спринт занималась только их продуктом, чтобы компенсировать тот сорванный спринт. И тогда вообще всё летело к чёрту. Одним из решений данной проблемы, которое я использовал, было уплотнение времени. Что это значит? В каждом спринте фокус идёт на один продукт, но остаётся место заниматься понемногу и другими продуктами. Опять же, владелец продукта должен действительно хорошо разбираться во всех мелочах, чтобы можно было сделать что-то маленькое по паре продуктов и нечто большее по тому, который в фокусе. Инциденты и багиЯ видел, какой эффект оказывают в данной ситуации баги, и у меня не хватит слов, чтобы в достаточной степени подчеркнуть, как важно их избегать. По максимуму вложитесь в автоматизированное тестирование, чтобы по возможности убрать ручное регрессионное тестирование. Кроме того, сценарии тестирования - это тоже хороший способ помнить, что делает данный конкретный продукт. Поэтому просмотр кода тестовых сценариев - это самый быстрый способ получить представление о продукте. Помимо этого, используйте коллективное программирование или хотя бы парное программирование, чтобы за кодом следило больше глаз во избежание ошибок и для того, чтобы избавиться от пересмотра кода. Предлагаемое решение: разделите свою командуВ команде одного из клиентов было десять человек, которые занимались несколькими продуктами в различных сегментах. Тут были и глобальная поддержка пользователей, и CRM-системы, и офисные системы собственной разработки - слишком много всего, чтобы все члены команды могли понимать, что происходит во всех этих разных областях. Деление на замкнутые подкоманды было очевидным, и люди были демотивированы тем фактом, что им приходится слушать, оценивать, обсуждать то, о чём они не имеют ни малейшего представления. Но решение, на самом деле, было в том, чтобы сохранить подкоманды! Мы разделили команду на три, где одна стала командой CRM, одна - командой глобальной поддержки пользователей, и ещё одна взяла на себя всё остальное. Таким образом как минимум две команды из трёх могли целиком сосредоточиться на одном продукте, в то время как у последней всё-таки осталась необходимость поддерживать много продуктов. Поэтому третья команда сосредоточилась на унификации архитектуры и стека технологий там, где это возможно. Результатом стали довольные люди, эффективные совещания и лучшая продуктивность. Члены команды наконец-то поняли, на чём должно быть сосредоточено их внимание. Подводя итогиМасштабирование Agile - это не только использование новейших фреймворков, чтобы понять, как выпустить релиз усилиями ста с лишним команд. Иногда вам приходится разбираться с ситуациями, где масштабируется количество продуктов. Я пытался решить это, разделяя большие команды и избегая замкнутых подкоманд внутри команды. Кроме того, когда в одном спринте вы фокусируетесь на одном продукте, но оставляете место для незначительных изменений в остальных, вы, как минимум, сохраняете какую-то гибкость. Всё это основано на моём опыте.
Автор: Микаэль Бродд Оригинал: http://blog.crisp.se/2015/12/08/mikaelbr[...]aling-agile-but-not-in-the-way-you-think Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
