- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
[其它语言学习]中文User Stories Applied For Agile Software Development
来源:/space/?610884/
敏捷开发已经越来越受到人们的关注,User Story作为敏捷需求分析的一 种重要工具和方法,也越来越受到敏捷开发团队的重视,但是市面上关于User Story的资料目前较少,而且 多为英文资料,所以将我自己读的这本《User Stories Applied: For Agile Software Development》翻译如下。
?
User Story 在敏捷开发过程中的应用
By Mike?Cohn
Publisher:Addison Wesley
Pub Date: March 01,2004
ISBN: 0-321-20568-5
Pages:
Translator:Yan Su,Peng Zhou
?
User Stories 应用提供了一种节省时间、减少重复工作、并且能够做出更好的软件需求过程。
构造满足客户需求的软件的最好方法就是从简短的、清晰的、扼要的并且对最终用户有价值的User Stories开始。,在这本书中,Mike Cohn提供了一种如何编写User Stories以及如何在软件开发生命周期中运用它们的详尽蓝图。
你将会学习到,怎样编写一个好的User Story ,而怎样又会导致一个坏的User Story产生呢?你还将会学习 即使在你无法和客户交谈的情况下,仍能获取到User Stories 的实用方法。如果你已经编写完User Stories 了,Cohn 将会指导你怎样去组织他们,怎样来划分优先级,以及怎样运用他们来进行计 划、管理和测试。
?????? 用户角色模型:理解用户 的共同和不同之处
?????? 获取stories:用户访谈、调查问卷、观察和讨论会(译者注:此处作者使用了workshop,但是翻译成工作场所,此处不合适,难道他的本意是到客户工厂 去工作几天,这确实是个好方法)
?????? 同客户中的管理者、培训 人员、销售人员和其他代理商等一起工作
?????? 编写可测试的User Stories。
?????? 根据User Stories 来划分优先级,制定计划,估算成本
?????? 章尾问题和练习
User Stories 应用对于使用任何敏捷 开发方法的软件开发人员、测试人员、分析人员和管理者都是极其有价值的。
序
90年代中期,大多数时间我 都觉得很有罪过感。我所在的公司每年都会并购一家新公司。每次并购以后,我都被指派去运作那个公司的开发团队。每一个并购的开发团队都会带来一些很壮观的、漂亮的、很长的需求文档。我不可避免的会因为我的团队没有生产出如此漂亮的需求详细说明而感到罪过。然而,我的团队的软件开发一直都比他们成功的多。
我知道我们当时做的有了成效。然后我仍然觉得头疼的是,如果我们当时做了这些很详细的需求文档,我们应该会做得更成功。毕竟,我当时读的书和文章中都是这么写的。如果一个成功的软件开发团队写了这些壮观的需求文档,似乎我们也该那么做,但是,我们从来都没有这个时间。我们的项目通常都是非常重要和非常急迫的,以至于我们不能在开始的时候有任何延迟。
因为我们没有时间去写一个漂亮、很长的需求文档,我们采用和我们的客户讨论这种工作方式,而不是把他们写下来,自前而后互相传递,然后讨论,我们只交谈。我们在纸上画一些界面,有时候我们会做些原型,还经常编写一小段代码,并把我们编写的东西展示给目标用户。我们去经常找一些有代表性的客户,并把我们真正编写的东西给他们看,通常至少每月一次。通过和我们的客户呆在一起并给他们看我们每一小块的工作进程。我们找到了一种不需要写那些漂亮的需求文档也能成功的方法。
但是,我仍然有罪恶感,我们没有按照我们应该按照的那种方式去做。
1999年,Kent Beck发表了一本具有革命意义的小书“Extreme Programming Explained: Embrace Change”,一夜之间,我所有的罪恶感消失了,书中有一种说法,说开发人员和客户交谈而不是写、讨论然后再写是可以的。Kent阐述了很多东西也给我提供了更多的工作方法。但是,最重要的是,他证实了我自己学到的一些经验是有道理的。
前期的那个大的需求收集和文档很多情况下都会扼杀一个项目,最常见的就是当我们把需求文档本身当成一个目标的时候。 其实需求文档只有在他引导软件达到最终目标的时候才应该被写下来。
第二种需求文档会扼杀一个项目的情况就是不准确的书面描述语言。我想起来很多年前听过的一个关于小孩洗澡的故事,爸 爸倒好了洗澡水,帮助他的小孩儿洗澡,这个两三岁的孩子,刚把脚趾头放到水里,就迅速的收了回来,然后跟他的爸爸说“再暖和点(make it warmer)”。爸爸把手放到水 里,惊奇的发现,水不但不冷,而且已经比她女儿洗澡用的热多了。
?当他想了一会
您可能关注的文档
最近下载
- 建筑劳务大清包合同.docx VIP
- GB/T 28043-2019 利用实验室间比对进行能力验证的统计方法.pdf
- ISO9001-2026质量管理体系标准版中英文及变化点解析.docx VIP
- 2021年上半年教师资格证考试《保教知识与能力》(幼儿园)真题及部分答案.pdf
- 卢新国《小企业会计》课后练习题参考-答案.doc VIP
- 海神肌电图仪使用技术说明书.doc VIP
- 秀丽线虫的研究和饲养.ppt VIP
- 广东省深圳市(2024年-2025年小学六年级语文)统编版小升初真题((上,下)学期)试卷及答案.docx VIP
- 最新ISO22301:2019业务连续性管理体系管理评审一整套资料汇编(1).pdf VIP
- 2025上海市六年级升七年级暑假数学衔接讲义 第09讲 平方差公式(八大题型)(解析版).docx VIP
文档评论(0)