SCRUM не срам, никому не отдам!
время публикации: 10:00 04 декабря 2018 года
Время чтения: 6 мин 55 сек.
Легкобольные надеются выздороветь самостоятельно, сильнонаивные уповают на трендомодные методики. Планирование и труд подменили разочарование и стыд. Горько перед своими, неловко среди пришлых. Заветная мечта – отыскать и внедрить заморский подход, срубающий проблемы на корню.
Легкобольные надеются выздороветь самостоятельно, сильнонаивные уповают на трендомодные методики. Планирование и труд подменили разочарование и стыд. Горько перед своими, неловко среди пришлых. Заветная мечта – отыскать и внедрить заморский подход, срубающий проблемы на корню.
Муай-Тай мнится круче самбо, MMA множит рукопашку на ноль, WWE кажется зрелищней боевого гопака. Суть вторична: влечёт непривычность произнесения и похожесть с алхимическими заклинаниями. Проектные команды во время сходок частенько ненароком вызывают Сатану.
Программисты схватились за термины спорта, компенсируя громкими фразами тщедушность хилых тел. Одно дело – процедурно плестись мелким шагом, другое – рубиться рьяно в свалке схватки. Именно так переводится SCRUM – методика гибкой разработки софта, заимствованная из бейсбольной терминологии.
Подход впервые описали в «Harvard Business Review» Хиротака Такэути и Икудзиро Нонака в январе 1986 года. Интел в это время вовсю продавала процессоры i386, недоступные малым компаниям и группам разработчиков. Низкую производительность железа предлагалось компенсировать умными подходами.
Потребовалось упорное десятилетие, прежде чем Кен Швабер и Джеф Сазерленд представили стройную модель гибкости. Ещё пять лет ушло на детализацию описания книгой «Agile Software Development with SCRUM» и… стартовали разработки продуктов высокой ценности в непрозрачной и запутанной среде.
Команды ринулись фреймовать дорожные карты спринтами – фиксированными по времени краткими итерациями. В каждом забеге заказчику обещалось работающее ПО с наращённым функционалом высшего приоритета. Ошибки перестали быть багами, коварно обратившись недокументированными фичами.
Сложнее проблема, масштабнее проект – больше сталкивающихся интересов и участников шабаша. Предсказуемы остаются только оправдания и даты сборов. Учесть позиции всех не пытаются, интересов многих – достаточно. Техническое задание плавится мороженым в руках, но слизывать капли любят не все.
Сценарий совещаний становится изящноигрив, подчиняясь формуле: с утра свернуть хотели горы, в обед решили – пусть стоят. Геройские переработки не приветствуются: амбиции отрицаются, ошибки обсуждаются. На повестке больше синхронизация действий и поиск сплочённости единого порыва.
Вместо нудных написания и согласования ТЗ, заказчик осчастливлен шансом регулировать очерёдность появления новых функций, оцениваемых мерностью применимости-пользы-срочности. Синхронизация разноспециальных стартует с планирования, прикидки трудозатрат и очерёдности релизов.
Проектирование сменяется прототипированием под незамысловатые правила SCRUM:
1. Устраните иерархию – работайте сообща.
2. Избегайте анархии – направление задаёт владелец продукта.
3. За результат отвечает команда – не ищите виноватых и оправдания.
4. Участники помогают друг другу, чтобы уложиться в рамки ресурсов и сроков.
5. Каждый знает, над чем работают остальные – команда регулярно «сверяет часы».
6. Процесс не вытесан в камне – улучшения возможны, желательны и приветствуются.
7. Скажите «нет» волоките – оставьте попоприкрывательство за дверью комнаты совещаний.
Ошибки SCRUM застираны до дыр:
1) Недооценена важность мотивации команды.
2) Метод применяется неверно или не полностью.
3) Процесс выдуман, нетипичен или построен неграмотно.
4) Идеология назначается продукту, которому не подходит.
5) Отсутствует формальный лидер, руководитель и потребитель.
6) Группа цепляется за первоначальные идеи, не желая гибко реагировать.
7) Задействуется долгосрочное планирование, вместо работы по спринтам.
Не мудрствуя лукаво, авторы заявили SCRUM лёгким в работе, простым в понимании, сложным в освоении. Как говорится, без пол-литра не разберёшься. Поэтому участники прошлых команд необычайно в цене, заявляя, что основа управления эмпирикой: прозрачность, проверка и адаптация, что бы это ни значило.
В ходе работ непонятное становится разведанным, недоступное – потенциальным, рискованное – инкрементально приближаемым. Простои и разглагольствования ограничены по времени: скрыться негде, а лентяев вышвыривают в окна возможностей. Поезд резво прёт несмотря на стенанья вагонов.
Опытный машинист зовётся Скрам-мастером, считается слугой и лидером команды. Следит за соблюдением правил, изложением теорий, внедрением практик. Выполняет нетривиальные функции:
1) Тренирует группу на пути изучения SCRUM’а.
2) Планирует этапы внедрения в пределах проекта.
3) Устраняет помехи, возникающие в процессе работы команды.
4) Выступает инициатором изменений, усиливающих продуктивность.
5) Помогает коллегам и заинтересованным понять принципы эмпирической разработки.
Приверженцы экстремальности ценят работоспособность выше описаний, не тратясь на создание сомнительной полезности. Нечасто заглядывают в будущее, дальновидно предпочитая смотреть под ноги и вперёд на шаг. Фокус на ближнем планировании приучает не громоздить документацию, но она есть:
1) Стартовая – верхнеуровневые диаграммы, первичный функционал, базовые компоненты, зоны ответственности, наброски архитектур.
2) Проектная – необходимые и достаточные требования, как часть бэклога, внедрённые системные и бизнесовые правила на выходах каждого спринта.
3) Функциональная – пользовательские истории в формате «Я, [роль потребителя], хочу [действие], чтобы [ожидаемое поведение разработки]».
Кстати, бэклогом зовётся журнал зафиксированных обещаний, ожидающих внедрения и нестабильностей реакций софта, назначенных к устранению.
Скраму способствуют:
1. Краткие и действенные совещания-летучки.
2. Терпимость к умеренной суматохе и неразберихе.
3. Следование методике и предварительное обучение.
4. Готовность к переформатированиям на ранних этапах.
5. Ясные приоритеты и обсуждённые ожидания заказчика.
Скрам гробят:
1. Давление иерархии.
2. Нежелание меняться.
3. Отвлечение внимания.
4. Нерегулярная приоритизация.
5. Несвоевременное назначение ресурсов.
Примите финальное напутствие:
1. Не делайте длинных спринтов: короче забег – очевиднее недоработки, проще устранение.
2. Постепенность обходится дешевле: следите за равномерностью добавления функционала.
3. Ранний успех почти гарантирован: начальные победы не длятся вечно, не расслабляйтесь.
4. Внедряйте Скрам постепенно, соблюдайте жёстко: будет меньше стресса и больше порядка.
5. Не используйте методику прикрытием для трансформаций – отделите зёрна от плевел и мух от котлет.
Чуть не забыл! Традиционная шутка: «Если сразу не получилось хорошо, назовите это версией 1.0».
,
Основатель
Читайте также:
0
Читайте также
Последние новости
Самое популярное
-
Фоторепортаж: Fix Price в новом офисе
-
Как подготовиться к Новому году на маркетплейсе: советы для продавцов
-
Продажи хлеба в 2024 году: тренды и влияние мерчандайзинга
-
Как музыкальный брендинг усилил восприятие фэшн-бренда и увеличил продажи (кейс ...
-
Как правильно работать с отзывами на маркетплейсах
