Статья Дж. Спольского, которую я только что рекомендовал, называется "Безболезненное планирование разработки софта". Безболезненность эта происходит от того, что исполнение плана не требует ни сложных программ, ни драконовских мер по контролю. Но Джоел, все же, слегка слукавил. Попользовавшись этим методом какое-то время я обнаружил, что совсем уж безболезненным он не является. Хотя может быть я просто еще не достиг просветления в нужной мере, но все равно поделюсь теми трудностями, которые мне встретились.
Дизайн
Самая большая трудность заключается действительно не в исполнении плана, а в его составлении. То, что план должен быть детализирован до очень простых задачек по нескольку часов, подразумевает, что функциональность надо заранее полностью спроектировать. И вот сидеть и придумывать в голове, как оно "будет", гораздо сложнее, чем просто делать, что делается, и по ходу смотреть, что получается. Но! Эта трудность действительно необходима. Стоит потратить на это день, два, неделю, но это позволит заранее выяснить очень много дополнительных вопросов и заранее увидеть многие ложные пути. Это в итоге сильно экономит время, потому что продумать и отменить ложный путь хоть и сложнее, но существенно быстрее, чем сделать и переделать. И менее нервно.
Этот процесс требует тренировки. У меня стало получаться нормально планировать проекты к третьему или четвертому разу. Тут главное — не опускать руки, когда сразу не получается.
Разная предсказуемость
Трудность планирования также сильно зависит от специфики задачи. Задачу легко раскладывать на составляющие, если разработчики с этой задачей уже знакомы. Если же нет, то прогноз будет уже отнюдь не таким точным. Это само по себе нормально, потому что план в любом случае позволяет контроллировать неожиданные трудности. Но в общем и целом, чем стандартней задача, тем точнее она планируется.
Обратное, кстати, неверно. Если ваш план разваливается, то это не означает автоматически, что вы делаете что-то грандиозное :-).
Хуже всего в этом смысле поддаются планированию три вещи: исследования, творчество и отладка багов. Именно поэтому задачи такого рода надо стараться решить как можно раньше (исследования в самом начале, странные баги — сразу после обнаружения), потому что чем раньше вы от них избавитесь, тем быстрее план уточнится.
Долгосрочное планирование
Выполнение многих задач зависит от того, как именно выполнены предыдущие. Такие зависимости выстраиваются в цепочки и приводят к тому, что чем дальше простирается план (когда его надо уже называть План™), тем менее предсказуемым становится. Спланировать на многие годы вперед можно, видимо, только очень тривиальные задачи. Поэтому имеет смысл такие планы не строить вообще, а разбить всю большую задачу на достаточно крупные куски и планировать их отдельно. Они, кстати, естественным образом становятся мажорными номерами версий :-).
Комментарии: 6
Хотел заметить, что при работе в группе, данное планирование обходится безболезненней - мы как правило, садимся и начинаем "программировать" поведение системы на бумаге - причем сначала каждый набрасывает свой вариант, потом варианты аггрегируются группой во фронт работ, вбирая все оправдывающие себя реализации и нововведения, после чего разделить работу и распланировать ее по времени не составляет особого труда, ибо в процессе аггрегирования, а значит и построения системы, каждый принимает непосредственное участие.
Опять таки, это снижает эффект от разной предсказуемости, поскольку группой оценить возможные узкие места системы, разработанной всеми вместе, гораздо легче.
PS. Мне на плечи неожиданно упал груз управления своей группой, решил воспользоватся данной возможностью для реального планирования разработок. Начал приучать начальство к данной идее. :-)
На удивление, ссылка начальству на вашу предыдущую статью очень помогла, начальство решило посмотреть на эффективность планирования задач непосредственно исполнителями.
В общем, спасибо вам огромное, количество полезной информации, черпаемой из ваших статей просто невероятное. =)
Это называется "СЮРПРИЗ!!!"
;-)
Кстати - при попытках планирования в области софтостроения критически важно вычленить из общей рыхлой массы вещи фундаментальные и наиболее рисковые аспекты/ограничения. Если там возникают сомнения - то еще до начала планирования как такового необходимо создание модельного прототипа/test suite для выяснения ПРИНЦИПИАЛЬНОЙ возможности реализации проекта вообще.
Не раз был свидетелем, как бодро ваялись огромные объемы в рассчете на запроектированную функциональность одного из модулей. Когда же доходила очередь до него - оказывалось, что в принципе нереализуемо. И - опс! с кучей потерянного времени и горами кода, которого не к чему прикручивать.
О, да! Бывает такое :-). Я сейчас готовлю статью как раз о похожем случае. Там, правда, чисто принципиально все было хорошо, но когда в систему пришли пользователи (человека четыре), оказалось, что подход не работает. Из серии "поди спланируй" :-).
Опять же, повторюсь, наличие такой вероятности не повод не планировать вообще, потому что оно все равно помогает в большинстве случаев.
А это называется - "управление рисками". Без которого нормального планирования в принципе не бывает.
Прошу высказать свое мнение всех участников.
Применяются ли у вас поощрения и взыскания по результатам выполнения плана?
Если да, то как именно, и кратко о плюсах и минусах.