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

Что такое одновременная разработка функций?

Одновременная разработка функций — это распространенная практика разработки программного обеспечения, когда команда работает над несколькими функциями одновременно. Например, если вы проводите схватку, вы втянете кучу историй в свой спринт. И все будут более или менее счастливы, если вы закончите все свои истории к концу спринта. У вашей команды нет ограничений на незавершенную работу. Так что работайте на чем удобно.

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

Почему вы должны заботиться об одновременной разработке функций?

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

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

Как вы можете улучшить свои результаты, используя цену задержки

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

Пример

Предположим, вы начинаете новый четырехнедельный спринт и у вас есть 4 функции, которые нужно выполнить. Разработка каждой функции займет одну неделю. И вы теряете 5000 долларов каждую неделю, когда откладываете запуск каждой функции — это цена задержки.

Вот финансовые последствия, если вы разработаете все свои функции одновременно и развернете их в конце спринта.

А вот финансовые последствия, если вы будете разрабатывать свои функции последовательно и развертывать их, как только они будут готовы.

Вы можете оказать огромное влияние на прибыльность вашего проекта, просто внеся изменения в то, как вы планируете свою работу. В этом случае вы можете уменьшить стоимость задержки на 37,5 %! ((50–80 тысяч)/80 тысяч = 37,5%)

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

Ключевой вывод: ожидание имеет свою цену. Если для завершения вашей функции требуется 50 часов разработчика, но она проводит несколько месяцев в ожидании в различных очередях, прежде чем она будет наконец доставлена ​​вашим клиентам, истинная стоимость этой функции может быть во много раз больше, чем 50 часов заработной платы программиста. Большинство предприятий сосредоточено на этих 50 часах программистского времени и следит за тем, чтобы все их сотрудники работали с очень высоким коэффициентом использования. Но они совершенно не замечают потенциальной потери десятков тысяч долларов из-за того, что на реализацию этой функции ушли месяцы, тогда как ее можно было реализовать за несколько дней.

Подведение итогов

Я был совершенно слеп к этой огромной возможности увеличить прибыльность, пока не узнал о цене просрочки. Мы были счастливы, если работали над высокоприоритетными задачами в наших спринтах и ​​достигали поставленных целей по скорости. Но мы определенно оставляли много денег на столе. Мы часто позволяли историям задерживаться в нескольких спринтах, если они провалили несколько проверок кода. Эти истории могли заблокировать целые функции на несколько недель подряд. Но нам никогда не приходило в голову, что мы теряем деньги.

Расчет стоимости задержки и использование ее для планирования нашей работы потребовали от нас внесения некоторых корректировок, но это того стоило. Я расширю эти идеи и покажу вам более сложные примеры в последующих постах. Быть в курсе.

Дополнительные затраты на ресурсы задержки

Вам может пригодиться следующая стоимость ресурсов задержки:

  • отличный сайт с отличным трехминутным поясняющим видео
  • Книга: «Принципы процесса разработки продукта: разработка бережливого производства второго поколения» (Дональд Рейнертсен), глава 2.
  • книга: «Essential Scrum: Практическое руководство по самому популярному Agile-процессу» (Кеннет С. Рубин) Глава 16
  • видео выступление Дональда Рейнертсена о разработке продукта

Первоначально опубликовано на сайте smallbusinessprogramming.com 4 декабря 2017 г.