Пользователь
0,1
рейтинг
20 июня 2014 в 06:00

Разработка → Waterfall и Agile: и всё-таки, откуда эффект?

Всем добрый день! Этот короткий пост посвящен рассмотрению моделей процессов разработки Waterfall и Agile (на примере Scrum и/или Kanban). И вот в чем дело: с точки зрения заказчика, процесс не столь важен, сколько срок и бюджет удовлетворительного с точки зрения функционала результата. И если известно, что (изменения не учитываются) затраты Waterfall-процесса идут по S-кривой, а затраты Agile-процесса накапливаются линейно (так как ресурсы используются одновременно все), то как они должны различаться по эффективности. Чтобы исследовать этот вопрос, необходимо построить модели и сравнить их, и для этого будет использована несложная математика.


Совет №30: Считайте везде, где это возможно. Если счет невозможен — вычисляйте. Используйте оценки, полученные на основании одного лишь экспертного суждения, только лишь в крайнем случае.
Макконнел С. Сколько стоит программный проект (2007).



Предыстория


Управление проектом, условно, можно разделить на две составляющие — на планирование и управление ходом.

С этой точки зрения для waterfall всё ясно — составили пошаговый (аналитика-разработка-тестирование) календарный план задач по оценкам сроков, распределили задачи и вперед реализовывать.

Со Scrum и Kanban ненамного сложнее: последовательность планирования осуществляется через приоритеты в backlog, разработка контролируется либо через burndown chart для всего проекта (в Scrum), либо с помощью lead time (в Kanban). Оценка сложности задач влечет за собой и оценку сроков — через тройку итераций или задач становится ясной скорость, на основе которой можно давать оценку даты окончания.

В данном посте ход проекта моделироваться не будет (это вообще себе вполне отдельная задача), а будет сравниваться эффективность плановая.

«На кончике пера»


План представим как две составляющие:
  • Суммарное количество единиц (аналог storypoints) сложности задач на весь продукт проекта (P),
  • Количество привлекаемого в момент t персонала n(t) <= N (равенство в случае Agile).

Далее, обозначим как r — время на реализацию одной единицы сложности задачи одним специалистом, c — стоимость одного специалиста за единицу времени, T назовем суммарное время проекта, S — его бюджет, p=p(t) — количество выполненной работы на момент времени t.

Тогда для Agile мы имеем, что за единицу времени мы выполним столько работы, сколько N человек выполняют за раз единиц задачи:

p'A(t) = N / r => (зная, что вначале выполненной работы нет) pA(t) = N * t / r.

Откуда, собственно, ясно следующее:

TA = r * P / N; SA(t) = c * N * t; SA = c * r * P.

это всё и так ясно вообще-то
Очевидно же, сколько в сумме человек поработают, да помножить на время, да на стоимость, столько и будет стоить проект. В то же время он стоит столько, сколько стоит решить одну задачу, помножить на количество задач.


На этом пока с Agile закончим, к счастью модель его плана оказалась (в моей версии) достаточно проста. Всё становится сложнее с Waterfall-планом, так как в нём привлекаются специалисты по ходу проекта. При этом, однако, остается основное соотношение:

p'(t) = n(t) / r.

Всё дело в выборе функции n(t). Мы знаем, что в нуле она ноль, и в конце проекта — ноль. Больше мы ничего не знаем. Далее будем предполагать, что она симметричная, достигает в середине значения N, и растет квадратично (я выбрал квадратичную функцию из тех соображений, что это простейший вариант при заданных условиях).

n(t) = N * 4 * (T — t) * t / T2.

Зная, что p(0) = 0, можно выписать интеграл p'(t):

p(t) = 2 * N * t^2 / (r * T) — 4 * N * t^3 / (3 * r * T^2) => T = 3 * P * r / (2 * N).

О! А вот это уже интересно! При выбранном законе привлечения команды к проекту по времени, длина проекта вырастает в полтора раза! А ведь ситуация с привлечением не всего персонала сразу типична для Waterfall.

это всё опять-таки интуитивно
Ясно, что если люди делают задачи сразу, то это сокращает срок. В то же время, если всё время задействован максимум — N человек — то это и есть ситуация минимума для времени проекта.


Что у нас со стоимостью? Её также можно найти интергированием (по t).

s'(t) = c * n(t) => s(t) = 2 * c * N * t^2 * (3 * T — 2 * t) / (3 * T^2),

откуда

SW = 2 * c * N * T / 3 = c * P * r.

Бюджет тот же.

неудивительно
И с чего ему быть другим, если объем работ тот же?


Кривые


Убедимся, что мы получили S-кривую на отрезке [0; T]. Подставим значения с = 1, r = 2, P = 100, N = 10 и получим T = 30.

График p = p(t) для Waterfall:


График s = s(t) для Waterfall:


S-образная кривая
Это не логистическая кривая, так как у нас план определяет количество выполненной работы в момент времени, а не количество человек зависит от того, сколько работы в какой момент должно быть выполнено.


Немного выводов



Кто-то сочтет данный пост капитанством, и будет недалек от истины. Ведь конечно, модели слегка «людоедские», и не учитывают изменения (которые, в сущности, являются обновлениями планов). В то же время, если собирать различное количество человек на Waterfall и Agile, сроки можно будет сравнять, но бюджеты будут различны.

Я не буду говорить, что Agile оптимален (несмотря на то, что это экстремум по срокам при таком моделировании) — слишком много упрощений в моделях. Но вполне возможно, что рассмотренная механика объясняет некоторую разницу между эффектами при различных подходах, и кто-то возьмет на вооружение рассмотренный принцип для оптимизации своих проектных планов: привлекать как можно большее количество человек к решению задач сразу — может снизить срок при сохранении бюджета (хотя и может казаться, что бюджет увеличится).
Андрей @S_A
карма
33,7
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • 0
    В формулах несколько ошибок:

    Во-первых, r — функция, и сложность — тоже функция.

    r = rand(min,max) — время на реализацию одной единицы сложности ©
    C — оценка сложности, которая находится в диапазоне от 1 до реальной сложности.

    При этом при при рассчёте мы используем оценку сложности, а при реализации тратим время согласно реальной сложности.
    • +1
      Был выбран немного другой подход. Сравнивалась только плановая эффективность (рандомизация — это уже моделирование хода, пусть даже при анализе рисков, и да — не очень хотелось пока что решать с.д.у.). А за r было обозначено время решения одной сторипоинт, сложность всего продукта — за P. Для большей сопоставимости моделей я предпочел использовать единообразно подходящие параметры.
      • –2
        Я, на самом деле, намекаю на то, что все сторипоинты, оценки сложности и т.д. чаще всего — ничем необоснованное ИМХО человека. То есть я за свою бытность ни разу не видел, чтобы хоть кто-то мог адекватно оценить сложность решения задачи. Даже без учётов риска вида «я там открыл код — а там бездна и переписывать». Даже автономные безрисковые задачи, выходящие за рамки тривиальных, и те не возможно оценить адекватно.

        … Более того, лично я по своему опыту могу сказать, что сложность реализации задачи чаще всего зависит даже не от собой задачи (если только в ходе реализации механической яйцебойки не нужно доказать P=NP), а зависит от контекста и предыдущих задач. То есть с точки зрения планирования, просто непредсказуема.
        • +1
          И кому можно продать такой подход? Я не против (того же) time & material. Как мне видится, для «предсказуемости» и были придуманы инструменты и процессы УП (и тот же Waterfall). Я от оценки сложности (и хода проекта) абстрагировался, обратив внимание только на план по ресурсам, потому как это основной драйвер стоимости (при той же продаже), и в том числе сроки — важнеший параметр при принятии решения. А в вашей постановке задачу объять — это куда как более серьезный мех.
          • +1
            Не могу сказать ничего про продажу, я скорее про реальность. То есть главный плюс agile состоит в том, что если какой-то этап оказался max_implement(max_time(expected)) вместо implement(time(expected)), то есть, внезапно, оно оказалось адски сложным и нереализуемым за разумное время, это не стопит весь конвейер, а позволяет просто отложить проблему или даже отказаться от конкретной фичи. Причём проблема будет понятна прямо тут, а не к моменту, когда всё уже ожидает этой фичи и она жизненно необходима.

            Если совсем просто говорить, куда проще вести машину, постоянно корректируя руль, чем выставив один раз руль и надеяться, что машина будет ехать строго прямо, только прямо и никак иначе, чем как запланировано в начале.
            • 0
              Для кого-то и продажи — реальность.
              А касательно корректировки — по-вашему в Waterfall-проектах не бывает изменений?
              Вы снова про ход проекта говорите. Я об этом написал, что это не рассматривается.
  • 0
    Статью плюсую, ибо считаю, что уже сама попытка что-то смоделировать и вывести формулу для практического применения достойна похвалы. Но вообще говоря, содержимое статьи вызывает противоречивые чувства, и практически по каждому пункту можно дискутировать. Но чтобы не ломать копья зазря, я бы Вам посоветовал:

    1. Чётче обозначить цели Вашего исследования (это сравнительный анализ или что?) и описать соответствующие им полученные результаты.
    2. Очертить границы рассматриваемых случаев и допустимости применения Ваших методов. Допускаю, что в отдельных случаях, оценка трудозатрат с применением Вашего подхода может быть вполне приемлемой (с оглядкой на трудозатраты по получению самой оценки). Но всё же следует это всё оговорить. Вот Вы строите графики для N=10, а мне мой опыт подсказывает, что проект с 10-ю разработчиками – это уже весьма объёмный проект. И здесь если и применять грубые оценки, то только совместно с риск-менеджементом и резервированием времени/бюджета.

    Из замечаний по сути я особо выделил момент с n(t):
    1. Всё-таки делать какие-то выводы на одном-единственном примере не айс. Тем более что у меня лично, как сталкивавшегося в основном именно с водопадом, есть возражения по поводу типичности такого примера с колоколообразной функцией распределения.
    2. Эта функция в принципе не может быть непрерывной. Сразу вспоминаются 2,5 землекопа из Страны невыученных уроков. ;-)))
    • 0
      Спасибо за отзыв. Конечно же, в посте (не в статье… это скорее что-то из жанра записок на салфетках) много пробелов.
      Целью исследования было установить, при каких условиях Agile и Waterfall эквивалентны, но при так поставленной задаче, как я её поставил, я выяснил другое. К счастью, не к счастью — на усмотрение читателя.

      По поводу n(t) и Waterfall (по которому я также в основном и управлял по большей части, и даже моя записка пока меня не до конца переубедила) — если функция привлечения персонала — не «колоколообразная», то S-кривую мы не получим… а насчет непрерывности — то просто с непрерывными моделями иметь дело проще. Если обратить внимание на другие комментарии, то предлагают еще и случайные величины задействовать. И (лично мне) наверное даже проще было бы решить стохастическое дифференциальное уравнение, моделирующее ход проекта (например, отклонение от плана взять за искомую функцю), чем оперировать суммами. Замечание я тем не менее взял себе на заметку, спасибо.
  • 0
    Если б математику можно было прикладывать к поведению людей, давно бы уже исчезли роли ПМов, директоров и проч.
    Поведение людей различно в различных сложных системах управления, а также поведение разных людей различно. Просто потому, что люди разные.

    Исходя из этого основной постулат о неизменности оценки задачи нам всё рушит. Это допущение критично.
    • 0
      основной постулат о неизменности оценки задачи нам всё рушит. Это допущение критично.

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

      К сожалению, на данный момент я (уже, и, возможно, еще) не владею свободно аппаратом с.д.у., а так бы с удовольствием бы модель улучшил. И давайте представим на секундочку, что r случайно. И P случайно. Вашим выбором всё равно останется сколько и кого когда привлекать (что и есть задача ПМ, которая не исчезнет думаю никогда).
      • 0
        В реальности и r случайно и P, причём в разных стратегиях они случайны по разному. В разных комбинациях людей они также случайны по разному. Т.е. случайность в кубе.

        И да — люди не ресурсы, не единицы, не переменные и не параметры.
        • 0
          В реальности
          Ну а контракты только в математике встречаются?
          И да — люди не ресурсы, не единицы, не переменные и не параметры.
          Я читал манифест Agile. Как впрочем и Waterfall не утверждает подобного. Как и я.

          Я утверждаю, что решение кого и когда привлечь, и в каком количестве — задача менеджера проекта. И когда проект еще не стартовал — это его задача планирования, где еще нет той «реальности». Неужели сидит менеджер проекта, открывает MS Project, ему отображается пустой проект, и он думает… «всё случайно». Закрывает MS Project, занавес. Нет конечно. План, как и любая другая модель, базируется на допущениях. План является основой для оценки бюджета. Покупать time & material желающих мало.
  • 0
    «Очевидно же, сколько в сумме человек поработают, да помножить на время, да на стоимость, столько и будет стоить проект. В то же время он стоит столько, сколько стоит решить одну задачу, помножить на количество задач.»

    Это справедливо, если вообще нет никаких рисков, что нереально. А если и реально, то этот проект стоит выбросить на помойку, т.к. если в проекте вообще нет рисков, то он не принесёт никакой выгоды.
    • 0
      Риски — отдельный вопрос для моделирования. Риски бывают разные. Но в целом, давайте себе представим два основных риска:
      1. Новая или неучтенная задача: эквивалентно увеличению P.
      2. Задержки исполнения задач: эквивалентно увеличению r.
      Если детерминированная модель устраивает — риски можно резервировать именно этими величинами.

      Однако не стоит отождествлять модель плана, план, и управление проектом, таким какое оно есть.
      • 0
        Но ведь вы сравниваете водопад и гибкие методологии.
        Разница между ними помимо подхода к планированию как раз в реакции на изменения и в конечном итоге в стоимости изменений и всего проекта в целом, которые чаще всего вызваны именно исполнением рисков.
        И при этом в своём моделировании риски вы не учитываете вовсе.
        Статья интересная, но, наверное, есть смысл подумать, как эти риски в вашем моделировании учесть. То, как вы попытались это сделать выше, — это слишком просто. Когда срабатывает риск — это не только новая или неучтённая задача и не только задержки исполнения задач. Это ещё много чего.
        Кроме негативных рисков, которые принято называть просто рисками, существуют позитивные риски, которые называют возможностями. Таким образом, в результате срабатывания тех или иных рисков у вас часть задач вообще может отвалиться, могут возникнуть новые, может на ровном месте измениться стоимость той или иной задачи, могут быть ещё масса изменений, которые в ваше моделирование вписать не так-то просто.
        • 0
          Анализ рисков — моделирование хода проектов. Что касается реакции на изменения… рассмотрите любое отклонение от плана как новый проект (проект с новыми параметрами, начатый в момент внесения изменений, у которого p(0) > 0).«Мягкое» моделирование нам и подсказывает, что гибкий подход справится с ним быстрее.

          Риск — это событие. Событие, будучи не заложеным в план, не является частью плана (и частью, соответственно, модели).

          То, как я попытался сделать это выше, и действительно несложно — и я об этом дважды или трижды сказал в той или иной форме. А так, лучше формализовать, чем нет, это раз, во-вторых я не просто так привел цитату Макконнела.

          А в целом я чую запрос аудитории, конечно же. Смоделировать и план, и факт, это было бы весело. Просто обещать ничего не могу — я не писатель статей для Хабра по профессии. Есть свободное время — пишу… и не обещаю как раз, потому что знаю что у меня его мало.
          • 0
            Понятно.
            Спасибо, тогда будем ждать и надеяться на продолжение вашей статьи.
            • 0
              Разоткровенничаюсь немного — я изначально собирался рассматривать отклонения от плана.
              Но для этого нужен другой инструментарий: одними дифурами тут не обойдешься.

              Во-первых, действительно, отклонения случайны --> надо использовать либо с.д.у. либо Монте-Карло.
              На с.д.у. я когда-то специализировался, но, увы, это было лет 10 назад. Что касается Монте-Карло, то тут выходом был бы Excel (электронные таблицы в смысле), но ММК — это не аналитическое решение, которые я всё же предпочитаю.

              И даже в этом случае выбор распределения с.в. был бы всегда спорным.

              Выходом было бы, возможно, использование Modelica, но поставить OpenModelica под linux свой пока руки не доходят, да и random там не сказать что из коробки (его нужно самому делать). Даже не уверен, что оптимизационные задачи будут корректно решены при рандомизации в моделике.

              Поэтому выше я уже писал — что это серьезная задача с вычислительной точки зрения. С одной wolframalpha.com уже не решишь. А за интерес — спасибо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.