[business,fuck] Why it sucks
Sep. 30th, 2004 10:21 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
piggymouseВдогонку крику души про sucking Gannt chart. То, что я пытался сказать, не имеет никакого отношения к agile methodologies. То, что я думаю про agile methodologies, это совершеннейший офф-топик в данном случае.
Мысль, которую я имел в виду, такая. Разработка софта, на масштабах времени порядка дня или недели устроена абсолютно не по Ганнту. Там нет фиксированного порядка задач, а зависимости между задачами либо отсутствуют, либо гораздо сложнее того, что можно описать Ганнтом. Поэтому попытки планировать и мониторить разработку софта с помощью Ганнта на всех уровнях рассмотрения приводят обычно к конфузам. Тот, кто пробовал 100% честно сделать baseline планирования, а потом 100% честно отслеживать состояние задач, наверняка помнит чувство ужаса, внушаемое в таком варианте видом Tracking Gannt view. См. также весьма показательное высказывание Яши Сироткина.
Детальное планирование такого рода идеально делается в Экселе (см. классическую статью старого
Не стоит также забывать, что диаграмма Ганнта есть наследие индустриальной эпохи и что любимые иллюстрации в книжках, не заточеннных под IT — про доступное рабочим количество станков и фиксированное время засыхания краски.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-09-29 11:43 pm (UTC)У меня вот наоборот: наверху "метод ограниченного хаоса", а информация по проектам на неделю более-менее структурирована: project там, taskи в, я извиняюсь, Outlook'e. Хотя тут главное у кого какие фломастеры на вкус и цвет, я вот эти -- www.improvement.ru люблю.
PS А Гант сосет, однозначно, во всем кроме конечных автоматов. :)
no subject
Date: 2004-09-30 05:13 am (UTC)По какой причине Гант не сосал бы у конченых автоматов?
При разработке КА-based модулей что, законы другие?
no subject
Date: 2004-10-06 12:47 pm (UTC)no subject
Date: 2004-10-06 01:07 pm (UTC)no subject
Date: 2004-09-30 05:19 am (UTC)А планировать каждый день - это от того, что менеджеров много слишком. Работать не хочет никто - все в менеджеры лезут, и давай планировать! Кайло им в руки и в забой
no subject
Date: 2004-09-30 07:49 am (UTC)То, что ты говоришь, в общем, святая правда (включая, гы-гы, забой). Планировать каждый день в том смысле, что пытаться решить, что именно в этот день делать – это однозначный грех гордыни. Но вот при оценке картина с дискретностью в день строго необходима. Соответственно, в Проджекте мы рисуем длинные задачи уровня итерации (твои "Кодирование" и "Тестирование"), а scope, duration и planned cost для этих длинных задач прикидываем в Ёкселе.
no subject
Date: 2004-09-30 06:54 pm (UTC)no subject
Date: 2004-09-30 11:09 pm (UTC)Я неясно выразил свою мысль. План не нужен. Нужен список оценённых задач, возможно, в виде WBS, возможно, в виде бесформенной кучи. Когда я говорю о "картине с дискретностью в день", я имею в виду дискретность оценки, а не плана.
Ну вот, например, надо команде зафиксить сто багов и есть у неё на это три месяца с февраля по апрель. Ясно, что только наивный чукотский юноша будет в январе пытаться планировать, какой именно баг Вася Пупкин будет фиксить десятого апреля с утра. А вот оценить все баги с точностью до двух-восьми часов и прикинуть, влезаем ли мы с ними в три месяца – задача реальная и необходимая.
no subject
Date: 2004-09-30 05:27 am (UTC)no subject
Date: 2004-09-30 07:43 am (UTC)OK, давай зайдём с другой стороны. В пределах команды без внешних зависимостей и итераций длиной, скажем, один-два месяца, очевидно, идеально работает XP-шный planning game или более близкая мне его же вариация от Джоэля. Для проектов же, включающих более одной "подкоманды", коммуникация между которыми затруднена, а зависимости между результатами работы нетривиальны, Ганнт получается сам собой. Поэтому Когда Мы Придём К Власти MS Project будет переписан так, чтобы по-человечески поддерживать agile planning style на нижних уровнях. Но об этом я напишу отдельно.