Декларативное планирование revisited: темпоральная логика
Ну вот, после нескольких лет практики применения, удалось наконец более-менее подробно изучить свойства "декларативного планирования", и довести его до логически завершенной, самостоятельной концепции. Ахтунг, уважаемые коллеги, это оказывается вовсе не упрощенный вариант всем известного сетевого планирование. Это в самом деле новый единый подход к ( Read more... )
Рабочую группу собираешь, где представлено по 1 человеку из каждой области, в которой требуется компетенция. Наиболее занятые люди должны учавствовать по схеме инспекций документов. Скажем, следуя процессу инспекций Фагана http://en.wikipedia.org/wiki/Fagan_inspection
> Насколько валиден будет план (разработанный с использованием любой техники), если он построен на базе результатов предварительного проектирования с декомпозицией на один уровень?
Вопрос, что от тебя на самом деле требуется на самом раннем этапе. В реальности - это состав и даты закрытия крупных этапов, и грубая оценка трудозатрат (чтобы не залезть в минус)) для оценки стоимости всего проекта (раскидать по этапам ее потом небольшая проблема).
Для этого подробного плана с детальным проектированием не требуется. Достаточно декомпозиции на 1 уровень вниз. Эта декомпозиция, в свою очередь, будет более-менее корректной в случае, если выполнена декомпозиция на два уровня вниз.
Если впоследствии будет выбран другой подход к реализации, то ничего страшного - вряд ли он будет отличаться в худшую сторону от подхода, выработанного быстро.
Оценку трудозатрат можно делать при помощи моего метода, который я докладывал на Oracle ISV 2008. Поучается достаточно точно, и быстро.
>К тому же, для того, чтобы плану быть более или менее точным с точки зрения сроков, нужно заранее иметь максимально подробную декомпозицию,
Максимально подробной - не надо. На раннем этапе надо определится с порядком цены и сроков, оставив возможность играть функциональностью на дальнейших этапах. По итогам первого этапа надо уточнить план с учетом имеющихся ограничений, выполнив качественное предварительное проектирование.
Как-то так. По другому все равно нельзя :). Разве что подписать заказчика на повременку в том или ином виде (time & materals), чего заказчик не любит при большом бюджете - ему тоже расходы планировать надо.
Reply
Reply
"Экспертиза проектной документации", "эксперты". Так правильно, по русски, и интуитивно понятно о чем речь.
Reply
Но это уже мало соотносится с исходной темой твоего поста.
Reply
Reply
http://gaperton.livejournal.com/30970.html
Reply
Я уверен, что именно т.н. "проблемные группы" ключ к успеху в аппаратно-программных проектах. По крайней мере у нас данная схема рулит. Все проблемы ушли, после того, как стали программистов включать в проблемные группы начиная с раннего этапа.
Reply
При возникновении очередного "события" в плане некоторого проекта поток очередных заданий по проекту поступает в каждое подразделение, затрагиваемое событием. Которое, в это время естественно может быть занято чем-то другим. Еще хуже, если событие возникает извне (например, у какого-нибудь заказчика что-то где-то "чихнуло"), -- тогда для начала выбирается "крайний", его текущие работы немедленно задвигаются в сад, и он начинает героически решать проблему.
Меня в последнее время не оставляет мысль, что так работают почти все отечественные R&D-компании. Ибо приходящие к нам новые люди считают происходящее вполне нормальным (по-крайней мере, не высказывают недоумения происходящим).
Reply
Функциональное подразбиение, пусть временное, на срок жизни проекта, дает настолько большой эффект по нашему опыту, что всеми остальными мерами по организации можно пренебречь, и все равно будет лучше. Я думаю, это 90% эффекта.
Reply
В том-то и беда, что на классическом fixed price (точнее, fixed-all) проекте возможности играть функциональностью обычно нет, так как зафиксированы все три параметра "проектного треугольника" И такие проекты - увы, реальность и в 2012 году, сколько бы не писали об их недостатках.
Reply
Leave a comment