我的Thoughworks-Scrum经历点滴
Posted 敏捷开发WeAP
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我的Thoughworks-Scrum经历点滴相关的知识，希望对你有一定的参考价值。
背景：
2011年，平安陆金所p2p借贷平台，平安300万3个月，请Thoughworks敏捷团队来设计、开发。笔者有幸全程参与，亲身体验结对编程、测试驱动开发过程。（大约10人, 普通程序员顾问费一个月12万）
日记：
【日记】Day 2011/07/12
一周安排:
7-11 对上周进展进行总结，并和高层领导沟通
7-12 敏捷方法介绍
7-13 TDD介绍以及练习
7-14 用户需求讨论+规模估计
7-15 用户需求讨论+迭代计划
一、7/12敏捷方法介绍
什么是敏捷方法？答：迭代、TDD、重构
敏捷和快速软件开发没有任何关系，敏捷可以会很敏，但是并不一定会很捷
如果说敏捷是个方法论，那瀑布也是个方法论、rup也是个方法论有什么区别
如果说迭代，敏捷可以是迭代也可以不是迭代，而瀑布也可以是迭代，rup是一个典型的把瀑布的生命周期放到迭代中
用任何的方式很难定义敏捷
敏捷方法论如何诞生：诞生的时候与其他方法论不同的在于，它不是一个单独的方法、一个过程，它是一簇方法和一簇过程。在2001年敏捷宣言创立的时候它至少包括6个方法论参与到了讨论。在敏捷这个词被创造出来前它们被统称叫做新方法论。这一簇包括
极限编程（XP）:以开发人员为核心的方法，它的一切目的是为了方开发人员效率最大化。在敏捷开发人员实际在做项目中来工作的，要轻量化掉所有的过程，使之最适合开发人员。因此目前敏捷中大部分的开发和工程实践是源自XP方法。
SCRUM：是一个纯粹的管理方法，没有任何工程实践，他的工程实践需要根据scrum的选择再去选其他的工程实践。Scrum作为一个纯粹的管理方法后，它的管理目标是没有办法实际上来达成的。例如，我2个星期做一个迭代，这个迭代里面要做某些内容，没有工程实践的配合是无法做出任何内容上的变化。但是它是第一次从纯管理的角度来看在软件开发从迭代的角度如何来做
FDD：在产品开发方法里面新发展起来的，把产品分解成一些特征和特征树，把特征和特征树进行分团队的开发，之后再进行整合。
DSDM（动态系统设计方法）：如果只看过程，dsdm方法是非常类似瀑布方法的。在瀑布中的流程、管控、文档在dsdm中都可以找到
APT:从C++发展起的方法，可以用公式来计算在不同团队中使用怎样一个方法
很难讲什么是敏捷方法，我们更多的说的是敏捷方法簇。他们作为一个新方法在90年代末作为新方法的代表有着相似的价值观。经过会议后用Agile来代表许多方法背后的价值观。它是在具体方法、具体实践上的价值观。
个体和互动 高于 流程和工具
可工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应计划 高于 遵循计划
敏捷并不是少些文档，而是多做可工作软件。敏捷里面并不是不些文档，而是认为可工作软甲的价值更高。在商业社会没有合同是不可能的，但是比起扣合同中的字眼，更看重的是彼此之间的写作。遵守计划很重要，在敏捷中计划和进度性是非常强的，在适度的范围内去响应变化比起严格遵循计划的价值更高。敏捷的计划非常细，可以订到天、小时，但是在刚刚定下来之后不是不能改动的，当价值、优先级更高的事情发生变动，可以去响应它，比去按照计划价值更大。有过程是很重要的，在每个具体方法里面都有工具，但是我们认为个体互动更重要。在做事情的时候要问一下，到底是促进了个体交互，还是促进了流程工具。比如项目管理软件，我们公司有自己的项目管理软件，但是同时也有物理上面的卡墙。如果仅仅是电子的软件，是促进了工具的发展，还是个体的交互。一个物理的卡墙放在那边会引起别人的一些兴趣，引发一些对话。如果放到电子工具中，一样的信息但是就会缺少了个体之间的交流。比如，在敏捷中并不要求BA把story写的非常详细，让开发一看就知道怎么做，而是在开发的时候让开发去问Ba，促进的是开发人员和ba之间的交流
今天要讲的最颠覆性的，也是验证第二条的，在敏捷开发中度量进度的唯一方法就是可工作软件。在瀑布中比如6个月的项目分析（1m）、设计（1m）、开发（3m）、测试（1m）。当2个月的时候，这个项目完成了多少，在瀑布的度量里面就是1/3，但是在敏捷来看，这个项目还未开始，因为他还没有产出一行可工作的软件。如果这个项目在此时终止，那么有的只是一堆文档。
假设这个项目在10/1的是第一个release会有个交付的软件。在这个时候有它的价值比如会走完一个基本的流程。在这个中间的过程是怎么的？在这个release里面会分成若干个迭代，迭代是工作的单位，每个迭代的输入：IPM、kickoff、迭代结束的时候有show case。从story的级别来看，会有ba来分析story，story会有优先级。在开发前会有对story的kickoff，如果这个story已经写 的很详细了为什么还要有story的kickoff，因为开发、ba或者product owner之间想的会有不同，经过讨论才能更加清晰。Story只有完成测试才算做完。开发完成不能作为story完成。
在第一个迭代会有环境搭建、最小的story的编写。
环境：会要有qa的环境和uat的环境
敏捷日记（07/11~07/15)-敏捷项目估算方法
上周五下午，在整理完交付Story List之后，项目组进行项目估算，并以此排出优先级，并作为迭代排期的输入物。这里总结一下用到的项目估算方法。
回顾一下我们在平安使用的项目估算，有UCP和 Delphi估算方法。拆分方法不同，最后的估算结果都是人时。无论是UCP还是Delphi，都需要有组织级的生产率数据，才可以进行。
Thoughtworks在项目中使用的是故事点估算法，采用的是相对估算法。故事点只是一个计量单位的名称而已，代表完成一个难度适中、代码规模中等的功能点所需要的工作量单位。不同的项目所定义的故事点可能不一样。它应该也算是Delphi方法，但是不需要转化为具体工作量。
下图中每个白色小贴士就是写有估算点数的用户故事。
我们进行估算的时候，参与的人员包括了在场的所有开发人员：程序员、测试人员、数据库工程师、分析师、用户交互设计人员等等。所以，这样的参与人员比我们平台做估算所需要的人员要多。业务方参与估算但是并不作为估算专家。
大概的步骤为：
(1)选择一个比较小的用户故事，确定其故事点，将该故事作为基准故事。
(2) 选择一个用户故事。
(3) 主持人进行描述，主持人是PM或BA，当然也可以是其他任何人，业务方和BA回答估算者提出的任何问题，大家讨论用户故事。
(4) 每个估算者对该用户故事与基准故事进行比较，提出估算故事点数，
(5) 主持人判断估算结果是否比较接近，如果接近则接受估算结果，转向（2）选择下一个故事，直至所有的用户故事都估算完毕，否则转向（6）。
(6) 如果结果差异比较大，请估算值最高及最小的估算者进行解释，大家讨论，时间限定为不超过2分钟。如果大家同意，也可以对该用户故事进行更细的拆分。
在该方法中，参与的人员对于被估算的需求进行了充分的沟通。
Thoughtworks反馈按照4个程序员结对（Pair），一个迭代完成的故事点是21点。所以以此控制每个迭代完成的Story个数。
外部系统(如支付宝接口)的点数最高，为8个点。反映了Thoughtworks对关联接口开发是有些风险意识的。
后续在Technical Spilke环节可以进行试验，试着开发一个用户故事，度量花费的工作量，得到开发效率，即在本项目中一个故事点需要花费多少工时，再去调整所有故事的工作量。
说明，以上文字是是我的体会，加上另一种估算方法——策划扑克法的一些文字。项目结束后，会对此估算再进行整理。
策划扑克法的介绍请参考（http://wenku.baidu.com/view/10f4d51655270722192ef7f6.html）
用户故事颗粒度
注：感谢当时小伙伴们整理的日记
以上是关于我的Thoughworks-Scrum经历点滴的主要内容，如果未能解决你的问题，请参考以下文章