Декларативное планирование revisited: темпоральная логика

[gaperton]

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

Comments

[thrust_breaker]

Положим, с некоторой натяжкой, что множество фич известно на берегу. Однако не очень понятно, откуда перед началом планирования возьмется множество компонентов. Или первой целью в плане будет то самое "множество компонентов" плюс уточненное множество фич?

[thesz]

Компонента - это тоже "фича".

[thrust_breaker]

Автор сказал так:
Множество это состоит из функций (фич), и компонентов (классов/модулей/итд). Мы воспользуемся CRC-картами, которые связывают модули и фичи.
Где брать фичи перед планированием -- понятно (почти, потому что фича, как минимум, является результатом анализа внешних требований). Вопрос о компонентах в силе.

[gaperton]

Предварительное проектирование выполнить. Хороший план нельзя сделать, не зная, как будет устроено то, что надо сделать, и затраты оценить невозможно. До крупных подсистем хотя бы (на один уровень декомпозиции вниз, максимум на два). Детально ничего расписывать не надо - crc-карты это по сути структурированный фичлист, промежуточное представление между требованиями и "дизайном". Интерфесы, скажем, crc-карты не определяют.

[thrust_breaker]

Да, нужно выполнить предварительное проектирование. И это, по моему опыту, является одной из главных проблем планирования программных и аппаратно-программных проектов. Ведь проект еще не запущен, команда и другие пре-реквизиты не собраны, а нужно выполнить анализ требований и ограничений, предметной области в целом, и конкретного объекта применения в частности, поискать/посмотреть прототипы и прочая, почерепить над вариантами (желательно не в одиночку, чтобы не напороть чепухи), оформить результаты, в конце концов.
Скажем, 15 лет назад небольшая фирма, в которой я работал, почти год существовала в основном за счет поступлений за т.н. "нулевой этап" проектных работ, который назывался "Предпроектное обследование", целью которого было получение технико-коммерческого предложения с предварительными планом проекта и технико-экономическим расчетом

[gaperton]

> Ведь проект еще не запущен, команда и другие пре-реквизиты не собраны, а нужно выполнить анализ требований и ограничений

[gaperton]

Гхм, следуя облегченному процессу инспекций Фагана, сохраняющему принцип и дух. Посмотрел - уж больно он формален в оригинале.

[gaperton]

Слово "инспекции" лучше перевести на русский как "экспертиза", вероятно.

"Экспертиза проектной документации", "эксперты". Так правильно, по русски, и интуитивно понятно о чем речь.

[thrust_breaker]

Ну да, в смешанных (аппаратно-программных) проектах примерно так все и происходит, с небольшими вариациями. И почти всегда не срабатывает, если только проект не прост, как валенок (хотя и там случаются приколы, потому как сложности кроются в психологии и прочих малотехнических деталях). Видимо, у нас пчелы совсем неправильные и не та трава.
Но это уже мало соотносится с исходной темой твоего поста.

[gaperton]

Ну дьявол-то в деталях, чего тут удивляться.

[gaperton]

Вот чутка философии, на тему почему так.
http://gaperton.livejournal.com/30970.html

[gaperton]

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

Я уверен, что именно т.н. "проблемные группы" ключ к успеху в аппаратно-программных проектах. По крайней мере у нас данная схема рулит. Все проблемы ушли, после того, как стали программистов включать в проблемные группы начиная с раннего этапа.

[thrust_breaker]

Конечно, так должно быть. Но на практике над проектом у нас работают аппаратчики, конструктора, программисты, тестеры, тех.писы из разных подразделений практически автономно. Прежде всего потому, что проектов много, а штыков в каждом подразделении мало, и выкручиваться предлагается за счет того, что разные проекты в некоторый момент времени находятся в разных фазах.
При возникновении очередного "события" в плане некоторого проекта поток очередных заданий по проекту поступает в каждое подразделение, затрагиваемое событием. Которое, в это время естественно может быть занято чем-то другим. Еще хуже, если событие возникает извне (например, у какого-нибудь заказчика что-то где-то "чихнуло"), -- тогда для начала выбирается "крайний", его текущие работы немедленно задвигаются в сад, и он начинает героически решать проблему.
Меня в последнее время не оставляет мысль, что так работают почти все отечественные R&D-компании. Ибо приходящие к нам новые люди считают происходящее вполне нормальным (по-крайней мере, не высказывают недоумения

[gaperton]

С этим надо что-то делать. Уверен, проблема в этом.

Функциональное подразбиение, пусть временное, на срок жизни проекта, дает настолько большой эффект по нашему опыту, что всеми остальными мерами по организации можно пренебречь, и все равно будет лучше. Я думаю, это 90% эффекта.

[dmitriyl]

Максимально подробной - не надо. На раннем этапе надо определится с порядком цены и сроков, оставив возможность играть функциональностью на дальнейших этапах.

В том-то и беда, что на классическом fixed price (точнее, fixed-all) проекте возможности играть функциональностью обычно нет, так как зафиксированы все три параметра "проектного треугольника" И такие проекты - увы, реальность и в 2012 году, сколько бы не писали об их недостатках.

[gaperton]

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