我非常喜欢
agile manifesto的概念,重点应该放在工作软件上,而不是全面的文档.另一方面,我的一部分工作也是管理产品,所以我一直需要最新的版本设计文件.有些人可能会说当前版本的工作软件是我需要的所有文档,但是我需要文档来证明该产品是按照客户规格工作的,即使在原始设计进行了10次更改之后.
在以前的工作中,每个批准的更改都集成在系统中每个主要功能的设计文档中.此过程为每次更改增加了一个重要的间接费用,因为至少需要更新,批准和签署一个和可能的双字文档.
至少这个程序在瀑布项目中工作,但是现在我正在寻找一种更敏捷的方法来记录目前商定的解决方案状态,所以我非常期待听到你如何处理这个问题,谢谢.
编辑：我的问题是如何跟踪系统的外观或行为方式.所以我有一个现有的生产系统,并且客户记录当输入X时系统应该执行Y的问题.然后,我需要弄清楚在不同用户故事中可能已经改变了很多次功能的当前规范,叹息.
设计文档至关重要,但是在项目开始时创建的“对系统的所有方面的完整描述”类型文档不是一个好主意.
原文链接：https://www.f2er.com/javaschema/281380.html你将不得不摆脱一个设计雕刻在雕刻系统的各个方面的想法.您将从设计开始,然后开始将其分解为用户故事,这些故事是您将立即针对第一个冲刺的零件的小型集中任务.
稍后实施的设计方面不一定要详细说明,而在初级阶段,实际上可能会将许多用户故事组合成一个用户主题.更进一步的是,您可能将用户主题的群组分组在一起成为用户史诗.随着团队进步到以后的冲刺,用户主题被分解为个人用户故事,用户史诗可能开始分解为用户主题.
每个冲刺可以自己被认为是一个迷你瀑布项目,所以在冲刺开始时将会有一个需求收集和设计阶段.这是设计文档在设计的新部分逐步更新的地方.
这个概念在Mike Cohn的“Getting Agile with Scrum”演示文稿中有所介绍.我也推荐他的书“User Stories Applied”和“Agile Estimating and Planning”.如果你有很多新的Scrum我建议让迈克去教他的一门课程给你.
阅读Martin Fowler关于创建不必要的文档的优秀作文“The Almighty Thud”.
