Функциональная спецификация и гибкие [закрытые] процессы

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

Вырастите свою документацию инкрементно и многократно, как Вы сделаете с кодом. Протестируйте немного, кодируйте немного и... документ немного.

Я вижу три способа сделать это: или включайте время, чтобы записать документацию по оценке задач, создать документацию определенные задачи или иметь неудовлетворенные объекты/истории документации.

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

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

Я поместил длительное размышление на предмет - мы работаем в среде Толпы, и мы закончили тем, что испытали затруднения для организации документации.

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

В основном рабочий процесс следующий:

1. Истории подходят в отставании
2. История забрана программистом
3. Программист делает код, и в DOD (Определение Сделанных), также должен записать некоторые тесты против новой функциональности и должен отредактировать Wiki для добавления страницы для новой функциональности.

Wiki организована с шаблонами mediawiki, в значительной степени вдохновленными mediawiki страницами документа расширений, с названием функциональности, версия, это было представлено в, что-либо, что может быть полезно. Шаблон добавляет pictos для различения различные виды функций (и их состояния).

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

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

Гибкий не означает "спецификаций". Это означает тест и выпускает рано и часто (но не обязательно к производству).

Отставание в Толпе является "спецификацией". Если Вы не будете на самом деле записывать и управлять списком функций, то Вы потеряете функции, и Вы никогда не будете мочь выяснить, когда продукт будет выпущен (не сможет оценить объем работы, оставленный, потому что Вы понятия не имеете, где Вы или сколько там оставлен сделать). Список функций MUST управляться кем-то. Самый легкий способ сделать, который должен записать все продукт, должен сделать (можно стать столь сложными в формулировке и определении, как Вы хотите), и отслеживайте то, что было завершено и что оставляют сделать. Как еще Вы поручите работу разработчикам и сообщите о состоянии "управлению?

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

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

Я не зарегистрировал бы все это заранее.

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

Кроме того, можно понять, что Вы не хотите реализовывать все требования после нескольких повторений.

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

К сожалению, Вы не собираетесь оставаться очень гибкими при принятии этого процесса. Клиент действительно хочет те же функции для переписанного приложения? Если да, то, почему это переписывает? Я уверен, что там функции, которые никогда не используются.

Я не потрудился бы документировать старую версию. У Вас уже есть ссылка, само приложение. В программном обеспечении нет никакой неоднозначности.

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