Scrum и потери в разработке программного обеспечения

 

В основе Scrum лежат принципы бережливого производства Toyota, а собственно борьба с потерями. ЦелRipped Moneybagью обнаружения и ликвидации потерь является сокращение себестоимости и повышение эффективности разработки программного обеспечения.

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

Семь типов потерь

Производство Разработка ПО
Излишние запасы Частично выполненная работа
Перепроизводство Избыточный функционал
Повторное выполнение работы Повторное приобретение знания
Транспортировка Передача работы/задачи
Перемещения Переключение между задачами
Ожидание Задержки
Дефекты Дефекты

Частично выполненная работа

Частично выполненная работа при разработке программного обеспечения является эквивалентом излишних запасов на производстве. Для уменьшения потерь от частично выполненной работы в Scrum выполняются следующие действия:

  1. Требования описываются в виде User Story, чтобы избежать излишней детализации и минимизации затрат на внесения изменений в требования.
  2. На Бэклог груминге команда детально прорабатывает только вершину айсберга Бэклога, User Story на 2-3 спринта.
  3. Концентрация усилий команды на разработку готового кусочка продукта в конце каждого Спринта, тем самым избежание частично выполненной работы.

Избыточные функционал

Избыточный функционал один из худших непроизводственных потерь в разработке программного обеспечения который заключается в разработке функционала, который не нужен заказчику. Если нет явной экономической необходимости в разработке функционала его не нужно разрабатывать (Модель Кано).

Для этого:

  1. Руководствуйтесь здравым смыслом.
  2. Знайте и понимайте цели, задачи и проблемы, которые хочет решить заказчик.
  3. Приоритезируйте Бэклог, реализовывайте задачи согласно приоритетов.
  4. Создавайте гибкую архитектуру для возможности добавления функционала на более поздних этапах.

«Только около 20 % функциональных возможностей в типичном пользовательском программном обеспечении используется регулярно, и около двух третей возможностей используется редко» (Джим Джонсон, председатель Standish Group)

Повторное приобретение знания

Повторное открытие чего-то, что мы раньше знали, но забыли — это, лучший пример “повторного выполнения работы” при разработке программного обеспечения. Мы знаем, что должны запомнить то, чему научились, но тем не менее на практике мы делаем это очень плохо. Еще одним примером пренебрежения знанием является игнорирование опыта членов коллектива, это еще хуже, чем забыть то, что мы уже знали. Крайне важно использовать знание всех членов коллектива, приобретенное ими с течением времени.

Scrum фреймворк создает комфортные взаимоотношения в коллективе для обмена знаниями и опытом с целью решения сложных задач и проектов.

Передача работы/задачи

Когда работа передается от одного исполнителя к другому, большая часть знаний остается в голове того, кто начинал работу. Задумайтесь, если при каждой передаче незавершенной работы другому исполнителю, по скромной оценке, теряется около 50% знаний, тогда:

  • если работа передавалась дважды у исполнителя остается 25%
  • если работа передавалась трижды у исполнителя остается 12%
  • если работа передавалась четыре раза у исполнителя остается 6%
  • если работа передавалась пять раз у исполнителя остается 3%

Так как передать знания от одного исполнителя к другому очень тяжело, передача работ всегда ведет к потере знаний. В Scrum фреймворке эти потери снижаются тем, что для реализации проектов:

  1. Выделяется отдельная кросс-функциональная команда, в рамках которой знания для реализации работ и задач накапливаются, а не теряются.
  2. Команда ежедневно обсуждает ход выполнения работ и задач, тем самым делясь знаниями в рамках группы.
  3. Получение обратной связи от заказчика на демонстрации продукта.

Переключение между задачами (мультизадачность)

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

Задержки

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

Для того чтобы уменьшить эти задержки в Scrum выделяется отдельная роль Владельца продукта, который плотно взаимодействует с командой в процессе разработки продукта и имеет полномочия принимать критические решения по проекту.

Дефекты

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

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

Автор: Николай Митько

Используемая литература:

  1. Бережливое производство программного обеспечения: от идеи до прибыли. Поппендик, Мэри, Поппендик, Toм — 2010
  2. Основы Scrum. Практическое руководство по гибкой разработке. Кеннет С. Рубин — 2016

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

три × три =