Управление разработкой ПО.

[metaclass]

Сижу, пытаюсь вникнуть, как ведется управление проектами по разработке ПО в нормальных условиях, читаю про всякие SRS да SDD(там еще штук десять аббревиатур, кто во что горазд).
Интересное обсуждение здесь опять пришло к старой теме - "пока мы будем полгода заниматься планированием, клиентам наш продукт станет не нужен".
Похоже, что для простых проектов и планирование с документацией надо вести как-то упрощенно, чтобы не похоронить проект в бюрократии еще до начала разработки.

Comments

[pascendi.livejournal.com]

Полноценное документрирование планирования и исполнения проекта необходимо, только если:
- в проекте занято более 10-15 человек (у исполнителя) или требуется координация нескольких подразделений с выраженно разными интересами;
- перечень работ проекта не умещается на трех листах А4 12 кеглем. :-)

[vp.livejournal.com]

А как понять степень необходимой полноценности?
А возможная смерть главного девелопера это сильный повод? :)

[pascendi.livejournal.com]

Здравый смысл поможет :-)

ИМХО, документирование проекта не должно занимать более 2-3% трудозатрат на сам проект.

[beskov.livejournal.com]

В каком смысле "нормальных условвиях"? Цели какие?

[metaclass.livejournal.com]

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

[henu3detb.livejournal.com]

Мда, а чего такая экономия?

[metaclass.livejournal.com]

Потому что промежуток между "ведем проекты от фонаря, как бог на душу положит силами одного-двух человек" до "ведем проекты силами вменяемых проект-менеджера и аналитика и десяти кодеров и инженеров по поддержке среднего уровня" сложно перескочить. Сложно отказаться от привычки "сделать все и сразу и вчера" у клиентов, работников и начальства.

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

Поэтому сижу и думаю, как бы это проекты документировать, чтобы работники новые вникнуть могли.

[pascendi.livejournal.com]

ИМХО, в проекте должно быть документировано:
- решения по архитектуре системы;
- прецеденты;
- информационные потоки;
- схемы данных;
- организация и взаимодействие модулей.

Остальное -- опционально.

[beskov.livejournal.com]

В таких условиях имхо надо обратить внимание на Agile, а не читать Брауде.

[metaclass.livejournal.com]

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

[beskov.livejournal.com]

Что именно документировать, вам должно быть понятно из опыта работы.
Как документировать - в принципе тоже, накидали структуру, выбрали способ описания - текст, таблицы, диаграммы.
С помощью чего - ну тут вряд ли есть что-то лучше вики.

Одни из самых простых шаблонов - в MSF.

[vp.livejournal.com]

Квалификация нанимаемых людей откровенно пугает. Есть шанс, что как ни документирую - все равно не поймут 99% ни в технологиях, ни в предметной области :(

[pascendi.livejournal.com]

А надо ли таких людей? :-)

[vp.livejournal.com]

Это объективная реальность с учетом качества сегодняшних кадров. Я некоторое время сидел на отборе HR, потому представление имею.

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

[metaclass.livejournal.com]

Безальтернативно. Других просто нет, а проекты растут и скоро выйдут за пределы физических возможностей теперешних работников.

[pascendi.livejournal.com]

Тогда, к сожалению, выход один: переходить на формализованные методологии, при которых происходит декомпозиция проекта до уровня спецификаций функций, по которым даже тупой кодер может быстро сделать требуемое.
Ну, или использовать что-то вроде IBM Rational Rose, если специфика разрабатываемой системы позволяет (для портальных решений эта штука, к сожалению, подходит не очень).

[pascendi.livejournal.com]

Про МСФ -- согласен на все сто.