Уточняя новые функции - PullRequest
5 голосов
/ 09 марта 2010

Мне любопытно, как другие команды разработчиков описывают новые функции. У команды, которую я только что поднял, нет реального процесса спецификации. Я только что реализовал правильный процесс разработки с помощью CI, автоматического развертывания и регистрации всех ошибок, используя Trac, и теперь я перехожу к изменениям.

У меня есть список из примерно 20 изменений, внесенных в наш продукт в течение следующих 2 месяцев. Обычно я просто уточняю каждое изменение, вдаваясь в детали того, что должно быть сделано, но мне любопытно, как другие команды справляются с этим. Есть предложения?

Ответы [ 2 ]

1 голос
/ 10 марта 2010

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

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

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

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

1 голос
/ 09 марта 2010

Хороший вопрос, но он может быть субъективным. Я предполагаю, что это зависит от стратегии продукта, от того, будет ли он развернут на нескольких клиентах одинаковым образом или на одном клиенте в индивидуальном проекте, влияние, зависимость, которые эти изменения оказывают на систему и друг друга, и их приоритетность. изменения должны быть сделаны. Я бы посмотрел на приоритет и зависимость, которые естественно начнут группировать вещи?

...