38 Agile попугаев

filmz.ru

Если Вы занимались управлением проектами, то наверняка сталкивались с задачей – как оценить трудоемкость будущих работ?

Эта задача достаточно сложная при любой системе управления проектами – от классического «водопада» PMBOK до современных Agile-техник. Проблем здесь две:

  1. Мы оцениваем трудоемкость работы, исходя из нашего опыта выполнения аналогичных работ в аналогичных условиях. Но условия могут не совпасть.

В графике проекта реконструкции помещения на разводку силовых кабелей было отведено 2 дня. Это был консенсус заказчика и прораба – в прошлых совместных проектах объем был примерно такой же, и исполнители справлялись за этот срок. Реальность – 3 недели! Причина простая – изменились строительные правила, и кабели пришлось протягивать «в гофрах». А монтаж «гофров» – это совсем другая технология, и другой объем работы.

  1. Производительность исполнителей работы в разное время может отличаться не только в разы – в десятки раз! Особенно, если работа не физическая, а мозговая. Дело не только в профессионализме. На работоспособность человека может повлиять все что угодно – «фазы луны», пробка по дороге, зависший компьютер, приезд в дом любимой тещи. Ну не получается у него сегодня, и все тут!

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

«Ничего не делать, просто плюнуть, и не заморачиваться!» Такой радикальный ответ на этот вопрос дает Agile-система управления работами «Канбан». Вместо попыток как-то спланировать будущее следует просто отдаться потоку прилетающих извне задач, но жестко ограничивать на входе количество заданий, принятых «в работу». Остальные – в очередь, пока не справимся с теми, что есть.

Как легко догадаться из названия, система управления работами «Канбан» базируется на японском опыте. Точнее — на системе управления материальным производством компании «Тойота». «Канбан» по-японски – это карточка заказа, и в язык менеджмента это слово пришло именно из «Тойоты». Вы заказываете у дилера автомобиль, Ваш заказ («канбан») поступает на завод, Вам собирают автомобиль под заказ. Нет заказов – на заводе ничего не собирают, сидят пьют чай.

В ИТ-разработках система «Канбан» применяется пока лет восемь, в материальном производстве «Тойота продакшн систем» работает уже более полувека. Есть некоторый опыт, который неплохо бы использовать и в Agile. Из опыта производственной системы «Тойота» известно, что:

  1. Поток заказов на завод никогда не бывает равномерным. Есть спады, есть пики по известным причинам (выход новой модели, маркетинговая компания) и неизвестным причинам (пресловутые «фазы луны»). Чтобы справиться с потоком заказов, необходимо иметь на заводе избыток ресурсов относительно усредненного уровня заказов. И мириться с неизбежными в период спада простоями. Хотите эффективно работать по «Канбан» — создайте больше рабочих мест!
  2. Заказы различаются по требуемым для их выполнения трудозатратам. Сборка автомобиля в комплектации «люкс» потребует больше времени операций, чем машины в базовой комплектации. Чтобы обеспечить ритмичность загрузки рабочих, заказы предварительно накапливают на 1-3 дня работы. А потом переставляют в оптимальной для производства последовательности (в системе «Тойота» такая перестановка называется «хейдзунка»).

В ИТ-компаниях, работающих по системе «Канбан», перестановку задач на входе тоже используют (правда, не называют этот процесс японским словом).  Но автомобилестроителям легко! Технолог точно знает, что сборка комплексации «люкс» занимает 32 часа 48 минут, а базовой – 23 часа 13 минут. А что делать, если мы используем «Канбан» для поддержки клиентов, и ожидаемое время решения их проблем неизвестно? Если мы пропустили в работу только сложные проблемы, но оставили пустяковые вопросы томиться в очереди по несколько дней, то клиенты вряд ли будут довольны. И мы снова утыкаемся в проблему оценки затрат времени выполнения задач.

Хороший подход к этой проблеме предлагает другая Agile методика – Scrum. Создатель этой методики Кент Бек отмечает, что люди не умеют оценивать абсолютные трудозатраты для решения задачи – либо сильно недооценивают, либо переоценивают. Но опытные сотрудники очень хорошо умеют оценивать относительные трудозатраты разных задач. Надо просто дать им удобную шкалу для сравнительной оценки. В практике Scrum предложено много таких шкал оценки – размерами футболок (S, M, L, XL), числами Фибоначчи, есть даже процедура коллективной оценки под названием  Scrum Poker.

Хочу внести свои пять копеек в решение проблемы сравнения трудозатрат. Я предлагаю измерять относительную трудоемкость решения задач «в попугаях». Да, в тех самых попугаях и мартышках из мультфильма «38 попугаев». Предлагаемая шкала следующая:

  1. Попугай. Работу можно выполнить одному человеку за несколько часов, если работать не отрываясь.
  2. Мартышка. Работа потребует нескольких человеко-дней (1 Мартышка – больше 7 Попугаев, как в мультфильме)
  3. Слон. Работа значительная, трудозатраты слабо предсказуемы. 20 Попугаев и более. Слонов надо стараться делить на Мартышек (подзадачи), как только появляется такая возможность.
  4. Удав. Задача не может быть выполнена за один прием. Скорее это цепочка периодически возникающих работ, существующих «в фоновом режиме».

Если первые три пункта интуитивно понятны, то необходимость выделения Удавов в отдельный класс задач требует пояснений.

В классических руководствах по Agile повторяющимся задачам уделяют очень мало внимания. Это естественно, у разработчиков софта таких задач немного. Но как только мы начинаем внедрять Agile методики в других сферах (например,  для поддержки клиентов), то доля рутинной работы у команд может быть весьма велика. А потом руководство удивляется – у команды задач «в работе» совсем мало, но почему они не переходят в статус «сделано»? Потому что все сотрудники заняты возней с Удавами, и у них нет времени даже на Мартышек.

Если Вы уже используете Agile методики управления, и Вам понравилась шкала «в попугаях» – пользуйтесь  ей на здоровье!

Дмитрий Привольнев

Эксперт Vera Via

Привольнев Д.А

Подружитесь с нами в соцсетях

Фёдор Рагин

Анастасия Сербинова
Яндекс.Метрика