Agile процесс: как и что нужно документировать?

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

Они ушли по завершении проекта со всеми, кроме одного из команды проекта. Вики-сайт проекта был закрыт после годовой подписки.

Когда они уходили, они брали большую часть знаний и понимания того, что было разработано с ними.

Итак, у меня есть 2 основных вопроса;

1. Это нормально для гибкой или просто повод для нежелания писать?
2. Каковы отраслевые нормы для документации в гибких проектах для записи требований к разработке, проектов, ключевых решений и контекста?

Это нормально для гибкой или просто повод для нежелания писать?

Моя теория такова, что именно поэтому agile распространяется так быстро, особенно scrum . Я видел слишком много команды, желающей быть гибкой, чтобы защитить себя (вместо всей компании). Проблема в том, что во многих случаях руководство использует против них методологию (потому что они тоже хотят защитить себя!).

Означает ли это, что Agile вообще не работает? Конечно, нет, это просто означает, что Agile помогает вам решить несколько общих проблем, но вы по-прежнему отвечаете за все остальные. И во многих случаях Agile просто не подходит для этой команды в этой компании.

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

Быть коротким:

Команда должна определить, сколько документации им нужно

Они знают область, они - эксперты, и что более важно, они строят вещь!

Вот что означает « Рабочая программа» над исчерпывающей документацией в Agile Manifesto .

Они оставили вам набор тестов TDD, приемочных тестов или других юнит-тестов? Они хорошо документируют, как приложение работает и, как ожидается, будет работать, а также предоставляют пример реализации того, как использовать то, что было разработано.

Хотя я ни в коем случае не являюсь экспертом Agile, вот моя попытка ответа:

1. Была ли история / требование с конкретной документацией? Если нет, то это является частью проблемы, поскольку вы получаете то, что запрашивается в некоторой степени. Это оправдание, и я мог бы задаться вопросом, что вы подразумеваете под «нормальным» здесь. Это просто большинство из тех, которые следуют Agile-принципам, которые делают что-то нормальное, или это часть общего процесса, который следует ожидать? Это две точки зрения, которые я мог видеть. РЕДАКТИРОВАТЬ: Я сомневаюсь, что большинство команд делают то же самое, когда дело доходит до документации, но это предположение с моей стороны.

2. Пара ссылок, которые могут быть интересны, - это лучшее, что я мог бы сделать в этом:

   • Лучшие практики для гибкой / бережливой документации
   • Гибкая и техническая документация

У Agile есть некоторые специфические моменты в манифесте , где я бы указал на это вместе с примечанием:

Рабочее программное обеспечение над полной документацией

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

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

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

Ваша проблема не имеет ничего общего с Agile. Они должны были предоставить документацию, которую вы просили. Проект был плохо управляем.

Как минимум, где-то должно быть некоторое описание функций, пользовательских историй и тестовых случаев . Это может быть в файлах ReadMe в проектах, это может быть в комментариях к исходному коду, это может быть в проектной документации; это может быть все вышеперечисленное ... или это может быть МВД!

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

Для реальной точности и достоверной информации все сводится к возможности читать код и тестировать. Клиент, желающий (заново) выяснить, что делает его система, всегда может опросить и спросить программиста, который затем может представить (с некоторым исследованием) факты о системе.

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