Comments 18
В формулах несколько ошибок:
Во-первых, r — функция, и сложность — тоже функция.
r = rand(min,max) — время на реализацию одной единицы сложности ©
C — оценка сложности, которая находится в диапазоне от 1 до реальной сложности.
При этом при при рассчёте мы используем оценку сложности, а при реализации тратим время согласно реальной сложности.
Во-первых, r — функция, и сложность — тоже функция.
r = rand(min,max) — время на реализацию одной единицы сложности ©
C — оценка сложности, которая находится в диапазоне от 1 до реальной сложности.
При этом при при рассчёте мы используем оценку сложности, а при реализации тратим время согласно реальной сложности.
Был выбран немного другой подход. Сравнивалась только плановая эффективность (рандомизация — это уже моделирование хода, пусть даже при анализе рисков, и да — не очень хотелось пока что решать с.д.у.). А за r было обозначено время решения одной сторипоинт, сложность всего продукта — за P. Для большей сопоставимости моделей я предпочел использовать единообразно подходящие параметры.
Я, на самом деле, намекаю на то, что все сторипоинты, оценки сложности и т.д. чаще всего — ничем необоснованное ИМХО человека. То есть я за свою бытность ни разу не видел, чтобы хоть кто-то мог адекватно оценить сложность решения задачи. Даже без учётов риска вида «я там открыл код — а там бездна и переписывать». Даже автономные безрисковые задачи, выходящие за рамки тривиальных, и те не возможно оценить адекватно.
… Более того, лично я по своему опыту могу сказать, что сложность реализации задачи чаще всего зависит даже не от собой задачи (если только в ходе реализации механической яйцебойки не нужно доказать P=NP), а зависит от контекста и предыдущих задач. То есть с точки зрения планирования, просто непредсказуема.
… Более того, лично я по своему опыту могу сказать, что сложность реализации задачи чаще всего зависит даже не от собой задачи (если только в ходе реализации механической яйцебойки не нужно доказать P=NP), а зависит от контекста и предыдущих задач. То есть с точки зрения планирования, просто непредсказуема.
И кому можно продать такой подход? Я не против (того же) time & material. Как мне видится, для «предсказуемости» и были придуманы инструменты и процессы УП (и тот же Waterfall). Я от оценки сложности (и хода проекта) абстрагировался, обратив внимание только на план по ресурсам, потому как это основной драйвер стоимости (при той же продаже), и в том числе сроки — важнеший параметр при принятии решения. А в вашей постановке задачу объять — это куда как более серьезный мех.
Не могу сказать ничего про продажу, я скорее про реальность. То есть главный плюс agile состоит в том, что если какой-то этап оказался max_implement(max_time(expected)) вместо implement(time(expected)), то есть, внезапно, оно оказалось адски сложным и нереализуемым за разумное время, это не стопит весь конвейер, а позволяет просто отложить проблему или даже отказаться от конкретной фичи. Причём проблема будет понятна прямо тут, а не к моменту, когда всё уже ожидает этой фичи и она жизненно необходима.
Если совсем просто говорить, куда проще вести машину, постоянно корректируя руль, чем выставив один раз руль и надеяться, что машина будет ехать строго прямо, только прямо и никак иначе, чем как запланировано в начале.
Если совсем просто говорить, куда проще вести машину, постоянно корректируя руль, чем выставив один раз руль и надеяться, что машина будет ехать строго прямо, только прямо и никак иначе, чем как запланировано в начале.
Статью плюсую, ибо считаю, что уже сама попытка что-то смоделировать и вывести формулу для практического применения достойна похвалы. Но вообще говоря, содержимое статьи вызывает противоречивые чувства, и практически по каждому пункту можно дискутировать. Но чтобы не ломать копья зазря, я бы Вам посоветовал:
1. Чётче обозначить цели Вашего исследования (это сравнительный анализ или что?) и описать соответствующие им полученные результаты.
2. Очертить границы рассматриваемых случаев и допустимости применения Ваших методов. Допускаю, что в отдельных случаях, оценка трудозатрат с применением Вашего подхода может быть вполне приемлемой (с оглядкой на трудозатраты по получению самой оценки). Но всё же следует это всё оговорить. Вот Вы строите графики для N=10, а мне мой опыт подсказывает, что проект с 10-ю разработчиками – это уже весьма объёмный проект. И здесь если и применять грубые оценки, то только совместно с риск-менеджементом и резервированием времени/бюджета.
Из замечаний по сути я особо выделил момент с n(t):
1. Всё-таки делать какие-то выводы на одном-единственном примере не айс. Тем более что у меня лично, как сталкивавшегося в основном именно с водопадом, есть возражения по поводу типичности такого примера с колоколообразной функцией распределения.
2. Эта функция в принципе не может быть непрерывной. Сразу вспоминаются 2,5 землекопа из Страны невыученных уроков. ;-)))
1. Чётче обозначить цели Вашего исследования (это сравнительный анализ или что?) и описать соответствующие им полученные результаты.
2. Очертить границы рассматриваемых случаев и допустимости применения Ваших методов. Допускаю, что в отдельных случаях, оценка трудозатрат с применением Вашего подхода может быть вполне приемлемой (с оглядкой на трудозатраты по получению самой оценки). Но всё же следует это всё оговорить. Вот Вы строите графики для N=10, а мне мой опыт подсказывает, что проект с 10-ю разработчиками – это уже весьма объёмный проект. И здесь если и применять грубые оценки, то только совместно с риск-менеджементом и резервированием времени/бюджета.
Из замечаний по сути я особо выделил момент с n(t):
1. Всё-таки делать какие-то выводы на одном-единственном примере не айс. Тем более что у меня лично, как сталкивавшегося в основном именно с водопадом, есть возражения по поводу типичности такого примера с колоколообразной функцией распределения.
2. Эта функция в принципе не может быть непрерывной. Сразу вспоминаются 2,5 землекопа из Страны невыученных уроков. ;-)))
Спасибо за отзыв. Конечно же, в посте (не в статье… это скорее что-то из жанра записок на салфетках) много пробелов.
Целью исследования было установить, при каких условиях Agile и Waterfall эквивалентны, но при так поставленной задаче, как я её поставил, я выяснил другое. К счастью, не к счастью — на усмотрение читателя.
По поводу n(t) и Waterfall (по которому я также в основном и управлял по большей части, и даже моя записка пока меня не до конца переубедила) — если функция привлечения персонала — не «колоколообразная», то S-кривую мы не получим… а насчет непрерывности — то просто с непрерывными моделями иметь дело проще. Если обратить внимание на другие комментарии, то предлагают еще и случайные величины задействовать. И (лично мне) наверное даже проще было бы решить стохастическое дифференциальное уравнение, моделирующее ход проекта (например, отклонение от плана взять за искомую функцю), чем оперировать суммами. Замечание я тем не менее взял себе на заметку, спасибо.
Целью исследования было установить, при каких условиях Agile и Waterfall эквивалентны, но при так поставленной задаче, как я её поставил, я выяснил другое. К счастью, не к счастью — на усмотрение читателя.
По поводу n(t) и Waterfall (по которому я также в основном и управлял по большей части, и даже моя записка пока меня не до конца переубедила) — если функция привлечения персонала — не «колоколообразная», то S-кривую мы не получим… а насчет непрерывности — то просто с непрерывными моделями иметь дело проще. Если обратить внимание на другие комментарии, то предлагают еще и случайные величины задействовать. И (лично мне) наверное даже проще было бы решить стохастическое дифференциальное уравнение, моделирующее ход проекта (например, отклонение от плана взять за искомую функцю), чем оперировать суммами. Замечание я тем не менее взял себе на заметку, спасибо.
Если б математику можно было прикладывать к поведению людей, давно бы уже исчезли роли ПМов, директоров и проч.
Поведение людей различно в различных сложных системах управления, а также поведение разных людей различно. Просто потому, что люди разные.
Исходя из этого основной постулат о неизменности оценки задачи нам всё рушит. Это допущение критично.
Поведение людей различно в различных сложных системах управления, а также поведение разных людей различно. Просто потому, что люди разные.
Исходя из этого основной постулат о неизменности оценки задачи нам всё рушит. Это допущение критично.
основной постулат о неизменности оценки задачи нам всё рушит. Это допущение критично.
Секунду. Даже если вы моделируете проект случайными величинами — в контракте прописывается какая-то конкретная дата. И с этим ничего не поделать. Для этого, конечно, не обязательно фиксировать оценки сложности, но конечный срок будет все равно величиной не случайной (мат. ожиданием например).
К сожалению, на данный момент я (уже, и, возможно, еще) не владею свободно аппаратом с.д.у., а так бы с удовольствием бы модель улучшил. И давайте представим на секундочку, что r случайно. И P случайно. Вашим выбором всё равно останется сколько и кого когда привлекать (что и есть задача ПМ, которая не исчезнет думаю никогда).
В реальности и r случайно и P, причём в разных стратегиях они случайны по разному. В разных комбинациях людей они также случайны по разному. Т.е. случайность в кубе.
И да — люди не ресурсы, не единицы, не переменные и не параметры.
И да — люди не ресурсы, не единицы, не переменные и не параметры.
В реальностиНу а контракты только в математике встречаются?
И да — люди не ресурсы, не единицы, не переменные и не параметры.Я читал манифест Agile. Как впрочем и Waterfall не утверждает подобного. Как и я.
Я утверждаю, что решение кого и когда привлечь, и в каком количестве — задача менеджера проекта. И когда проект еще не стартовал — это его задача планирования, где еще нет той «реальности». Неужели сидит менеджер проекта, открывает MS Project, ему отображается пустой проект, и он думает… «всё случайно». Закрывает MS Project, занавес. Нет конечно. План, как и любая другая модель, базируется на допущениях. План является основой для оценки бюджета. Покупать time & material желающих мало.
«Очевидно же, сколько в сумме человек поработают, да помножить на время, да на стоимость, столько и будет стоить проект. В то же время он стоит столько, сколько стоит решить одну задачу, помножить на количество задач.»
Это справедливо, если вообще нет никаких рисков, что нереально. А если и реально, то этот проект стоит выбросить на помойку, т.к. если в проекте вообще нет рисков, то он не принесёт никакой выгоды.
Это справедливо, если вообще нет никаких рисков, что нереально. А если и реально, то этот проект стоит выбросить на помойку, т.к. если в проекте вообще нет рисков, то он не принесёт никакой выгоды.
Риски — отдельный вопрос для моделирования. Риски бывают разные. Но в целом, давайте себе представим два основных риска:
1. Новая или неучтенная задача: эквивалентно увеличению P.
2. Задержки исполнения задач: эквивалентно увеличению r.
Если детерминированная модель устраивает — риски можно резервировать именно этими величинами.
Однако не стоит отождествлять модель плана, план, и управление проектом, таким какое оно есть.
1. Новая или неучтенная задача: эквивалентно увеличению P.
2. Задержки исполнения задач: эквивалентно увеличению r.
Если детерминированная модель устраивает — риски можно резервировать именно этими величинами.
Однако не стоит отождествлять модель плана, план, и управление проектом, таким какое оно есть.
Но ведь вы сравниваете водопад и гибкие методологии.
Разница между ними помимо подхода к планированию как раз в реакции на изменения и в конечном итоге в стоимости изменений и всего проекта в целом, которые чаще всего вызваны именно исполнением рисков.
И при этом в своём моделировании риски вы не учитываете вовсе.
Статья интересная, но, наверное, есть смысл подумать, как эти риски в вашем моделировании учесть. То, как вы попытались это сделать выше, — это слишком просто. Когда срабатывает риск — это не только новая или неучтённая задача и не только задержки исполнения задач. Это ещё много чего.
Кроме негативных рисков, которые принято называть просто рисками, существуют позитивные риски, которые называют возможностями. Таким образом, в результате срабатывания тех или иных рисков у вас часть задач вообще может отвалиться, могут возникнуть новые, может на ровном месте измениться стоимость той или иной задачи, могут быть ещё масса изменений, которые в ваше моделирование вписать не так-то просто.
Разница между ними помимо подхода к планированию как раз в реакции на изменения и в конечном итоге в стоимости изменений и всего проекта в целом, которые чаще всего вызваны именно исполнением рисков.
И при этом в своём моделировании риски вы не учитываете вовсе.
Статья интересная, но, наверное, есть смысл подумать, как эти риски в вашем моделировании учесть. То, как вы попытались это сделать выше, — это слишком просто. Когда срабатывает риск — это не только новая или неучтённая задача и не только задержки исполнения задач. Это ещё много чего.
Кроме негативных рисков, которые принято называть просто рисками, существуют позитивные риски, которые называют возможностями. Таким образом, в результате срабатывания тех или иных рисков у вас часть задач вообще может отвалиться, могут возникнуть новые, может на ровном месте измениться стоимость той или иной задачи, могут быть ещё масса изменений, которые в ваше моделирование вписать не так-то просто.
Анализ рисков — моделирование хода проектов. Что касается реакции на изменения… рассмотрите любое отклонение от плана как новый проект (проект с новыми параметрами, начатый в момент внесения изменений, у которого p(0) > 0).«Мягкое» моделирование нам и подсказывает, что гибкий подход справится с ним быстрее.
Риск — это событие. Событие, будучи не заложеным в план, не является частью плана (и частью, соответственно, модели).
То, как я попытался сделать это выше, и действительно несложно — и я об этом дважды или трижды сказал в той или иной форме. А так, лучше формализовать, чем нет, это раз, во-вторых я не просто так привел цитату Макконнела.
А в целом я чую запрос аудитории, конечно же. Смоделировать и план, и факт, это было бы весело. Просто обещать ничего не могу — я не писатель статей для Хабра по профессии. Есть свободное время — пишу… и не обещаю как раз, потому что знаю что у меня его мало.
Риск — это событие. Событие, будучи не заложеным в план, не является частью плана (и частью, соответственно, модели).
То, как я попытался сделать это выше, и действительно несложно — и я об этом дважды или трижды сказал в той или иной форме. А так, лучше формализовать, чем нет, это раз, во-вторых я не просто так привел цитату Макконнела.
А в целом я чую запрос аудитории, конечно же. Смоделировать и план, и факт, это было бы весело. Просто обещать ничего не могу — я не писатель статей для Хабра по профессии. Есть свободное время — пишу… и не обещаю как раз, потому что знаю что у меня его мало.
Понятно.
Спасибо, тогда будем ждать и надеяться на продолжение вашей статьи.
Спасибо, тогда будем ждать и надеяться на продолжение вашей статьи.
Разоткровенничаюсь немного — я изначально собирался рассматривать отклонения от плана.
Но для этого нужен другой инструментарий: одними дифурами тут не обойдешься.
Во-первых, действительно, отклонения случайны --> надо использовать либо с.д.у. либо Монте-Карло.
На с.д.у. я когда-то специализировался, но, увы, это было лет 10 назад. Что касается Монте-Карло, то тут выходом был бы Excel (электронные таблицы в смысле), но ММК — это не аналитическое решение, которые я всё же предпочитаю.
И даже в этом случае выбор распределения с.в. был бы всегда спорным.
Выходом было бы, возможно, использование Modelica, но поставить OpenModelica под linux свой пока руки не доходят, да и random там не сказать что из коробки (его нужно самому делать). Даже не уверен, что оптимизационные задачи будут корректно решены при рандомизации в моделике.
Поэтому выше я уже писал — что это серьезная задача с вычислительной точки зрения. С одной wolframalpha.com уже не решишь. А за интерес — спасибо.
Но для этого нужен другой инструментарий: одними дифурами тут не обойдешься.
Во-первых, действительно, отклонения случайны --> надо использовать либо с.д.у. либо Монте-Карло.
На с.д.у. я когда-то специализировался, но, увы, это было лет 10 назад. Что касается Монте-Карло, то тут выходом был бы Excel (электронные таблицы в смысле), но ММК — это не аналитическое решение, которые я всё же предпочитаю.
И даже в этом случае выбор распределения с.в. был бы всегда спорным.
Выходом было бы, возможно, использование Modelica, но поставить OpenModelica под linux свой пока руки не доходят, да и random там не сказать что из коробки (его нужно самому делать). Даже не уверен, что оптимизационные задачи будут корректно решены при рандомизации в моделике.
Поэтому выше я уже писал — что это серьезная задача с вычислительной точки зрения. С одной wolframalpha.com уже не решишь. А за интерес — спасибо.
Sign up to leave a comment.
Waterfall и Agile: и всё-таки, откуда эффект?