Pull to refresh

Comments 41

UFO landed and left these words here
Не нравятся беременные женщины — можно про грибы:
Мальчик за 1 час в среднем собираeт 3 кг грибов, а девочка — 2 кг грибов.
Но это не значит, что они в лесу вместе за 1 час соберут 5 кг грибов.
UFO landed and left these words here
Афоризму про «9 месяцев» сотни лет. И он отлично соответствует содержанию статьи!

А про грибы лучше перефразировать, а то в коментах уже споры пошли:
Если мы выпустим в лес молодого парня, то он соберет 3 кг ягод, если девушку-то 5 кг. Но это еще не значит, что, если мы выпустим их в лес вместе, то они соберут 8 кг ягод ;)))
У вас девушка собирает больше парня :)
Замечал, что парни больше в пузо ягоду кидают, чем в лукошко :)
есть подозрения что эти двое вообще не будут ниче собирать, если пустить их в лес вдвоем;)
Пример с грибами, как мне кажется, не совсем корректен: зависимость сбора грибов от количества людей вполне может быть простой, а тема статьи подразумевает учет нелинейных эффектов, как необходимость времени на обучение, усложнение коммуникации в большей команде и прочие.
Не совсем) неочевидно, возможно, но мальчик с девочкой в лесу могут не грибы собирать =)
ах, я всё же не успел соригинальничать =)
С этим не поспоришь)
Подразумевалось, конечно, возможность экстенсивного увеличения результата работы.
Ну допустим, что в лесу находиться 4 кг грибов. В этом случае и мальчик, и девочка отдельно соберут по 3 и 2 кг соответственно.
А если их вдвоем отправить, то больше того, что есть, они не наберут )))
s/ за 1 час соберут 5 кг грибов / будут собирать грибы /g
Я, чего-то в примере не понял, наверное, но как раз вместе они соберут те 5 кг грибов.
Наверное имелось в виду что в лесу всего, например, 4 кг грибов находится :)
А может, они просто подумают, что нафиг им грибы? ;)
Зависит от того, где будут собирать. Если каждый на своей отдельной территории, то да 5 кг.
А если они будут рядом это делать, то плотность покрытия поверхности грибами упадёт — а она влияет на число собранных грибов за еденицу времени.
Т.е. над разными проектами работать?
Да, или над достаточно независимыми компонентами.
UFO landed and left these words here
Автор топика — гуру аллегорий.
Можно тогда сказать так: 1 программист напишет эту программу за год. Но это не значит, что 365 программистов напишут её за 1 день.
В общем классная статья, спасибо!.. В универе мой профиль как раз системы поддержки принятия решений. Направление классно и перспективное, но сложное :) Самом пробовал моделирование только в GPSS World. Надо попрбовать в остальных пакетах, приведенных в этой статье. Еще раз — спасибо!
про это очень хорошо у Брукса написано.
Очень подробно тема раскрыта, спасибо.

P.S. Долго смотрел на все эти краники и квадратики с кривыми, а потом осенило: да это ж тот самый ithink из «Deadline» Тома Демарко. И графики очень близкие. Отличная, все-таки книга.
А потом еще и в тексте заметил туда же отсыл. Чтение по-диагонали до добра не доведет :(
отличный пост, очень интересно, спасибо.
Статья близка с темой моей научной работы, а потому хочу поинтересоваться полезными готовыми моделями, которые связанны с течением проектов (можно не только по разработке ПО).
От себя могу добавить работы Форда (в частности его диссертацию) и книгу Software Process Dynamics by Raymond J. Madachy.
И, хоть и отклоняясь от темы топика, было бы интересно посмотреть на данные по ходу реальных проектов, чтобы можно было позднее на них проверять предположения, заложенные в модели, если такие материалы где-то есть в открытом доступе и кто-нибудь поделится информацией.
Вот тут много моделей. Посмотрите. Может, найдёте что-нибудь по душе.
Не гарантирую, что именно по процессу, но хоть что-то.
По поводу данных… В открытом доступе такую информацию найти очень непросто. Это самое ценное, что может быть в оценке трудоёмкости — историческая калибровка. Имхо, тот, кто обладает такой информацией, не очень расположен ей делиться. Важно ещё помнить, что данные могут быть очень специфичны для данного места, типа работ и прочих условий. Проецировать их «один к одному» нужно очень осторожно.

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

Далее, замечу, то вышеописанный подход применим только к командам, в которых используется инженерная методология разработки проектов (заводская культура). То, что она весьма неудачна, думаю уже знает большинство. Сам ДеМарко уже отказался от повсеместных использований метрик — см. «Software Engineering: An Idea Whose Time Has Come and Gone?» (2009, а не древние книги из прошлого тысячелетия).

Если проект организован грамотно, и например, разбит по проблемам, а не по компонентам (как многие руководители проектов любят делать), то даже при горящих сроках можно нанимать и использовать людей. Потому что новым сотрудникам будут ставится не задачи типа «напиши этот компонент, или срочно исправь 100 багов» (тут кривая обучения будет очень крутая), а «разбирись с этой проблемой и предложи решение, пусть даже не программное» (здесь кривая обучения будет намного сглаженней).
Хорошая мысль. Я пока писал статью, тоже неоднократно думал об этом (а нужны ли «плюшечки»). Так вот, «плюшечки» всё-таки нужны. «Плюшечки» дают наглядность. В принципе, и без mind maps можно обойтись, оформив всё линейным списком. Но! Ради наглядности идут на усложнение представления. В картинках проще мыслить.
Кроме того, в iThink есть закладка Equation, в которой все необходимые «системы уравнений» создаются самой программой (их можно редактировать) на основе графической модели.
Метрика — это не модель. Я бы не стал смешивать эти понятия.
Насчёт применимости моделей… все модели имеют какие-то ограничения. То, как она будет создана, и то, как будут интерпретироваться результаты целиком зависит от исследователя.
Меня давно уже поражает в людях то, как компьютерные плюшки отучают людей от аналитических моделей в пользу имитационки. Скоро уже и уравнения типа 2х = х + 1 будут методом конечных разностей решать.
Интересный способ заранее определить развитие проекта… Как то даже не задумывался, что есть такое ПО, спасибо за обзор и примеры…
Отличная статья… читаю, а в голове всплывают несколько бывших начальников, произносящих фразу: «Нам нужно сократить сроки, что нужно докупить? Сколько и каких людей нанять? Все решают ресурсы!». А ведь новые люди должны еще «влиться» в коллектив, быстро «проникнуться» проектом.
не нужно воспринимать все буквально. если ваш начальник говорил про долгосрочную перспективу, то он прав (хоть Демарко и не согласился бы со мной, говоря, что догонять проект в конце плохая перспектива).
UFO landed and left these words here
У одной женщины может быть несколько детей или ни одного.
Вообще-то в нецензурном варианте, как подконвойные ученые объясняли охране, почему нельзя все решить Давай — Даваем, фраза звучит так — Если бабу вдевятером дрючить она за месяц не родит.
(точнее она вообще не родит)
Only those users with full accounts are able to leave comments. Log in, please.