如何在Scrum环境中维护设计规范？ [英] How to maintain a design specification in a Scrum environment?
问题描述
我非常喜欢敏捷宣言中的重点应该放在工作软件上，而不是全面的文档上。另一方面，我的工作的一部分也是管理产品，因此我需要任何时候最新的版本设计文档。有些人可能会说当前版本的工作软件是我需要的所有文档，但是我需要这些文档来证明该产品是按照客户规格进行工作的，即使在原始设计进行了10次更改之后。
在以前的工作中，每个批准的更改都集成在系统中每个主要功能的设计文档中。此过程为每次更改增加了相当大的间接费用，因为至少需要更新，批准和签署一个和两个可能的双字文档。
至少这个程序在瀑布项目中工作，但现在我正在寻找一种更灵活的方式来记录当前的商定状态的解决方案，所以我真的很期待听到你如何处理这个问题，谢谢。
编辑：我的问题是如何跟踪系统的外观或行为方式。所以我有一个现有的生产系统，并且客户记录当输入X时系统应该做Y的问题。然后，我需要找出这个功能的当前规范，这些功能可能会在各种用户故事中被多次更改。
设计文档是必不可少的，但是在项目开始时创建的系统的所有方面的完整描述类型文档不是一个好主意。 / p>
您将不得不从刻画石雕的系统的各个方面摆脱设计的想法。您将从设计开始，然后开始将其分解为用户故事，这些故事是您将立即针对第一次冲刺的零件的小型集中任务。
稍后实施的设计方面不一定要详细，在初步阶段实际上可能包含许多用户故事集中在一起成为用户主题。更进一步的是，您可能将用户主题集合在一起分为用户史诗。随着团队进步到以后的冲刺，用户主题被分解为个人用户故事，用户史诗可能会开始分解为用户主题。
每个冲刺可能被认为是一个迷你瀑布项目，所以在冲刺初期将会有一个需求收集和设计阶段。这是设计文档在设计的新部分逐步更新的地方。
这个概念涵盖在Mike Cohn的使用Scrum进行敏捷演示。我还推荐他的书籍应用使用者故事和敏捷估算与规划。如果您有很多新的Scrum，我建议让Mike进入他的课程。
阅读Martin Fowler的优秀作文一个href =http://martinfowler.com/distributedComputing/thud.html =nofollow noreferrer>全能之路关于创建不必要的文档。
I really like the concept in the agile manifesto that the focus should be on working software rather then on comprehensive documentation. On the other hand a part of my job is also to manage the product and as such I need a up to date version design document at all times. Some might say that the current version of the working software IS all the documentation that I need, but I need the documentation to prove that the product works as per the customers specifications, even after 10 changes to the original design.
In a previous job each and every approved change was integrated in a design document per major feature in the system. This procedure added a significant overhead to each change, since at least one and posible two word docs had to be updated, approved and signed.
At least this procedure worked in a waterfall project but now I am looking for a more agile way to document the current agreed state of the solution so I am really looking forward to hear how you handle this issue, thanks.
Edited: My issue here is how to track how come the system looks or behaves the way it does. So I have an existing system in production and the customers logs an issue that the system should do Y when X is entered. Then I'll need to figure out the current specification for that piece of functionality which might have been changed a number of times in various user stories, sigh.
A design document is essential, but a "complete description of all aspects of a system" type document, created at the beginning of a project, is not a good idea.
You will have to get away from ideas of a design for all aspects of a system that is carved in stone. You do start out with a design and then start breaking that down into user stories which are small concentrated tasks for the parts you will be working on immediately for the first sprint.
Aspects of the design that are being implemented later don't have to be as detailed and in the intial phases may actually consist of many user stories clumped together into a user theme. Even further out, you may have clumps of user themes grouped together into user epics. As the team progresses to later sprints, the user themes are broken down into individual user stories and the user epics may start to be broken down into user themes.
Each sprint may be considered a mini-waterfall project on its own so there will be a requirements gathering and design phase at the beginning of the sprint. This is where the design document is incrementally updated with th e new portions of the design.
This concept is covered in Mike Cohn's "Getting Agile with Scrum" presentation. I'd also recommend his books "User Stories Applied" and "Agile Estimating and Planning". If there are many of you new to Scrum I'd suggest getting Mike in to teach one of his courses to you.
Have a read of Martin Fowler's excellent essay "The Almighty Thud" about creating unnecessary documentation.
这篇关于如何在Scrum环境中维护设计规范？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
