Учебный кейс Posit Science. Часть 3

0
(0)

Продолжение учебного кейса Posit Science из программы тренинга Kanban System Improvements (KMP II) от Kanban.University.

Оглавление:

Канбану отказано

Дженис была уверена, что ее коллеги примут любые улучшения, но, к ее удивлению, на практике они отвергали любые предложенные изменения. Может быть Скрам стал слишком важной частью их идентичности? Ведь в течение двух лет они с тренерами изучали правила и практики. К тому же Скрам стал очень популярным подходом в районе залива Сан-Франциско и со стороны коллег-профессионалов ощущалось довольно высокое давление: они пытались доказать, что этот подход – это часть движения вперед.

Тем временем их критиковали, унижали и высмеивали за то, что они не могли заставить этот подход работать. Их вынуждали чувствовать вину за отсутствие дисциплины, но они не хотели, чтобы их считали лодырями. К тому же существовал некоторый риск профессионального и социального давления из-за выбора другого подхода, поэтому Скрам должен был остаться.

Дженис показалось, что несмотря на то, что Скрам хорошо работал в самом начале, обстоятельства изменились так, что политики и практики Скрама буквально вредили разработчикам. И все же, не смотря на это, они сопротивлялись изменениям. Сама идея изменений казалась еще более болезненной, чем текущая ситуация. Удвоив усилия, она продолжала читать все, что могла найти, пытаясь получше понять Канбан.

Она начала подмечать некоторые недостатки в работе команды, описанные в зарождающейся литературе о Канбане. Во время ежедневных встреч команды было ясно, что разработчики работают параллельно практически над всем в спринте. Уровень многозадачности зашкаливал, и отдельные лица были явно перегружены. Однако она никогда не считала это проблемой, пока не прочитала о практике ограничения количества незавершенной работы (WIP-лимиты). И хотя она уже видела проблему и её решение, команда не хотела отклоняться от правил Скрама, которым их обучили.

Дженис подумала, что в Скраме нет ни слова о WIP-лимитах. Она никогда об этом не слышала и об этом не упоминал ни один профессиональный тренер компании Posit. На самом деле нужно очень глубоко погрузиться в литературу о Скраме и вернуться к его истокам, чтобы найти совет Джеффа Сазерленда, соавтора Скрама, и упоминание о необходимости фокусировки внимания. Члены команды должны сфокусироваться на завершении работы и не начинать слишком много задач сразу. Однако в этом руководстве никогда не указывалось ограничение на количество задач в работе или даже концепция политики по этому ограничению. Это было лишь общее руководство, написанное в свободной формулировке, в которой предполагалось, что люди не должны добровольно брать много работы в параллель. В 2008 году редко можно было найти тренера, который хотя бы знал, а тем более обучал этой практике фокусировки внимания в Скраме.

Дженис не сдавалась. Она продолжала зарождать в их головах мысль о возможных изменениях и улучшениях. Она ждала, когда они будут готовы к этому. И в конце концов вмешался Дэвид Хоффман. Он согласился, что нужно что-то менять. Он проявил лидерские качества, которые были нужны отделу разработки. Иногда людям нужна помощь, чтобы они могли помочь себе. Им нужно волевое решение руководства. Он был готов попробовать Канбан.

Однако сопротивление и страх никуда не делись. Разработчики оттолкнули идею полной реализации Канбана и вытягивающей Канбан-системы (системы сигналов), суть которой – выполнять работу, когда будет доступная ёмкость. Дженис пришлось отступить и сократить масштабы изменений. В октябре 2008 года она смогла внедрить всего три простых, но важных улучшения: она смогла расширить их визуальную доску до анализа вверх по течению, внедрить персональные WIP-лимиты и отказаться от стиля Кена Швабера, оценивающего каждый элемент в часах работы, заменив его более простой системой, которая просто спрашивала «размер футболки», начиная с экстра-малого и заканчивая экстра-большим (XS, S, M, L, XL). На основе консенсуса было принято решение, что каждый разработчик будет работать не более чем над тремя задачами одновременно: ограничение незавершенной работы на человека будет равно трем.

На доске это было визуализировано с помощью небольших аватаров – фотографий членов команды, закрепленных на магнитах. У каждого человека было по три аватара и они помещали их рядом с тикетами, над которыми работали. Все могли видеть, кто над чем работает, кто с кем трудится над одной задачей и какие карточки в настоящее время простаивают без исполнителей. Изменения в методах работы представлены в табл. 1, а новая расширенная доска показана на рисунке 2.

На расширенной доске процесс работы по Скраму показан справа или ниже по течению, в то время как восходящая деятельность по подготовке клиентских запросов – преобразованию запрошенной функции в набор пользовательских историй – показана слева. Тикеты шли слева направо. Планирование спринта раз в три недели служило точкой принятия обязательств. По историям, выбранным в спринт, давалось обязательство о поставке; бэклог продукта содержал потенциально неограниченное количество историй без обязательств. Бэклог продукта не отображался на доске, а хранился в таск-трекере.

Эта визуализация раскрыла некоторые важные детали, которые, возможно, были ранее непрозрачными: люди, выполняющие работу над тикетами в колонке Specify, также выполняли работу по тикетам и в других колонках.

ДОПОСЛЕ
Итерации˅˅
Скрам-мастер, Владелец продукта˅˅
Планирование спринта˅˅
Ежедневные собрания˅˅
Принятие владельцем продукта˅˅
Демо˅˅
Ретроспективный˅˅
Оценка˅ Задачи (в часах)˅ Пользовательская история (по размеру футболки)
ДругоеWIP-лимит на человека
Таблица.1 Практика реализации программы «Posit Science’s Scrum», октябрь 2008 г.
Рис. 2 Расширенная визуальная доска компании Posit Science, октябрь 2008 г.
stuff.JPG
Рис. 3 Защита людей от перегрузки не защищает рабочий процесс от перегрузки.

Разработчики выполняли одновременно и оцененную, запланированную и обещанную работу, и внеплановую работу по подготовке требований в восходящем потоке. Таким образом, этап подготовки требований в Posit был внеплановым, неконтролируемым и деструктивным. Неспособность команды выполнить обязательства по спринту отчасти была вызвана отвлечением на эту внеплановую работу.

Как правило мы не хотим оказаться в ситуации, когда работники пересекают точку принятия обязательств и попадают в ситуацию многозадачности между запланированной и обещанной работой и незапланированными и необязательными запросами. Это особенно актуально, когда вы даете конкретные обязательства по срокам поставки.

Итак, уже сейчас мы с вами видим возможности для дальнейших улучшений в Posit. Проблема заключалась в том, что сами разработчики еще не были к этому готовы. Может быть, если они каждый день будут стоять перед доской с этой информацией, они тоже увидят то, что уже смогли увидеть мы? Время покажет. Дженис теперь была в роли Канбан-коуча и ей нужно было набраться терпения.

Идея изменения процесса оценки заключалась в том, чтобы отойти от ненужной точности. Эта точность требовала много времени, принося много боли, и при этом всегда оставалась под вопросом. Размер футболки же давал более понятное представление о том, насколько велик размер каждого запроса. Особенно это было понятно заинтересованным сторонам, далеким от разработки программного обеспечения. Быть менее точным, как правило, проще и быстрее, и это, в свою очередь, приводит к консенсусу. Надежда была на то, что такая оценка будет достаточно точной для выполнения обязательств. Дженис сообщила, что единственный важный показатель – это положительный ответ на вопрос: «Сделали ли мы того, что обещали?» Выполнение обещаний влияет на уровень окситоцина в мозге. Окситоцин – это химическое вещество, связанное с доверием и такими эмоциями, как любовь. Говоря с неврологами языком неврологов, она надеялась, что они ее поймут и начнут действовать. Весь отдел понимал, что гипоталамусы и заказчиков, и исполнителей будут вырабатывать окситоцин, когда поставки будут делаться в соответствии с обещаниями. Каждый спринт, завершенный с соответствующей обещаной функциональностью, будет улучшать отношения между заинтересованными сторонами и разработчиками.

Версия Канбан-доски от Октября 2008 г. (рис. 3) не является Канбан-системой. Для рабочего процесса не установлены WIP-лимиты и сквозная система всё ещё не защищена от перегрузки. Количество работы в системе может расти неограниченно, потому что в спринте нет ограничений на количество задач. Работа всё также может быть начата, а затем отложена на некоторое время. Объём бэклога спринта ограничен только планированием, а эффективность планирования зависит от точности процесса оценки. Несмотря на то, что есть отложенные обязательства и вытягивание работы партиями со сроком выполнения три недели, настоящая Канбан-система работает в масштабе индивидуальных запросов: по одному канбану – одной карточке – в работе.

Этот и другие варианты частичных реализаций Канбана стали известны как прото-Канбан-системы, термин, придуманный академиком программной инженерии Ричардом Тернером из Института Стивенса. “Прото” подразумевает эволюционного предшественника. Эти реализации названы так из-за историй, подобных истории Posit Science. Как вы увидите, частный вид этой прото-Канбан-система в Posit позже эволюционирует в полноценную и правильную реализацию. Таким образом, эти частные примеры по сути являются ступеньками и частью активного эволюционного процесса. Следовательно, эта история – не только история скрамбана, это еще и история прото-Канбана. Это также один из самых ранних зафиксированных примеров использования WIP-лимитов на одного человека в рабочем процессе довольно значительного масштаба – более двадцати человек. В то время, осенью 2008 года, этот подход был связан с только что зарождающейся концепцией Персонального Канбана, которая еще не была задокументирована.

Продолжение.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

Индекс лояльности клиентов

Пожалуйста, оцените по шкале от 0 до 10 вероятность, что вы порекомендуете нас другу или коллеге?

Baши пpeдлoжeния пo улучшeнию кaчecтвa нaшeй paбoтыЧто нам нужно улучшить в нашей работе, чтобы вы могли оценить нас 10?
Извините! Вы уже проходили голосование. Если вы забыли дополнить свой отзыв, напишите нам через обратную связь.

Задайте мне вопрос

Спросите меня, если не нашли ответ на сайте

Мы используем cookie-файлы. Оставаясь на сайте, вы соглашаетесь с политикой конфиденциальности.
Хорошо