Форум продуктивных

Natalia писал(а): Это фундаментальные проблемы планирования, чего угодно, а не только документации.

Все-же хочется определиться с документацией, пусть это и частный случай.

Наверное можно обобщить тему на любые задачи, которые являются обеспечивающими, а сами не стоят на критическом пути.
Например, тестирование.

Но вопрос документации имеет для меня практическое значение.
Обобщить можно и потом.

Alex Moskvichev писал(а):Хотелось бы определится с с любой документацией, которая нужна/не нужна для завершения проектов вовремя.
Или слишком глобально получится?

Ага, слишком глобально. И так тема-то довольно абстрактная...

Скажем рабочие инструкции - вроде нужны. Но если это документ в дофига страниц - то не нужны. Если это набор одностраничных чеклистов - то польза возрастает.

Тут вот еще какое дело... Документация - это типа идея. Как идея - это все нужно. Но помимо идеи будет еще и конкретная реализация, а вот тут и будет тыща юансов.

Alex Moskvichev писал(а):
Новый вариант "Завершить проекты в срок сейчас и в будущем".
В текущем проекте все может быть идеально, заказчик в команде, вся команда в одном месте, команда сработанная, в работе только один проект.
Документация не нужна, все в оперативной памяти.
Но потом будет другой проект, потом еще, а потом маленькая доработка в старый проект потребует усилий сопоставимых с началом проекта с нуля, потому что все забылось. Или другой команде надо будет проект отдавать, тоже проблемы.
Поэтому, "сейчас и в будущем"

У меня в конспекте по PMBoK в группе процессов "закрытие" есть пункт "сохранение шаблонов". Может ты об этом?

cartmendum писал(а):

Alex Moskvichev писал(а):Хотелось бы определится с с любой документацией, которая нужна/не нужна для завершения проектов вовремя.
Или слишком глобально получится?

Ага, слишком глобально. И так тема-то довольно абстрактная...

Скажем рабочие инструкции - вроде нужны. Но если это документ в дофига страниц - то не нужны. Если это набор одностраничных чеклистов - то польза возрастает.

Тут вот еще какое дело... Документация - это типа идея. Как идея - это все нужно. Но помимо идеи будет еще и конкретная реализация, а вот тут и будет тыща юансов.

Тогда предлагаю уменьшить ситуацию до цепочки аналитик-разработчик, или заказчик-аналитик-разработчик. А там как пойдет.

Максим, а есть альтернативный формат записи диаграммы, текстовый например? С диаграммой не очень удобно в компьютере работать, надо доску или ватман.

Alex Moskvichev писал(а):Тогда предлагаю уменьшить ситуацию до цепочки аналитик-разработчик, или заказчик-аналитик-разработчик. А там как пойдет.

Имеются в виду требования к системе? А так еще на вскидку, какая еще документация может быть?

Alex Moskvichev писал(а):Максим, а есть альтернативный формат записи диаграммы, текстовый например? С диаграммой не очень удобно в компьютере работать, надо доску или ватман.

XML
Вообще все дело в программе, думаю. Это какого рода диаграммы не удобно в компьютере делать?

Вообще то, кол-во и объем документации на проекте - зависит от сложности, важности, размера проекта. Вроде очевидно.

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

Суммируя - для каждого проекта определяется кастомный набор требуемой документации. За это отвечает ПМ, он в свою очередь руководствуется правилами компании.

Документы как идея - метко!
Обсуждать "документы" вообще, и их влияние на разработку можно бесконечно.

Чтобы немного "приземлить" идею, предлагаю выделить:
"ТЗ","конструкторскую документацию", "пользовательскую документацию", "технологическую документацию", "управленческую документацию".

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

В итоге, "в срок" не получилось, потому что пришлось переделывать архитектуру. И переписывать следом.

Отсюда вывожу: ТЗ и конструкторская документация - ни разу не вспомогательный процесс, а часть основного.
Я не увидел этого в "Цель" и "Цель2" - вероятно, потому, что для примеров все время выбирались "классические производства", где станки стоят на 1-2 порядка дороже з\п рабочего (если не брать глубокое заМКАДье, в ИТ все с точностью до наоборот), а от состояния ума рабочего перед станком характеристики результата зависят слабо (опять же, в отличие от ИТ, где джуниор, еще не отошедший от чтения "банды 4х" может простое действие копирования значения одного атрибута в другой сделать через все каноны - с фабриками, фасадами и прочей...гм). Соответственно, конструирование\проектирование в книгах как возможное ограничение не рассматривалось.

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

Про РМскую документаци - не копенгаген.

Получится.

Чтобы проект по разработке ПО не умер завтра, и чтобы другие проекты выполнялись в срок

Мой рецепт следующий:
1. Вся документация по проекту в вики (mediawiki4intranet + plantuml + graphviz)
2. документация которая вводит в курс дела: карточка проекта - суррогат устава проекта, определяет важное: цели, ресурсы (команда, ссылки на все инфосистемы поддержки), ограничения проекта.
3. Документация защиты от автобусного фактора по формуле: СНАЧАЛА ПИШЕТСЯ дизайн дока ПОТОМ делается задача на реализацию. Если происходит наоборот, то обучаю как делать правильно. Но все рано пишут обычно будущие архитекты, те кто не хочет - "увольняю", ибо нафиг мне сотрудник который не хочет учиться?

по п 3 дока обычно содержит:
1. Постановка проблемы. Какую проблему решаем?
2. Ограничения : чем мы ограничены в выборе вариантов?
3. Варианты решения , с обоснованием почему это хорошо и почему плохо. схемы делаются в plantuml

Также на этом этапе может быть создана сразу пользовательская документация ДО кодирования, потому что фактически это является требованиям к коду и тестам.

Таким образом имеем:
1. Когда начинаем думать о проблеме клиента , пишем в вики требования/истории
2. Когда смотрим на историю, думаем о том как это реализовать, и сразу пишем дизайн решение.
3. Когда начинаем кодировать, думаем о том как будет работать целевой класс и пишем модульные тесты.(TDD+BDD)
4. потом пишем МИНИМУМ кода чтобы тесты сработали.
5. передаем в QA (если есть)
6. QA уже обновил свои тест планы на основе wiki
7. выпускаем клиенту


О wiki - Created by Ward Cunningham, Launched 25 March 1995
то есть к моменту выхода XP в России, ISBN 5-94723-032-1; 2002 г. , wiki идея уже взлетела
Кент на неё ссылается в книжках.


И да, я это называю XP.