Комментарии 42
НЛО прилетело и опубликовало эту надпись здесь
Не нравятся беременные женщины — можно про грибы:
Мальчик за 1 час в среднем собираeт 3 кг грибов, а девочка — 2 кг грибов.
Но это не значит, что они в лесу вместе за 1 час соберут 5 кг грибов.
Мальчик за 1 час в среднем собираeт 3 кг грибов, а девочка — 2 кг грибов.
Но это не значит, что они в лесу вместе за 1 час соберут 5 кг грибов.
НЛО прилетело и опубликовало эту надпись здесь
Афоризму про «9 месяцев» сотни лет. И он отлично соответствует содержанию статьи!
А про грибы лучше перефразировать, а то в коментах уже споры пошли:
Если мы выпустим в лес молодого парня, то он соберет 3 кг ягод, если девушку-то 5 кг. Но это еще не значит, что, если мы выпустим их в лес вместе, то они соберут 8 кг ягод ;)))
А про грибы лучше перефразировать, а то в коментах уже споры пошли:
Если мы выпустим в лес молодого парня, то он соберет 3 кг ягод, если девушку-то 5 кг. Но это еще не значит, что, если мы выпустим их в лес вместе, то они соберут 8 кг ягод ;)))
Пример с грибами, как мне кажется, не совсем корректен: зависимость сбора грибов от количества людей вполне может быть простой, а тема статьи подразумевает учет нелинейных эффектов, как необходимость времени на обучение, усложнение коммуникации в большей команде и прочие.
s/ за 1 час соберут 5 кг грибов / будут собирать грибы /g
Я, чего-то в примере не понял, наверное, но как раз вместе они соберут те 5 кг грибов.
Наверное имелось в виду что в лесу всего, например, 4 кг грибов находится :)
Зависит от того, где будут собирать. Если каждый на своей отдельной территории, то да 5 кг.
А если они будут рядом это делать, то плотность покрытия поверхности грибами упадёт — а она влияет на число собранных грибов за еденицу времени.
А если они будут рядом это делать, то плотность покрытия поверхности грибами упадёт — а она влияет на число собранных грибов за еденицу времени.
Если мальчику и девочке каждому по 18 лет, то это не значит, что оказавшись в лесу каждый с лукошком, они займутся сбором грибов...Ведь есть другие более интересные и уврекательные занятия.
НЛО прилетело и опубликовало эту надпись здесь
Автор топика — гуру аллегорий.
Можно тогда сказать так: 1 программист напишет эту программу за год. Но это не значит, что 365 программистов напишут её за 1 день.
В общем классная статья, спасибо!.. В универе мой профиль как раз системы поддержки принятия решений. Направление классно и перспективное, но сложное :) Самом пробовал моделирование только в GPSS World. Надо попрбовать в остальных пакетах, приведенных в этой статье. Еще раз — спасибо!
про это очень хорошо у Брукса написано.
Злободневно для меня. Спасибо.
Очень подробно тема раскрыта, спасибо.
P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.
P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.
отличный пост, очень интересно, спасибо.
Статья близка с темой моей научной работы, а потому хочу поинтересоваться полезными готовыми моделями, которые связанны с течением проектов (можно не только по разработке ПО).
От себя могу добавить работы Форда (в частности его диссертацию) и книгу Software Process Dynamics by Raymond J. Madachy.
И, хоть и отклоняясь от темы топика, было бы интересно посмотреть на данные по ходу реальных проектов, чтобы можно было позднее на них проверять предположения, заложенные в модели, если такие материалы где-то есть в открытом доступе и кто-нибудь поделится информацией.
От себя могу добавить работы Форда (в частности его диссертацию) и книгу Software Process Dynamics by Raymond J. Madachy.
И, хоть и отклоняясь от темы топика, было бы интересно посмотреть на данные по ходу реальных проектов, чтобы можно было позднее на них проверять предположения, заложенные в модели, если такие материалы где-то есть в открытом доступе и кто-нибудь поделится информацией.
Вот тут много моделей. Посмотрите. Может, найдёте что-нибудь по душе.
Не гарантирую, что именно по процессу, но хоть что-то.
По поводу данных… В открытом доступе такую информацию найти очень непросто. Это самое ценное, что может быть в оценке трудоёмкости — историческая калибровка. Имхо, тот, кто обладает такой информацией, не очень расположен ей делиться. Важно ещё помнить, что данные могут быть очень специфичны для данного места, типа работ и прочих условий. Проецировать их «один к одному» нужно очень осторожно.
Спасибо за ссылку на книгу!
Не гарантирую, что именно по процессу, но хоть что-то.
По поводу данных… В открытом доступе такую информацию найти очень непросто. Это самое ценное, что может быть в оценке трудоёмкости — историческая калибровка. Имхо, тот, кто обладает такой информацией, не очень расположен ей делиться. Важно ещё помнить, что данные могут быть очень специфичны для данного места, типа работ и прочих условий. Проецировать их «один к одному» нужно очень осторожно.
Спасибо за ссылку на книгу!
Конечно, все это красиво и замечательно, но по сути, все эти плюшечки не нужны — такого рода результат можно было получить и просто решив систему уравнений. И одним из основополагающих уравнений является та модель, которую вы так хитро не захотели расписать, чтобы не провоцировать холивары.
Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).
Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).
Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
Хорошая мысль. Я пока писал статью, тоже неоднократно думал об этом (а нужны ли «плюшечки»). Так вот, «плюшечки» всё-таки нужны. «Плюшечки» дают наглядность. В принципе, и без mind maps можно обойтись, оформив всё линейным списком. Но! Ради наглядности идут на усложнение представления. В картинках проще мыслить.
Кроме того, в iThink есть закладка Equation, в которой все необходимые «системы уравнений» создаются самой программой (их можно редактировать) на основе графической модели.
Метрика — это не модель. Я бы не стал смешивать эти понятия.
Насчёт применимости моделей… все модели имеют какие-то ограничения. То, как она будет создана, и то, как будут интерпретироваться результаты целиком зависит от исследователя.
Кроме того, в iThink есть закладка Equation, в которой все необходимые «системы уравнений» создаются самой программой (их можно редактировать) на основе графической модели.
Метрика — это не модель. Я бы не стал смешивать эти понятия.
Насчёт применимости моделей… все модели имеют какие-то ограничения. То, как она будет создана, и то, как будут интерпретироваться результаты целиком зависит от исследователя.
Меня давно уже поражает в людях то, как компьютерные плюшки отучают людей от аналитических моделей в пользу имитационки. Скоро уже и уравнения типа 2х = х + 1 будут методом конечных разностей решать.
Интересный способ заранее определить развитие проекта… Как то даже не задумывался, что есть такое ПО, спасибо за обзор и примеры…
Отличная статья… читаю, а в голове всплывают несколько бывших начальников, произносящих фразу: «Нам нужно сократить сроки, что нужно докупить? Сколько и каких людей нанять? Все решают ресурсы!». А ведь новые люди должны еще «влиться» в коллектив, быстро «проникнуться» проектом.
Почитайте «Мифический человеко-месяц» Брукса, там это все очень подробно и просто объясняется.
www.ozon.ru/context/detail/id/83760/
www.ozon.ru/context/detail/id/83760/
НЛО прилетело и опубликовало эту надпись здесь
Вообще-то в нецензурном варианте, как подконвойные ученые объясняли охране, почему нельзя все решить Давай — Даваем, фраза звучит так — Если бабу вдевятером дрючить она за месяц не родит.
(точнее она вообще не родит)
(точнее она вообще не родит)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему 9 женщин не могут родить ребёнка за 1 месяц или О применении имитационного моделирования в управлении проектами