G>>всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
A>Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

Прочитайте книгу Agile Estimation and Planning, там довольно много про DoD (Definition of Done, не Department of Defense). Тогда, возможно, вам и вовсе откроются "тайные знания", не просто жемчужины, а таки бриллиантовая шахта.

S> а потом тупо соврал — сказал, что в enterprise версии MS Project есть сравнивалка проектов, которая позволяет нормально посмотреть, что изменилось за год.

Кстати, а она есть, сранивалка такая? Я не видел, но я, опять же, не эксперт.
Кто вас обучал проджекту?

Здравствуйте, Sinclair, Вы писали:

S>При этом сам Гапертон PERT критикует. Вообще, PERT решает всего лишь одну проблему...

И кстати, хочу обратить твое внимание на один момент.

Из всех известных человечеству на данный момент "не матанистых" методов оценки сроков, PERT — единственный, который в принципе позволяет учесть риски в прогнозе сроков. В этом его огромная практическая ценность. "Продвинутые" методы, основанные на метриках, включая их апофеоз и концентрат, доведенный до маразма — PSP/TSP, этого сделать не позволяют.

"Матанистая" группа методов основана на моделировании монтекарло. Она требует серьезной поддержки тулами, и куда больших затрат на применение либо высокого порога вхождения. Есть, например, соответствующие плагины для MS Project — с ними надо весьма хорошо понимать, что ты делаешь.

Огромный практический (не теоретический) плюс PERT Estimation состоит в том, что он настолько прост, что любой человек в состоянии его применить в excel или на бумажке. Это драматически увеличивает практические шансы на то, что ты его в нужный момент применишь, и применишь его правильно.

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

Я тебе буквально как врач говорю. А врачам надо верить, как себе .

Здравствуйте, Gaperton, Вы писали:

G>Из всех известных человечеству на данный момент "не матанистых" методов оценки сроков, PERT — единственный, который в принципе позволяет учесть риски в прогнозе сроков. В этом его огромная практическая ценность. "Продвинутые" методы, основанные на метриках, включая их апофеоз и концентрат, доведенный до маразма — PSP/TSP, этого сделать не позволяют.

Впрочем, я в свое время разработал метод, который объединяет плюсы PERT Estimation и методов, основанных на метриках. Очень простой, и на практике невероятно точный — сравним с PSP/TSP. Помнится, года 4 назад докладывал его на конференции Oracle для партнеров. Вот здесь ссылки на презентации.

http://gaperton.livejournal.com/34265.html

Здравствуйте, Gaperton, Вы писали:

G>http://gaperton.livejournal.com/34265.html

Презентация, кстати, говно. Не умел я тогда еще делать презентаций.

Здравствуйте, Gaperton, Вы писали:

G>>>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.
G>>>И если этот критерий звучит как "программист Вася сказал, что написал класс Х, и осталось только отладить", то такую задачу нет никакого смысла выделять.

A>>Вот очередная жемчужина (для меня). Ответ только для того, чтобы она не затерялась.

G>Поищи у меня в блоге по "декларативное планирование", там тема раскрыта подробнее . На этом целый метод построен.
Я додписан на твой блог. Периодически перечитываю некоторые статьи. Пишешь ты не часто (я понимаю, что нету времени), но по делу. Спасибо.

G>Я про него доклад делал на одном из SoftwarePeople.
Насколько я помню, там про виселицу было (Вот мало что помню с тово доклада, а виселицу хорошо запомнил. Как интересно память устроена )
Гапертон, можно ли где-то видео последнего твое доклада взять? Презентацию я уже раза три смотрел. Но хотелось бы и видео. Особенно интересую последние 2 слайда. И, кстати, в середине доклада тоже есть про такой подход, но вскользь.

По поводу конкретно этой "жемчужены".
Не могу сказать, что я о таком не читал. И декларативное планирование я читал и про "definition of done" я тоже читал. Но как-то это были теоретические знания. По принципу: в одно ухо влетело, в другое вылетело.
Тут же произошло некое озарение. То ли накопился критический объем знаний и оно "жахнуло" То ли твое сообщение легло на нужный момент времени (я как раз тогда, и сейчас, был плотно занят анализом и оценкой задач.
В общем, спасибо!

Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей

СУВ, Aikin

Здравствуйте, Gaperton, Вы писали:

G>> Да мне побоку.
G>Я знаю. Именно поэтому ты в моем журнале комментарии оставлять и не можешь.
Сорри. Я не пробовал. А что, действительно не могу?

По правде, я не оставляю коментарии из-за боязни спроть чушь. Т.е. "бан" у меня внутри. Не знал, что он так же есть "снаружи".
Но это фигня. Я не знаю когда дорасту до уровня, когда смогу спросить что-то действительно стоящее.

СУВ, Aikin

G>Ты хочешь, чтобы я его тебе в деталях, подробно, и по шагам воспроизвел в форуме? Зачем? Тебе что-то мешает самому нажать кнопку Help?

Извиняюсь что заползаю в дискуссию — зачем на форуме? Думаю, многие вам будут благодарные, а сами вы получите еще +20 к известности и +1 к менеджерству если создадите несколько статей на хабре. Я, например, потихоньку перевожу туда свои знания об управлении — иногда достаточно интересный фидбек всплывает. Намного более ценный, чем часы, потраченные на написание:

http://habrahabr.ru/post/126104/

G>А вот к "разбиению задачи на подзадачи" это не приводит. Я понимаю, что это сейчас для вас звучит странно. Чтобы оно было не так странно, надо понимать принцип, как правильно выделять задачи. Это, в общем, разговор долгий, но если кратко и о главном — всегда начинать надо с детального анализа критерия завершения задачи. Ответа на вопрос "как я проверю, что задача завершена". А вовсе не с фантазий о том, что ты будешь делать в процессе.

Надеюсь, никто не обидится если я и сюда заползу?

Досточтимый и многомудрый Gaperton, а почему вы считаете что для любой задачи основное — это критерий завершения? Насколько я помню, процессы обычно подгоняют под наиболее частый случай. Если у нас при копании траншей наиболее частый случай — "выкопали", то ежу понятно что основное что нам о задаче интересно — это "выкопали или не выкопали". Варинт "копали, выкопали трубопровод, теперь не знаем что делать" случается очень редко, мы его рассматриваем как исключение.

Разработка программного обеспечения — область ебанутая сложная отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день. Очень редко случается что мы в последующем проекте применяем точно те же технологии что и в предыдущем, для решения тех же задач. Потому как у нас нулевая цена копирования и если кто-то уже выокпал траншею — нам не нужно копать следующую. Мы копируем уже выкопанную. Так что каждый следующий проект — это копание траншей новой формы на новой планете с не очень понятными физическими законами и с новым набором инструментов. И вариант что оно выкопалось — это не самый частый случай. Самый частый случай — это выкопались те или иные проблемы, с которыми мы как-то работаем дальше — начиная от разбиения задачи и заканчивая ее изменением / отменой.

Вы согласны с вышеизложенным? Или считаете что критерий "выполнено/не выполнено" основной вне зависимости ни от чего?

Здравствуйте, stranger_v, Вы писали:

C>>Project более подходит для проектов по копанию траншей. Где «могу копать. могу не копать.» и все работники взаимозаменяемы.

_>Да ну? А как хотя-бы примерно рассчитать сроки и объяснить их заказчику без подобного механизма? Я не вижу альтернативы, мы же разрабатываем софт не для себя, а для заказчика, где есть вполне конкретные бюджеты и сроки.

А если по-честному, то никак. Эстимейт проектов ПО это столь же научная задача, как предсказание курса колебания валют в течение дня. Можно сделать эстимейт, можно придумать число от балды, можно погадать на кофейной гуще.

Я работал с большой аутсорсинговой компанией (одной из крупнейших в РФ, да и в мире наверно), мы заказывали у них пару проектов. И шо вы думаете, как они работают? По принципу «главное ввязаться в бой». В первом проекте первоначальный план и эстимейт не имел ничего общего с тем, как оно в итоге оказалось. А во втором мы их просто послали, потому что они сразу выдали смехотворно нереалистично маленький эстимейт для крайне сложной задачи.

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

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

EOH>Разработка программного обеспечения — область отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день.

После определенного срока в отрасли приходит понимание, что написанное вами — (само)обман.

EOH>>Разработка программного обеспечения — область отличная от копания траншей. И от вытачивания заготовок на станках — тоже. У нас как раз ситуации когда "копали, а ночью все само зарасло", "копали — выкопали BSOD", "копали — докопались до лавы" — это то, что случается каждый день.
SD>После определенного срока в отрасли приходит понимание, что написанное вами — (само)обман.

Какие-нибудь факты, аргументы? Если делать одинаковые веб-странички на одном и том же стеке технологий — то да, оно в целом предсказуемо и подземного стука не будет. Но, к сожалению, разработка программного обепсечения не ограничивается веб страничками и распилом "бизнес автоматизации" .

EOH>Какие-нибудь факты, аргументы?

Опыт.
Девелопмент может быть хаотичным. Но не обязан им быть. Задачей РМ является превращение естественного хаотичного процесса в искусственный, но направленный процесс создания ПО.

Здравствуйте, Sinclair, Вы писали:

S>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).

И на что ты его поменял?

Здравствуйте, Аноним, Вы писали:

S>>1. с тех пор, как я бросил проджект менеджмент, люди придумали много интересных теорий (большинство из которых не очень хорошо применимы на практике).
А>И на что ты его поменял?
на менеджмент продуктов. Людьми я управлять не люблю. Понятия не имею, чего все так стремятся к этой "власти". Управлять требованиями гораздо интереснее.

Здравствуйте, Aikin, Вы писали:

A>Насколько я помню, там про виселицу было

Виселица была в докладе о рисках. Это о другом. Насчет видео — организаторов тряхну. По поводу декларативного планирования — помимо презентации (одной, на первом SWP) есть посты в ЖЖ, которые суть тексты, а не слайды. Ключевое слово рулит.

A>Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей

По настоящему торкнет тогда, когда ты себе запретишь ставить задачу, не имея внятного (а не булшытного) критерия ее завершения. Это просто — запрети себе писать названия задач. Полностью замени их списком критериев завершения каждой.

В самом деле — а как ты поймешь, что задача завершена, если не знаешь критерия ее завершения? Подумай. Это ж нонсенс. А исполнителям — как задачу выполнять, не зная, когда она завершена?

Здравствуйте, Gaperton, Вы писали:

G>Виселица была в докладе о рисках. Это о другом. Насчет видео — организаторов тряхну. По поводу декларативного планирования — помимо презентации (одной, на первом SWP) есть посты в ЖЖ, которые суть тексты, а не слайды. Ключевое слово рулит.
Та я читал. Не созрел еще. Да и не надо оно пока мне. У меня пока менеджмент на уровне6 не забыл все таски сделать. Вопрос о сроках хоть и стоит, но не так жестко.


A>>Но, все равно, сказать по правде, я не делаю детальный анализ критерия завершения задачи. Умом понимаю, что так правильно. Но что-то (похоже лень и мысль: "сто раз так делал") мешает Убеждаю себя что мои задачи мелкие и в них не будет неоднозначностей
G>По настоящему торкнет тогда, когда ты себе запретишь ставить задачу, не имея внятного (а не булшытного) критерия ее завершения. Это просто — запрети себе писать названия задач. Полностью замени их списком критериев завершения каждой.
G>В самом деле — а как ты поймешь, что задача завершена, если не знаешь критерия ее завершения? Подумай. Это ж нонсенс. А исполнителям — как задачу выполнять, не зная, когда она завершена?
Давай попробуем, хорошо?

Вот 10 минут назад создал таску:
Название: Add configurable XXX field into YYY window for TBM
Описание: we need a new input field for TBM in the YYY window to scan xxx as briefly discussed last week
This should be configurable. when this is shown the app should not create its own barcode and take it from this input field

Ясно что 100% булшыт. Но, я полностью знаю что нужно сделать, это обсуждалось с заказчиком на прошлой недели, подводных камней тут не будет (это поле нужно для перестраховки, если автоматический сканер не сработает и ручной тоже не пашет).
Этот таск займет 2 часа от силы. Да его больше описывать, чем кодировать

Попробую:
Пользователь может ввести XXX баркод вручную в окне YYY, который будет присвоен новой детали в таблице ZZZ
Если эта функция отключена в конфигурации, то поле не показывается и новый баркод генерится программой
Достаточно или более детально?


Получилось практически то же самое, что и в описании, но человек со стороны сможет легко разобраться что же мы там "briefly discussed last week". И ему не придется думать "а может они что-то еще там надискасили, а я не знаю".
Думал я от силы 3 минуты, писал еще 3. Неплохо.
Ну и как бонус получил тестплан, съэкономлю время когда тестер не придет ко мне спрашивать что же тут тестировать.

Хмм, интересно. Надо попробовать более сложный таск "перефигачить".


СУВ, Aikin

Здравствуйте, Aikin, Вы писали:

A>Получилось практически то же самое, что и в описании, но человек со стороны сможет легко разобраться что же мы там "briefly discussed last week". И ему не придется думать "а может они что-то еще там надискасили, а я не знаю".
A>Думал я от силы 3 минуты, писал еще 3. Неплохо.
A>Ну и как бонус получил тестплан, съэкономлю время когда тестер не придет ко мне спрашивать что же тут тестировать.

Вот, ты все правильно понял.

A>Хмм, интересно. Надо попробовать более сложный таск "перефигачить".

Более сложный таск ты сможешь декомпозировать на мелкие так: cмотришь на перечень критериев проверки, и задаешь себе вопрос: "что из этого я могу проверить независимо?" А потом — второй вопрос: "в каком порядке я могу это делать?" А потом, после подразбиения на задачи со связями, задаешь себе третий: "а что мне еще надо, чтобы иметь возможность все это проверить, как написано?" И дописываешь то, что забыл.

И ты получаешь мое декларативное планирование.

Здравствуйте, Gaperton, Вы писали:

G>И ты получаешь мое декларативное планирование.

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

А главная его особенность в том, что ты попросту не сможешь запланировать по этой методике активность, результат которой плохо себе представляешь (потому, что "активности" в ней отсутствуют). За, если ты хорошо себе представляешь, что и зачем ты делаешь — план пишется просто и прямолинейно, без задумий и ломании могза.

Здравствуйте, Aikin, Вы писали:

Удивительно, что ты один из моих лучших "учеников". Хотя и не работаешь со мной лично (узкий канал коммуникации) — но понимаешь с полуслова, и до кучи еще и регулярно срешься в мной комментах.

Впрочем, как говорят знающие люди, последнее качество всегда отличало годного combat officer . Предлагаю как-нибудь лично познакомиться на каком-нибудь мероприятии, конференции например. Почта как ник в gmail, если есть желание пиши.