在以前的工作中,每个批准的更改都集成在系统中每个主要功能的设计文档中.此过程为每次更改增加了一个重要的间接费用,因为至少需要更新,批准和签署一个和可能的双字文档.
至少这个程序在瀑布项目中工作,但是现在我正在寻找一种更敏捷的方法来记录目前商定的解决方案状态,所以我非常期待听到你如何处理这个问题,谢谢.
编辑：我的问题是如何跟踪系统的外观或行为方式.所以我有一个现有的生产系统,并且客户记录当输入X时系统应该执行Y的问题.然后,我需要弄清楚在不同用户故事中可能已经改变了很多次功能的当前规范,叹息.
你将不得不摆脱一个设计雕刻在雕刻系统的各个方面的想法.您将从设计开始,然后开始将其分解为用户故事,这些故事是您将立即针对第一个冲刺的零件的小型集中任务.
稍后实施的设计方面不一定要详细说明,而在初级阶段,实际上可能会将许多用户故事组合成一个用户主题.更进一步的是,您可能将用户主题的群组分组在一起成为用户史诗.随着团队进步到以后的冲刺,用户主题被分解为个人用户故事,用户史诗可能开始分解为用户主题.
每个冲刺可以自己被认为是一个迷你瀑布项目,所以在冲刺开始时将会有一个需求收集和设计阶段.这是设计文档在设计的新部分逐步更新的地方.
这个概念在Mike Cohn的“Getting Agile with Scrum”演示文稿中有所介绍.我也推荐他的书“User Stories Applied”和“Agile Estimating and Planning”.如果你有很多新的Scrum我建议让迈克去教他的一门课程给你.
阅读Martin Fowler关于创建不必要的文档的优秀作文“The Almighty Thud”.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。