Можно ли создавать документы планирования задним числом, чтобы они соответствовали созданному продукту?

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

У меня вопрос, это разрешено и целесообразно?

Правильно ли я понимаю, что вы спрашиваете, можно ли разрабатывать документацию и код по мере того, как вы работаете с ним и лучше его понимаете, вместо того, чтобы пытаться документировать все заранее?
@MarvMills Для протокола, это управление проектами! Я отстаю от графика в проекте, и потенциальным способом было сначала реализовать приложение, а затем вернуться к этапу проектирования, но это нормально, я знаю, что делаю. Я не знаю, почему я вообще написал здесь, когда меня вот так встретят.
Не принимайте на свой счет, я просто констатирую факты. Если вы работаете над проектом, то вам нужно спросить об этом вашего менеджера проекта, Интернет не может ответить на этот вопрос за вас, только ваш менеджер проекта может. Что также делает ответ конкретным для вашей конкретной организации и ситуации, поэтому ответ будет бесполезен для других посетителей. Извини,
Добро пожаловать в PMSE, Джордж! Я думаю, что этот вопрос определенно можно спасти с помощью разумного редактирования. В заголовке речь идет о разработке, но есть основной вопрос о возникающих спецификациях, которые потенциально могут быть здесь по теме. Я думаю, что здесь есть жемчужина вопроса, можно ли его переписать так, чтобы он больше касался планирования проекта или последовательности этапов проектирования , а не методов разработки.
Я сильно отредактировал ваш вопрос, чтобы сделать его больше вопросом управления проектами и методологии. Не стесняйтесь продолжать редактирование, если вы чувствуете, что я неправильно истолковал суть того, что вы действительно пытаетесь спросить.

Ответы (2)

Шипы и прототипы в порядке; Пересмотр планов проекта не

Я планировал перейти к этапу реализации, а затем перепроектировать свою работу.

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

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

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

Спасибо за изменение исходного вопроса, а также за ответ на него для меня. Это для проекта последнего года, и поэтому я являюсь его менеджером. Я делаю это самостоятельно, и мне посоветовали как можно быстрее перейти к этапу реализации. Я нашел этапы планирования удручающими и очень расплывчатыми. Я просто почувствовал, что впоследствии было намного проще смоделировать диаграмму классов и диаграмму последовательности.
+1 Как всегда у тебя ладится со словами CG. «Готовься, огонь, целься!» будет повторно использован здесь (не как методология, спешу добавить! :)

Еще одна хорошая аналогия со стрельбой: стреляй, перемещай цель над пулевым отверстием, прямо в яблочко!

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

Если что-то неоднозначно, уточняйте. Потратьте время на детализацию и документирование перед созданием. В конце концов, это принесет дивиденды.

Можно ли создавать документы планирования задним числом, чтобы они соответствовали созданному продукту?
СпросиСетьПолитика конфиденциальности1y, 0v