Я работаю в сфере гибкой веб-разработки более 10 лет. Из них больше всего мне пришлось иметь дело с самым популярным agile-фреймворком — scrum( согласно версии One ).
Хочу поделиться с вами своими накопленными наблюдениями и выводами.
Начну с метафоры, так как иногда видел реализацию Scrum по такому сценарию:
- Перед схваткой : «развитие» похоже на ребенка – целеустремленная, но не умеет нормально ходить, но очень хочет учиться, чтобы достичь своей цели.
- Выполнение : приходит учитель( Scrum-тренинги, курсы, agile-коуч и т. д. ) и показывает, как нужно ходить.
Малыш доволен, двигается шажочками! Топ-топ-топ.
У нас спринты – мы идём!
- После внедрения : терпеливые стейкхолдеры говорят: «Ладно, дойдем до цели», на что получают «не давите на команду, мы движемся!» Развитие пишет интересные траектории и наслаждается процессом, но цель забывается.
- Скрам : дальше таблетка правды от бизнеса, scrum «мутирует» и позволяет бизнесу получить какой-то продукт от разработки.
И, к сожалению, галочка «мы работаем по Scrum» формально выставлена, но реальный потенциал команды разработчиков никогда не раскрывается, а окружающие говорят: «Scrum не настоящий».
На мой взгляд, это связано с тем, что Scrum часто реализуется «механически», без понимания сути фреймворка и его элементов.
Я хотел бы попытаться выявить симптомы «механической схватки»; понять недостатки этого подхода; понять, что может быть лучше «настоящей Scrum с Agile»; а также найти способы борьбы с симптомами схватки.
Я посвятю этому пару статей здесь и буду рад вашим комментариям и вопросам.
Для начала давайте определимся, что такое «механическая схватка».
С моей точки зрения, это когда все Scrum-роли, события и артефакты формально присутствуют, но ценности и цели забыты; когда нет гибкой культуры( те.
высокая степень осведомленности и принятия гибкий манифест И принципы ).
Когда нет понимания или даже попытки понять, зачем нужен тот или иной артефакт, или какова цель событий в Scrum. Прямо как робот в видео кто умеет делать сальто, но кто назовет его гимнастом? При внедрении Scrum важно донести до команды ее цели и ценности, а не только механику.
Культура Agile усиливает Scrum и делает его «реальным».
Scrum полезен для регулярного предоставления ценности и немедленного получения обратной связи.
Scrum — это скорость и разработка продукта.
Звучит тривиально в теории? Давайте попробуем разобраться, как работать по Scrum и при этом не потерять agile-культуру и ценности Scrum. При разборе элементов Scrum в ScrumGuide одни из первых, кто понял роли, мы сделаем то же самое.
материала было много, поэтому, чтобы можно было в нем разобраться, он разделен на три части( Часть 2 , Часть 3 ).
Начнем анализ с владельца продукта.
Владелец продукта – Владелец продукта (ВП):
Владелец продукта — лицо, ответственное за продукт; он «владеет» портфелем продуктов.Основным инструментом ПО является видение развития продукта, а основная задача – максимизировать ценность продукта, производимого командой.
Кажется, все просто: «Если ты смел, ловок и умел.
», но есть нюансы.
Не мы учим ПО, а учат ПМ (менеджера проекта), и зачастую ПМ становятся ПО, полагая, что это всего лишь смена имени, и старые подходы к работе можно оставить позади.
Но в Agile это не работает. А как надо? 
Взаимодействие заказа на заказ и продукта, бэклог
Признак: ОП не несет ответственности за состав бэклога, он просто работает над историями, полученными от других участников процесса.Или директор по закупкам не несет ответственности за определение приоритетности элементов невыполненной работы.
Его задача — довести бэклог до принятого в команде стандарта, но он не определяет содержание и приоритеты того, что будет делать команда.
Почему это плохо? : Если у ПО нет смелости или возможности создать продукт ( создавать бэклог, расставлять приоритеты, проводить эксперименты и т. д. ), это не ПО, а какой-то другой вид деятельности.
А без ПО скрам — не скрам.
Без создания журнала заказов заказчик не может нести ответственность за продукт. Если ПО не несет ответственности за бэклог, то принятие продуктовых решений требует дополнительных коммуникаций — это пустая трата времени, что негативно влияет на скорость работы команды.
Как мы относимся : необходимо предоставить ПО единоличное право принятия продуктовых решений и ответственность за состав бэклога.
Если ПО без принятия решений является установленным порядком, изменить ситуацию в одночасье сложно.
Когда PO является «прокси», тогда
- Либо убираем его из уравнения и делаем ПО фактически тем, кто отвечает за состав и приоритезацию бэклога.
Как команда разработчиков, так и специальная исследовательская группа могут помочь ЗП в работе с отставанием ( Команда открытия продуктов ), но ответственность за состав и качество резерва должна оставаться только на одном человеке - ПО.
- Либо мы постепенно учим/разрешаем/заставляем брать на себя ответственность и принимать решения( состав элементов бэклога, приоритет элементов и т. д. ) текущий заказ на покупку.
Важны итерации: закрепление успехов, получение обратной связи.
Почему это плохо? : Основная сила ПО — это видение продукта, понимание, зачем и для кого он создается.
Благодаря этому видению он может мотивировать и «заражать» людей вокруг себя.
Если нет видения, то продукт вряд ли получится нужным и хорошим.
С команды не будут «заряжать» за результат. Как мы относимся :ПО Важно сначала сформулировать видение продукта.
Он должен уметь форматировать лифтовая площадка рассказать, какую классную вещь он делает, почему и для кого.
Одна из ценностей agile — прозрачность.
Визуализируя различные артефакты разработки продуктов, мы стремимся к прозрачности.
Руководитель проекта может сформулировать свое видение и представить его команде.
Лучше, если работа над формулированием питча и видения лифта будет проводиться с некоторой периодичностью - как и другие скрам-мероприятия ( запланировал новую итерацию - сделал - собрал обратную связь ).
Симптом: ПО не прорабатывает элементы бэклога, не доводит их до принятых в коллективе договоренностей, не обновляет элементы бэклога, не очищает его, не очищает. очистка отставания .
Почему это плохо? : Если ПО в настоящее время не уделяет должного внимания отставанию на регулярной основе, ему все равно придется это делать( спринты нужно собирать ), но это будет напряженнее и дороже( например: коллективно наводить порядок в бэклоге во время планирования спринта ).
Накладные расходы на связь будут компенсированы за счет времени разработки.
ПО начнет терять доверие команды: он не вкладывает деньги в бэклог — команда не вкладывается в инкремент. Плохое/неактуальное отставание снижает прозрачность для всех заинтересованных сторон.
А схватка без прозрачности — это не схватка.
Как мы относимся : PO необходимо донести важность работы над бэклогом — статей, книг, тренингов и т. д. Необходимо разработать правила/регламенты проведения Product Backlog Refinement (PBR), чтобы эти встречи были полезными и эффективными; проведя мини-ретроспективу после ПБР, за несколько итераций можно качественно улучшить это мероприятие.
Совершенствовать механизм PBR необходимо всей командой, добиваясь максимальной синергии между ПО и командой разработчиков.
Бэклог требует регулярной очистки.
При получении свежей информации, помимо добавления в бэклог новых историй, необходимо не забывать удалять истории, потерявшие свою актуальность.
Бэклог должен содержать четкие и проработанные ( в рамках договоренностей конкретной команды ) предметов на 2-3 спринта, более глубоко проработанный бэклог может потерять актуальность.
В общем, бэклог должен содержать дорожную карту минимум на год, чтобы все заинтересованные стороны почувствовали, что у продукта есть будущее.
Разбивка бэклога на приблизительные приращения поможет команде заранее продумать цели спринта ( цели спринта ).
Признак: PO работает над несколькими несвязанными продуктами или с несколькими командами.
Как вариант, помимо основного ПО, он также играет еще одну роль в scrum-процессе (либо разработчик, либо SM).
Почему это плохо? : Работа ОП – непростая работа, требующая большой самоотдачи.
Если роль ПО совмещается с другими видами деятельности, то с большой долей вероятности это отрицательно скажется на качестве результата.
Опытные и зрелые ПО могут одновременно управлять несколькими продуктами и работать с несколькими командами, если эти продукты «связаны» или являются функционально схожими частями одного большого продукта.
Скорее всего, только очень и очень уникальные люди могут одновременно создавать, скажем, графический редактор для мобильных устройств и армейский авиасимулятор.
Чтобы быть эффективным, вам нужно сосредоточиться на одной цели, прежде чем жонглировать несколькими.
Как мы относимся : ПО должно критически относиться к своей продукции: насколько зрелым и четким является видение? Насколько команды понимают и принимают это видение? Насколько хорошо развит резерв? Прозрачно ли это для всех заинтересованных сторон? Есть ли дорожная карта продукта, она всем понятна? Понимает ли команда, что она будет делать следующие 2–3 спринта? Насколько хорошо известен пользователь и рынок? Каково качество взаимодействия с командой разработчиков? Если в любой из этих областей есть возможности для качественного улучшения, стоит оставить один продукт и сосредоточиться на нем.
Взаимодействие между ПО и командой
Симптом: ПО директивно управляет командой, фактически работая по классической схеме ПМ.ПО принимает все решения, даже самые незначительные, к нему обращается команда по любому вопросу.
Почему это плохо? : Если ПО занимается микроменеджментом внутри команды и принимает активное участие в развитии, то, с одной стороны, это демотивирует команду и не дает ей развиваться( нет самоорганизации, потому что ответственность за местные решения остается за ОО ), с другой стороны, это плохо для продукта, поскольку усилия ПО направлены внутрь процесса, и продукт может остаться без его внимания.
Как мы относимся : ПО нужно убить в себе ПМ, попробовать недирективные подходы в управлении и перестать воспринимать людей как ресурс.
Если между ПО и командой разработки выстраивается директивная схема управления, стоит привлечь внешнего или внутреннего фасилитатора, который сможет скорректировать взаимодействие.
Необходимо четко определить границы ответственности между ПО и командой разработки — это прозрачность.
Между ЗП и командой должны быть доверительные отношения: команда по большей части доверяет ЗП и его решениям по продукту, а ЗП доверяет команде и решениям, которые команда принимает для реализации элементов невыполненной работы.
У всех есть понимание, что работа ведется ради общей цели.
Одним из возможных инструментов ПО может стать «продуктовая» команда, в которую входят аналитики.
Когда гипотезы основаны на цифрах и данных, они вызывают больше доверия.
Главное для ПО — не забыть поделиться этими данными с командой разработчиков.
Если команда не является независимой, то ОП необходимо научиться делегировать полномочия.
Тогда команда будет вынуждена взять на себя принятие решений, а, как следствие, и ответственность, и постепенно она станет скрам-командой.
Симптом: ПО и команда разработчиков регулярно конфликтуют, постоянное противостояние, нет взаимопонимания.
Почему это плохо? : ПО и команда плывут в одной лодке, если между ними не налажена эффективная связь, то вряд ли такая лодка сможет уплыть далеко.
Много энергии будет потрачено на создание взаимодействий, а не на разработку продукта.
Цель ПО и команды одна, а значит регулярных конфликтов быть не должно.
Как мы относимся : Нам нужен опытный фасилитатор, который сможет выявить суть конфликта, снять его и построить рабочие отношения.
Если все усилия не приводят к взаимопониманию, то, возможно, стоит сменить тандемы.
Признак: ПО почти не общается с командой.
Например, он доступен только во время обязательных совещаний (планирование, обзор спринта).
Почему это плохо? : Команда создает новый сложный продукт ( Scrum — это основа для разработки, доставки и поддержки сложных продуктов.
), поэтому работает в условиях большой неопределенности.
Чтобы обеспечить максимальную ценность, им нужна информация, которой в большинстве случаев располагает только ЗП ( это его работа ).
При отсутствии информации могут быть сделаны неправильные предположения и решения, в результате чего будет потеряно драгоценное время на их исправление.
Как решить : ЗП должен быть доступен команде, но команда не должна этим злоупотреблять, иначе время ЗП будет потрачено только на разовые вопросы.
Необходимо разработать комфортный для всех формат взаимодействия, при котором команда оперативно получает от ПО необходимую информацию и решения, которые команда действительно не может принять самостоятельно.
Можно с некоторой регулярностью приглашать ОО на ретроспективы и обсуждать там вопрос частоты, инструментов и формата коммуникаций.
Признак: ПО не прививает и не поощряет культуру.
обратная связь в команде.
Или руководитель проекта дает одностороннюю обратную связь, отфильтровывая похвалу или критику.
Почему это плохо? : Когда руководитель проекта не дает регулярной честной обратной связи команде, это демотивирует команду.
Нет синхронизации между ожиданиями и результатами.
Команда не чувствует себя причастной, они фактически не являются создателями продукта, они просто выполняют свою функцию.
«Команда регулярно вносит приросты.
Команда получает регулярные и честные отзывы о своей работе», — кажется справедливой сделкой.
Как мы относимся : ПО, конечно, не должно обременять команду всем объемом информации, с которой он работает сам, всем, что он получает от пользователей и аналитиков.
Он должен агрегировать и предоставлять информацию, которая уже важна и понятна команде.
Хорошо придумывать разные форматы обратной связи, а не только исходя из сухих цифр( например: живое тестирование, собеседования и т. д. ).
Сама команда должна напоминать ОП о необходимости обратной связи: задавать вопросы, выстраивать регулярный процесс получения обратной связи.
Назначение PO «владельцем» мероприятия по обзору спринта и информирование его о потребности команды в обратной связи, по крайней мере, напомнит PO о необходимости работать над обратной связью и может способствовать более творческому подходу к обратной связи организации.
Взаимодействие ПО и пользователей, рынок
Признак: ПО не знает «своего» пользователя; продукт рассматривается как набор функций.PO игнорирует запросы пользователей и информацию от существующих пользователей.
Не общается с «живыми» пользователями.
Почему это плохо? : В первую очередь продукт создан для пользователя, у которого есть( возможно, он еще этого не знает ) потребность, удовлетворяемая продуктом.
А если вы не знаете и не понимаете пользователя, то невозможно «нести ответственность за достижение максимальной ценности продукта», как того требует scrum-гайд. Как мы относимся : Существует множество различных инструментов для проведения качественных исследований, таких как глубинные интервью, портреты пользователей, дорожные карты пользователей ( карта пути клиента ), инструменты для сбора качественная (против количественной) аналитика и т. д. и так далее.
Вам нужно попробовать разные инструменты и оставить те, которые полезны/работают для вашего продукта.
Большинство этих инструментов имеют визуализацию результата в качестве вывода; стоит разместить их перед командой, чтобы повысить прозрачность.
Эти артефакты следует время от времени обновлять.
Вы можете организовать исследовательскую группу ( команда по поиску продуктов ) для оказания помощи в проведении качественных исследований.
Если ЗП способен наладить взаимодействие с пользователем, то он может использовать этот контакт, например, на обзоре спринта: давая пользователю свежий инкремент, и команда будет выяснять, как пользователь справится с задачей, для которой они включена помощь в решении приращения.
Признак: ПО не исследует рынок/конкурентов.
Почему это плохо? : Продукт словно живет в вакууме и оторван от реальности; нужно быть провидцем, чтобы создать ценный продукт в таких условиях.
Как мы относимся : Владельцы продуктов могут использовать ряд практик для изучения и создания рынков.
Стоит попробовать разные и остановиться на тех, которые являются полезными.
В этой деятельности ОП могут оказывать помощь аналитики или группа специалистов.
Приятно время от времени поднимать глаза» голубые океаны «.
И конечно, стоит черпать вдохновение из тренингов, продуктовых митапов и конференций.
Заключение
Анализ остальных ролей появится в следующих частях.Теперь давайте разберемся, чем эта информация может быть вам полезна.
Мы рассмотрели некоторые возможные симптомы того, что в Scrum что-то идет не так, и что вы можете сделать, чтобы изменить ситуацию.
Если хотите, финальный контрольный список:
- Прочитав почти каждый из пунктов, вы узнали себя( ваша команда/организация ), т. е.
у вас скрам с неканоническим пониманием.
Тогда стоит задаться вопросом: нужен ли Scrum вообще? Зачем вам нужен Скрам? Какие задачи вы перед ним ставите? Готова ли ваша корпоративная культура к ценностям и принципам agile? Если у вас есть ответы и понимание того, для чего нужен Scrum, и вы действительно на него делаете ставку, то переходите ко второму варианту.
Если нет, то перестаньте обманывать себя.
- Читая некоторые моменты, вы подумали, что это не про вас.
Некоторые моменты побудили вас задуматься и вы вспомнили свою ситуацию.
Если да, то выберите те пункты, которые могут относиться к вашей ситуации.
Распечатайте их в виде карточек.
Обсудите симптомы со своей командой: применимы ли они к вам? Обсудите риски, согласны ли вы с ними, а может быть, вы видите более опасные последствия от симптомов.
Затем возьмите карту, которая больше всего беспокоит команду, самый опасный симптом на данный момент. Рассмотрим предложенное решение, подойдет ли оно вам? Коллективно придумайте, как можно улучшить ситуацию, как облегчить симптом.
И действуйте! Разобравшись с одним симптомом, переходите к следующему, периодически возвращаясь к общему обзору, чтобы убедиться, что вы не потеряли уже достигнутые результаты.
- Если вы все прочитали и не осознали свою реальность в этих ситуациях, мы поняли это правильно.
Действительно ли существуют такие организации? Ребята, вы молодцы, обязательно поделитесь в комментариях, как вам это удалось!
П.
П.
С.
Спасибо большое за иллюстрации Сай Кин УПД.
Часть 2 И Часть 3 .
Теги: #agile #scrum #владелец продукта #управление разработкой #agile #управление продуктом
-
Почему Интернет Такой Удобный Инструмент
19 Oct, 24 -
Прямая Трансляция С Дня Инноваций Microsoft
19 Oct, 24
