懒的态度

前面说了Scrum的迭代范围， 再来看看人――Scrum的参与者。 涉及到Scrum流程的角色包括PIG和CHICKEN。 Scrum Master和Team算是猪；Product Owner和Stakeholders算是鸡。 在Daily Scrum Meeting中 猪可言 鸡难语～ 每日花15分钟围成一圈站着开Scrum Meeting，是促成团结增进和谐的良方。 一般建议每个scrum team不超过7个人， 如果scrum的团队比较大，可以拆分为若干个team。 这种情况下就需要召开scrum of scrums。 也就是每个team的master或是lead要开一个会。 在老师的ppt中甚至展示了一种超大团队的meeting方式―― scrum of scrums of scrums，当然，这只是theoretically speaking... 在迭代过程中，如果用户的需求发生了改变，要考量impact， 如果小修改可以立即执行，但是如果影响到当前的sprint，尽量应当放到下一次sprint中加入。 原则上一旦sprint的范围确定就不宜修改。

Scrum定义scope有这么几个范围：Project、Release和Sprint。 首先，product owner拥有整个product的vision，他可以是来自客户方的代表，亦或是自己的产品经理。 product owner可以回答关于产品需要的特性、特性优先级等问题。 整个scrum team需要先整理出product backlog。 第二步，scrum team根据能力――capacity，也就相当于朴素的人月概念， 从product backlog中挑选出优先级最高的user stories构成第一个release。 定义release scope的阶段也成为sprint 0 在每个release中，再定义有多少个sprint，大的epic先拆分为合理的user story， 类似的，再将user story细化为task，并估算story point，assign给team member。 估算story point有很多种方法，有一种是planning poker， 扑克的玩法是通过多人估值，分别解释最大值和最小值，在取得共识的前提下再次出牌估值， 直到最终达成大部分的一致。貌似挺民主的做法。 不过印度老师说公司不采用这种方式，残念了…… 因为它的精度不是很高，ADM采用一种estimator，从以往的项目中进行估算。 选择user story的时候有一个顺序问题――优先选取难度最大而价值也最大的user story， 其次选取价值高难度一般的；接下来是价值低难度也低的，最后才选择价值低而难度高的。 这种选取顺序是有道理的，因为一开始就尝试完成风险最高而价值也最大的user story， 可以最早地将潜在的风险给暴露出来，这样万一出现了难以解决的问题可以及早客户沟通。 而反过来，价值最低风险又高的user story放在最后，也有好处， 这样客户可以选择是否在最终的sprint抛弃这个功能。

公司内部做了三天培训，请了一位印度老师介绍Agile/Scrum。 趁着还没有忘记，赶快整理一下思路～ 故事源于 Agile Manifesto 。一群大牛聚在某个motel里头琢磨出的宣言…… Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 敏捷方法包含了很多内容，如eXtreme Programming、Crystal、FDD什么的。 当然，Scrum是其中被广泛运用的一个分支，主要定义了一种开发的方法论。 相较于传统的瀑布模型，敏捷更愿意拥抱变化， 因此change requirements如果impact不大的话在scrum中是可以迅速被接受的。 敏捷方式开发并不意味着开发周期一定比传统的方式短，不过质量应该更好。 据说有研究表明，同样周期的项目开发，敏捷方式的产品质量要明显占优。