После заморозки стартапа (более подробно можно ознакомиться в статье) компания заинтересовалась возможностью трансформации существующего производства, включающего 400 сотрудников, работающих в 6 продуктовых направлениях. Этой публикацией, я запускаю цикл статей, в которых попытаюсь предложить формализованный подход по оценке степени зрелости аспектов разработки для внедрения SCRUM.
Для решения этой сложной задачи была предложена программа, которая включает в себя 4 этапа:
Оценка готовности производственных подразделений к трансформации.
Разработка этапов трансформации.
Разработка механизмов трансформации.
Разработка ценностной модели обоснования трансформации.
Для реализации первого этапа я разработал программу оценки готовности, которая состоит из следующих частей:
Понимание и применение фреймворка SCRUM.
Разработка и поставка продукта.
Гибкое управление продуктовыми направлениями.
Развитие продуктовых команд.
В данной статье будет идти речь об атрибутах и их характеристиках в разрезе понимания и применения фреймворка SCRUM. Остальные части будут раскрыты в следующих публикациях.
Философия эмпиризма
Философия эмпиризма в контексте фреймворка описывает отношение и подходы, применяемые к возникающим проблемам. Данное отношение выражается в декомпозиции проблем на более мелкие инкременты, а также в возможности изучения нового в рамках предоставленных решений.
Характеристика | Метод исследования | Метрика |
Декомпозиция | Наблюдение за инструментами фиксации проблем (JIRA). | Отсутствует декомпозиция — 0 баллов. 1 уровень декомпозиции — 1 балл. 2 уровня декомпозиции — 3 балла. 3 уровня декомпозиции — 5 баллов. |
Проблема | Опрос респондентов: «Как вы относитесь к проблеме?» | Проблема — негативное событие и его нельзя допускать — 0 баллов. Проблема — явление, к которому я уже привык — 3 балла. Проблема — возможность для роста и изучения нового — 5 баллов. |
Наблюдение за реакцией сотрудников с руководящей функцией при возникновении проблемы. | Негативная реакция со стороны руководителя — 0 баллов. Позитивная реакция со стороны руководителя — 5 баллов. | |
Наблюдение за реакцией сотрудников при возникновении проблемы. | Негативная реакция со стороны сотрудника — 0 баллов. Позитивная реакция со стороны руководителя — 5 баллов. |
Определение интегральной шкалы оценки свойства «философия эмпиризма» не целесообразно, в связи с тем, что каждая характеристика является самодостаточной и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. В случае низкой оценки для какой-либо из характеристик, рекомендуется разработать индивидуальные программы в разрезе тренингов или коучинг-сессий.
Культурные ценности
Культурные ценности — шаблон поведения сотрудников внутри коллектива и внутри целой организации, который существует вне рамок регламентов и процедур. Данный шаблон определяет отношение сотрудника к выполняемому труду и формирует жизненную позицию. В интересах компании создать и развивать идеологический образ культурных ценностей, так как существует определённая корреляция между ценностями и производительностью труда.
Характеристика | Метод исследования | Метрика |
Фокус | Наблюдение за тем, что вся работа выполняется в контексте спринта для достижения своей цели. | Работа появляется спонтанно вне определённого контекста — 0 баллов. Вся работа запланирована и выполняется в контексте спринта — 5 баллов. |
Открытость | Наблюдение за тем, что разработчик продукта и стейкхолдеры открыты в отношении работы и вызовах, которые необходимо преодолеть для её выполнения. | Стейкхолдеры практикуют неконструктивную обратную связь (обвинение, унижение) — 0 баллов. Стейкхолдеры проявляют лояльность в отношении работ и дают обратную связь в конструктивном ключе — 5 баллов. |
Уважение | Наблюдение за тем, что участники разработки продукта проявляют уважение друг к другу в части компетенций и персональной самодостаточности. | У частников ярко выражена модель ассоциации проблемы с индивидуальными способностями сотрудников — 0 баллов. Участники с пониманием относятся к ограниченности как своих знаний, так и окружающих их людей; с желанием делятся опытом с коллегами — 5 баллов. |
Смелость | Наблюдение за способностью сотрудников проявлять смелость для решения сложных проблем. | Участники настороженно относятся к сложным задачам, которые вызывают отторжение — 0 баллов. Участники с вызовом относятся к сложным проблемам и расценивают их как возможность сделать очередную запись успеха — 5 баллов. |
Приверженность | Наблюдение за персональной приверженностью сотрудников в части достижения целей спринта. | Сотрудники не ощущают зоны ответственности, нет понимания собственного вклада — 0 баллов. Сотрудники ощущают персональную ответственность перед командой и продуктом; есть также понимание собственного вклада — 5 баллов. |
Определение интегральной шкалы оценки свойства «культурные ценности» не целесообразно, в связи с тем, что каждая ценность является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. В случае низкой оценки для какой-либо из характеристик, рекомендуется разработать индивидуальные программы в разрезе тренингов или коучинг-сессий.
Команда как функциональная единица
Рабочим механизмом доставки ценностей инкремента продукта является команда, организованная по предметному признаку (продукт). С позиции управления, наличие самодостаточной организационной единицы, которая в состоянии выполнить весь спектр работ для поставки инкремента в продуктивную среду клиента, предоставляет гибкость в планировании и решении стратегических задач для руководства. В целях упрощения управления командой на уровне организации и ролей, она сводится к минимальному составу: скрам-мастер — управление организацией, владелец продукта — управление контентом, разработчик — исполнитель.
Характеристика | Метод исследования | Метрика |
Команда | Наблюдение за принципами организации групп и наличие сущности «команда». | Отсутствует понятие команды — 0 баллов. Команда образована по функциональному признаку — 1 балл. Самоорганизация команды по предметному признаку — 3 балла. Команда образована по предметному признаку (направление) — 5 баллов. |
Скрам-мастер | Наблюдение за наличием функций: — развитие продуктовой команды; | Роль отсутствует, функции роли отсутствуют — 0 баллов. Роль отсутствует, функции роли присутствуют — 1 балл. Роль присутствует, функции роли отсутствуют — 3 балла. Роль присутствует, функции роли присутствуют — 5 баллов. |
Владелец продукта | Наблюдение за наличием функций: — разработка дорожной карты продукта; | Роль отсутствует, функции роли отсутствуют — 0 баллов. Роль отсутствует, функции роли присутствуют — 1 балл. Роль присутствует, функции роли отсутствуют — 3 балла. Роль присутствует, функции роли присутствуют — 5 баллов. |
Разработчик | Наблюдение за восприятием роли разработчика в контексте всех необходимых функций для выполнения задач в команде. | Роль включает в себя только компетенции программирования — 0 баллов. Роль включает в себя все необходимые компетенции для поставки версии продукта — 5 баллов. |
0–13 баллов — низкий результат, характеризующий отсутствие команды в качестве производственной единицы признанной на уровне организации. Необходимо разработать комплексную программу мероприятий для выделения и формирования команды в контексте организационных уровней компании. Не допускается проводить мероприятия для отдельно взятых характеристик за рамками комплексной программы.
14–16 баллов — средний результат, характеризующий наличие команды как класса, но существуют определённые ограничения для полного раскрытия потенциала. Необходимо определить проблемные характеристики для улучшения и разработать мероприятия. Допускается применение мероприятий без общей программы.
17–20 баллов — высокий результат, характеризующий наличие самодостаточной организационной единицы производства инкремента продукта, признанной на уровне организации. При данном результате, рекомендуется сделать акцент на мероприятиях направленные на управление продуктом, непрерывное обеспечение качества и CI/CD, как вектор роста команды.
События
События представляют из себя правила коммуникаций в разрезе следующих вопросов:
кто должен коммуницировать?
когда должен коммуницировать?
с какой целью должен коммуницировать?
Все события должны быть ограничены по времени для обеспечения гарантии эффективности коммуникаций и производительности труда. В дополнении, повторяющиеся по времени события создают производственный ритм, при котором формируется проактивный паттерн ответственности у сотрудников. Данный паттерн выражается в необходимости поделиться результатами работы и предоставить пояснения, если его деятельность кого-то блокирует.
Характеристика | Метод исследования | Метрика |
Спринт | Наблюдение за ограниченным по времени событием, в рамках которого производится выпуск работоспособного инкремента продукта. | Событие отсутствует — 0 баллов. Присутствует событие с фиксированной периодичностью (2–4 недели) — 5 баллов. |
Ежедневный стендап | Наблюдение за событиями ежедневных коммуникаций, где происходит синхронизация. | Событие отсутствует — 0 баллов. Событие проходит каждый день и несколько раз — 1 балл. Событие фиксировано по времени, проходит каждый день и больше 15 минут — 3 балла. Событие фиксировано по времени, проходит каждый день и ограничено 15 минутам — 5 баллов. |
Планирование спринта | Наблюдение за событием, на котором происходит планирование содержания инкремента продукта. | Событие отсутствует — 0 баллов. Событие не имеет ритмичности и происходит хаотично — 1 балл. Событие имеет ритмичность, но не ограничено по времени — 3 балла. Событие имеет ритмичность и ограничено по времени (4 часа—2-х недельный спринт) — 5 баллов. |
Обзор спринта | Наблюдение за событием, на котором происходит демонстрация работоспособного инкремента стейкхолдерам. | Событие отсутствует — 0 баллов. Событие не имеет ритмичности и происходит хаотично — 1 балл. Событие имеет ритмичность, но не ограничено по времени — 3 балла. Событие имеет ритмичность и ограничено по времени (2 часа–2-х недельный спринт) — 5 баллов. |
Ретроспектива | Наблюдение за событием, на котором команда анализирует результаты спринта для планирования мероприятий роста и развития. | Событие отсутствует — 0 баллов. Событие не имеет ритмичности и происходит хаотично — 1 балл. Событие имеет ритмичность, но не ограничено по времени — 3 балла. Событие имеет ритмичность и ограничено по времени (2 часа–2-х недельный спринт) — 5 баллов. |
0–17 баллов — низкий результат, характеризующий события в качестве реактивных явлений, триггером появления которых служит возникшая проблема или задача. Данному результату свойственно большое время простоя производства в связи с отсутствием эффективных механизмов коммуникаций. При данном результате необходимо разработать комплексную программу внедрения и развития событий в командах.
18–20 баллов — средний результат, характеризующий наличие событий с ограничением их эффективного использования. Ограничения выражены безосновательной продолжительностью, а также хаотичностью возникновения. При данном результате необходимо разработать мероприятия для проблемных характеристик с точки зрения сокращения времени и внедрения ритмичности. Допускается проведение мероприятий отдельно от общей программы в случае, если существующие события семантически соответствуют описанным выше. В том случае, если существуют дополнительные события, необходимо проанализировать эти события на предмет ценности и целесообразности.
21–25 баллов — высокий результат, характеризующий наличие эффективно выстроенных коммуникаций и ритмичные процессы производства продукта. При данном результате, рекомендуется сделать акцент на характеристике «критерии завершённости» в качестве точки роста компетенций команды и качества выпускаемого инкремента.
Артефакты
В традиционном водопадном подходе существует большое количество артефактов, целью которых является синхронизация функциональных групп. В гибкой разработке выделяют только три артефакта, которые являются единственными для организации работы команд:
Бэклог продукта — упорядоченный и постоянно обновляемый список всего, что планируется сделать для создания и улучшения продукта. Этот артефакт является единственным источником работы для команды.
Бэклог спринта — выбранный на спринт набор элементов бэклога продукта для достижения определённой командой цели спринта с учётом имеющихся знаний и приоритетов.
Инкремент — протестированная и работоспособная версия с добавочной ценностью для клиента, которая соответствует критериям завершённости.
Характеристика | Метод исследования | Метрика |
Бэклог продукта | Наблюдение за единым местом хранения всех задач, направленных на развитие продукта. | Бэклог продукта отсутствует — 0 баллов. Бэклог продукта имеет вид разбросанных задач — 1 балл. Бэклог имеет вид отфильтрованного списка по предмету — 3 балла. Бэклог единое место хранения всех задач по продукту — 5 баллов. |
Бэклог спринта | Наблюдение за единым местом хранения задач спринта, выполнение которых обеспечит выпуск инкремента. | Бэклог спринта отсутствует — 0 баллов. Бэклог спринта имеет вид разбросанных задач — 1 балл. Бэклог имеет вид отфильтрованного списка по предмету — 3 балла. Бэклог единое место хранения всех задач по спринту — 5 баллов. |
Инкремент | Наблюдение за фактом выпуска протестированной и работоспособной версии продукта. | Понятие инкремента отсутствует — 0 баллов. Понятие инкремента присутствует, но выпуск работоспособной версии не происходит по факту окончания спринта — 1 балла. Понятие инкремента отсутствует, но выпуск работоспособной версии происходит по факту окончания спринта — 3 балла. Понятие инкремента присутствует, триггером появления служит спринт — 5 баллов. |
0–9 баллов — низкий результат, характеризующий сложность существующих подходов в части управления и планирования содержанием работ. Данная сложность может быть причиной увеличения времени ожидания ответа на запрос внутри команды, а также причиной низкой концентрацией на актуальных задачах.
10–12 баллов — средний результат, характеризующий наличие артефактов, однако существуют ограничения для их эффективного использования. Ограничения могут быть обусловлены разбросанностью элементов бэклога, а также наличием дополнительных артефактов. Рекомендуется разработать мероприятия, направленные на выделение артефактов как отдельной практики, задуманной по определению.
13–15 баллов — высокий результат, характеризующий наличие и использование минимального набора артефактов для организации работ продуктовой команды. При данном результате рекомендуется сделать акцент на улучшение подходов по управлению содержанием продукта.
Критерии завершённости
Список критериев завершённости (далее DoD, от английского definition of done) является формальным чек-листом для принятия решения о выпуске инкремента. Критерии определяются стандартами организации. Если они отсутствуют, то команда должна определить список DoD. По мере развития команды список критериев завершённости будет развиваться параллельно улучшению качества выпускаемого инкремента.
Характеристика | Метод исследования | Метрика |
Наличие списка DoD | Наблюдение за существованием списка критериев завершённости и его использование для выпуска инкремента. | DoD отсутствует — 0 баллов. DoD отсутствует, существуют разбросанные критерии — 1 балл. DoD присутствует, инкремент выпускается без соответствия критериям — 3 балла. DoD присутствует, инкремент выпускается при соответствии критериям — 5 баллов. |
Проверка уязвимостей | Наблюдение за наличием критерия, который характеризует отсутствие уязвимостей в исходном коде. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, не используется специализированное ПО (sonarqube) — 3 баллов. Критерий есть, участвует в принятии решения, используется специализированное ПО (sonarqube) — 5 баллов. |
Покрытие исходного кода | Наблюдение за наличием критерия , который характеризует покрытие исходного кода тестами. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, не используется специализированное ПО (sonarqube) — 3 баллов. Критерий есть, участвует в принятии решения, используется специализированное ПО (sonarqube) — 5 баллов. |
Инженерные стандарты | Наблюдение за наличием критерия, который характеризует применение инженерных стандартов (методы, тесты, переменные и так далее) | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, нет общей wiki-страницы с описанием стандартов — 3 баллов. Критерий есть, участвует в принятии решения, есть wiki-страница с описанием стандартов — 5 баллов. |
Критерии приёмки | Наблюдение за наличием критерия, который характеризует условия для принятия инкремента клиентом. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, нет общей wiki-страницы с описанием критериев — 3 баллов. Критерий есть, участвует в принятии решения, есть wiki-страница с описанием критериев — 5 баллов. |
Автотесты | Наблюдение за наличием критерия, который характеризует покрытие автотестами инкремента. | Критерий отсутствует — 0 баллов. 30-50% покрытие — 1 балл. 50-80% покрытие — 3 балла. 80-100% покрытие — 5 баллов. |
Проверка безопасности | Наблюдение за наличием критерия, который характеризует соответствие безопасности отгружаемого инкремента. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, не используется специализированное ПО — 3 баллов. Критерий есть, участвует в принятии решения, используется специализированное ПО - 5 баллов. |
UI/UX стандарты | Наблюдение за наличием критерия, который характеризует соответствие стандартам дизайна и эргономики. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, нет общей wiki-страницы с описанием стандартов — 3 баллов. Критерий есть, участвует в принятии решения, есть wiki-страница с описанием стандартов — 5 баллов. |
Архитектурные принципы | Наблюдение за наличием критерия, который характеризует соответствие зафиксированным архитектурным принципам. | Критерий отсутствует — 0 баллов. Критерий есть, не участвует в принятии решения — 1 балл. Критерий есть, участвует в принятии решения, нет общей wiki-страницы с описанием принципов — 3 баллов. Критерий есть, участвует в принятии решения, есть wiki-страница с описанием принципов — 5 баллов. |
0–31 баллов — низкий результат, характеризующий отсутствие системы критериев завершённости, как механизма принятия решения о выпуске инкремента продукта. Для данного кейса свойственен иррациональный критерий — наступление даты релиза. Рекомендуется разработать комплексную программу внедрения критериев завершённости в минимальном составе. По мере того как критерии будут приобретать рутинный характер, можно рассмотреть внедрение новых для улучшения качества выпускаемого инкремента.
32–37 баллов — средний результат, характеризующий ограниченное использование системы критериев завершённости. Ограничение может быть обусловлено отсутствием полноты критериев, а также их игнорированием при принятии решения о выпуске инкремента. Рекомендуется предусмотреть отдельные мероприятия для улучшения критериев с низкой оценкой.
38–45 баллов — высокий результат, характеризующий устоявшуюся и применяемую систему критериев завершённости, которая гарантирует выпуск работоспособного инкремента за спринт. При данном результате команда по умолчанию выполняет действия, направленные на удовлетворение критериям завершённости, и это становится рутинной операцией. Рекомендуется зафиксировать подход как эталонный и разработать стандарт на уровне организации.
Масштабирование
Механизмы масштабирования самого продукта и производственных мощностей определяют капитализацию компании и прибыль.
Кадровое обеспечение — данный механизм определяет два способа наращивания штата новых сотрудников. Первый способ — запрос функциональных подразделений, второй способ — запрос продуктовой команды.
Новый продукт— механизм при котором происходит разворачивание нового продуктового направления. Первый способ — ресурсное привлечение отдельно взятого сотрудника, второй способ — привлечение устоявшейся продуктовой команды.
Новые клиенты — механизм при котором происходит внедрение существующих продуктов для нового клиента. Первый способ — для каждого клиента отдельная ветка и вектор развития продукта; второй способ — выделяется общее ядро и собственная ветка разработки для каждого клиента в рамках слоя кастомизации; третий способ — единственная ветка разработки с общими архитектурными механизмами.
Архитектура — механизм, который регулирует способ управления и развития архитектуры. Первый способ — монолитная архитектура, второй способ — микросервисный монолит, третий способ — микросервисная архитектура, четвёртый способ — оркестратор бизнес-процессов.
Характеристика | Метод исследования | Метрика |
Кадровое обеспечение | Наблюдение за способом наращивания штата новых сотрудников. | Запрос функциональных подразделений — 1 балл. Запрос продуктовых команд — 5 баллов. |
Новый продукт | Наблюдение за способом мобилизации ресурсов на новые продуктовые направления. | Привлечение отдельно взятого сотрудника — 1 балл. Привлечение устоявшихся команд — 5 баллов. |
Новые клиенты | Наблюдение за способом внедрения существующих продуктов для новых клиентов. | Своя ветка для каждого клиента — 1 балл. Общее ядро и собственная ветка разработки для каждого клиента — 3 баллов. Единственная ветка разработки с общими архитектурными механизмами — 5 баллов. |
Архитектура | Наблюдение за способом развития архитектуры. | Монолитная архитектура — 0 баллов. Микросервисный монолит — 1 балл. Микросервисная архитектура — 3 балла. Оркестратор бизнес-процессов — 5 баллов. |
Определение интегральной шкалы оценки свойства «масштабирование» не целесообразно, так как оно не является обязательным условием для организации продуктовой разработки. Максимальная оценка характеризует вариант, при котором может быть достигнут высокий синергетический эффект для компании в рамках оптимизации затрат на запуск нового продуктового направления или поддержку уже имеющихся. Обоснование метрик будет более подробно рассмотрено в рамках ценностной модели обоснования трансформации.
ngekht
Только часть эмпирицизма уже весьма интересно. Вроде заявлен Скрам — но полностью куда-то делась петля обратной связи через инспекцию и адаптацию и обеспечение прозрачности целей и текущего состояния.
И если “учимся на ошибках” как часть grow mindset хотя бы попадает в необходимые условия для того, чтобы запустить эмпирический подход, то метрика в виде количества уровней декомпозиции — это сильно. Особенно если учесть что уровни сразу ограничивают команду только в сторону декомпозиции структурной, что сильно дернет их в сторону component team вместо feature team.
Я бы посоветовал начать с whitepaper о evidence-based management, у них прекрасный набор метрик, причем не на поведение, а на полученный результат. В конце концов мы имеем то, что мы измеряем. А у вас великий шанс “декомпозицию на три уровня и праздник от проблемы” и получить вместо реализации цикла разработка обоснованной гипотезы — планирование и проведение эффективного эксперимента — анализ результатов эксперимента — уточнение неверной гипотезы/формирование новой на основе верной.
tkachsta Автор
ngekht, спасибо за обратную связь! Данная статья является одной из четырёх запланированных к выпуску, которые входят в общую программу.
В свою очередь, идея написания программы обусловлена бизнес задачами:
1. Рассмотреть готовность к трансформации
2. Создать общее видение
3. Сформировать набор метрик для оценки наличия атрибутов SCRUM
Соответственно, эмпиризм является важным атрибутом SCRUM со своими метриками. Но другой вопрос, как мы можем его измерить и оценить? Думая над этим вопросом, я выделил две понятные и простые метрики:
1. Декомпозиция — характеризует способность разбивать сложные проблемы на более простые.
2. Отношение к проблеме — характеризует мировоззрение (mindset), при котором сотрудник или команда не испытывает тревожность и раздражение при появлении новой проблемы.
Петля обратной связи есть и характеризуется набором следующих атрибутов:
1. Философия эмпиризма
2. События
3. Критерии завершенности