0/5
Подпишитесь на новости ритейла

Я ознакомлен с политикой конфиденциальности и принимаю её условия

SCRUM не срам, никому не отдам!

SCRUM не срам, никому не отдам!
Время чтения: 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 лёгким в работе, простым в понимании, сложным в освоении. Как говорится, без пол-литра не разберёшься. Поэтому участники прошлых команд необычайно в цене, заявляя, что основа управления эмпирикой: прозрачность, проверка и адаптация, что бы это ни значило.

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».





Читайте также:



время публикации: 10:00  04 декабря 2018 года
0

Комментарии (0)


Чтобы оставить комментарий, Вам необходимо авторизоваться:  
ЕГАИС Плюс
BBI НАССИМ ТАЛЕБ