《第9章敏捷过程教学提纲》由会员分享，可在线阅读，更多相关《第9章敏捷过程教学提纲（33页珍藏版）》请在金锄头文库上搜索。
1、软件开发与实践,第9章 敏捷过程 （Agile Process）,什么是过程？,过程定义了谁负责什么工作？何时以及怎样达到某一确定的目标？ 软件工程中的目标就是开发和维护软件及相关产品,过程铁三角,过程：把各部分集成在一起 CMM,概述,2001年敏捷联盟在美国成立； 2001年敏捷宣言发表；,概述,敏捷过程分为三个部分： 敏捷项目管理 敏捷需求分析 敏捷软件开发,敏捷过程中的需求分析,商务分析师与客户交流，搞清楚客户到底需要什么，到底为什么需要这些东西。 商业价值是商务分析师关注的最终目标。有了目标的指向，就可以不迷失方向。 和客户进行交流，最终目的就是挖掘出客户的商业目标。商务分析师需要详
2、细的问客户为什么，挖掘出他真正的目标。,敏捷过程中的需求分析,商务分析师要作出判断： 我们到底是否真的需要这个需求? 有没有更好的解决方案? 有没有简单并且低廉的方式? 换一种形式是不是也能达到这样的需求? 这个需求有多少地方涉及到以前的软件变更?,敏捷过程中的需求分析,商务分析师通过撰写用户故事来描述需求。 在书写的时候格式比较随意，可以在故事卡背面写上注释或疑问，甚至画上界面原型图。,敏捷过程中的需求分析,用户故事的作用有两个： 一个是作为进度跟踪的依据； 一个是作为与人交谈的备忘录。,敏捷过程中的需求分析,用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推
3、迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。,敏捷过程中的需求分析,用户故事和用例的区别： 用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用。 用户故事是可见的商业价值，而不是功能描述。每个用户故事的粒度和工作量都相差不多，这和用例有很大的区别。 用户故事是小粒度的，可测试的，可见的，并且是有价值的。,敏捷过程中的需求分析,敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前，由一组有经验的开发人员大致评估一下用户故事，标记出不同的难度和风
4、险，并提出问题供商务分析师来获得更详细的信息，商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选，客户可以选择这些用户故事，或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。,敏捷过程中的需求分析,客户看到每个迭代交付的可运行的软件后或者得到用户反馈后，常常会有新的想法冒出来。有些想法是好的，有些想法就属于看到别家网站有这个功能，不假思索的提出的功能。这些不同的需求都需要经过认真的分析，找出哪些是值得我们立即考虑的，哪些是不用急迫的去实现的。,敏捷过程中的需求分析,用户故事的跟踪和管理是由项目经理来进行。每次迭代都跟踪卡片的进展，确认
5、： 是否已经开始实现? 是否已经完成代码开发? 是否已经开始功能测试? 不同的卡片在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几次迭代后，团队的开发速度基本保持恒定，我们就可以很容易的知道每次迭代能做多少个用户故事，这样就可以安排下一次迭代的开发。,敏捷过程中的需求分析,每次迭代内分析得出恰好足够下一次迭代开发的需求，就是商务分析师每次迭代的主要工作内容。 商务分析师的需求分析工作在上一次迭代完成，包括需求的了解，分析，评估和排列优先级。,敏捷过程中的需求分析,在每次迭代开始的时候，由商务分析师主持召开迭代计划会议，在会议上向所有的程序员解释这次迭代要完成的用户故事，然后由程
6、序员自由提问，直到他们能够获得足够开始实现该功能的信息。,敏捷过程中的需求分析,在程序员完成一个用户故事后，商务分析师还要来代表客户做功能验收测试，查看是否完成了预计的功能，是否有程序员还没有想到的异常情况。 如果存在问题需要退回给程序员继续完成。 这在一定程度上保证了系统完成的需求不偏离客户的要求。当然，更多的测试还需要质量保证（QA）来完成。,敏捷过程中的需求分析,敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。 商务分析师在这个过程中，起到了纽带和桥梁的作用，是一个团队不可缺少的角色。,XP是什么？,敏捷方法的代表。 Kent Beck在他
7、的开篇之作Extreme Programming Explained Embrace Change中提出97年 一种高度动态的过程，它通过非常短的迭代周期来应对软件开发中的变化 强调有效测试和演化设计fowler,XP的目标,在规定的时间生产出满足客户需要的软件,什么时候需要XP？,需求不明确、变化快 高风险：在特定的时间内，面对一个相当难开发的系统 中小型团队（人数不超过10 个）,XP的系统隐喻,XP体现四个价值目标,沟通（communication） 简化（simlicity） 反馈（feedback） 勇气（courage）,XP的12个核心实践,规划策略(Planning game)
8、 系统隐喻(System Metaphor) 简单设计(Simple design) 配对编程(pair programming) 编码标准(Coding standards) 测试驱动(Test-driven) 重构（Refactoring） 持续集成(Continuous integration) 小发行版(Small releases) 现场客户(On-site customer) 集体代码所有权(Collective ownership) 一周40小时 (40-hour week),实践之间的互相支持,XP项目的状态图,XP的计划/反馈循环,从CMM角度看XP,XP部分满足或大部分满足
9、了CMM 2-3 级KPA 的要求，而基本上没有涉及CMM 4-5 级的KPA XP 侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题 XP 缺少的一个重要内容是“institutionalization” -Mark Paulk, SEI,XP vs. RUP,对XP的置疑,技术前提：对变化成本曲线的置疑 技艺前提：对于有经验的人是简单的代码，对没有经验的人是复杂的 社会结构前提 ：程序员可以能否对自己的开发过程承担责任,不适用于XP的场合,不能接受XP 文化的组织 中大型（超过10 个人）的团队 重构会导致大量开销的应用 需要很长的编译或测试周期的系统 不太容易测试的应用 人员异地分布的物理环境 Beck,怎样开始XP？,
