8/22/2010

About scrum meetings

在Sprint中,ScrumMaster要确保没有任何影响Sprint目标的变更发生。团队构成和质量目标在Sprint中均保持不变。Sprint一个紧跟一个进行,之间没有任何时间间隔。发布计划确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能。

在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。发布计划会议需要为该发布做产品Backlog条目的估算和优先级排列。

Sprint计划会议的产物是Sprint Backlog。计划会议一般安排整个Sprint周期的5%时间。Sprint计划会议包含两部分内容:“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。第一部分,Scrum团队处理“做什么”的问题。
产品负责人给团队介绍最高优先级的产品Backlog条目,并一起决定接下来的Sprint中开发什么功能。Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少产品Backlog的条目,因为只有团队可以评估在接下来的Sprint内可以完成什么工作。选定产品Backlog条目后,Sprint目标也就明确了。确定Sprint目标的原因是在功能方面为团队留出一定的回旋余地。例如,上一个Sprint的目标可能是:“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。所以当团队工作时,就会紧记这个目标。为了达到这个目标,团队就需要实现该功能和技术。如果团队感觉实现过程比预期的难度大,那么就可以和产品负责人协商,只实现部分功能。
在Sprint计划会议的第二部分,团队需要处理“怎么做”的问题。在Sprint计划会议的第二个4小时时间箱中,团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog条目转化成完成的增量。通常团队会先以设计展开工作,设计过程中,团队确定任务,这些任务就是将产品Backlog转化成可用软件的具体工作。任务需要被分解,以便在一天之内完成。这个任务列表就是SprintBacklog。团队通过自组织,并且是自己认领的方式分担任务,任务认领可以在Sprint计划会议上进行,或也可以Sprint中及时(Just-in-time)确定。产品负责人会参加Sprint计划会议的第二部分,为团队讲解产品Backlog条目,并协助团队权衡取舍。如果团队认为工作量过大或太小,就可以和产品负责人重新协商、确定产品Backlog。

新组建的团队常常在这次会议中第一次意识到:整个团队要么一起成功,要么一起失败,没有个体这个概念。团队同时认识到必须依靠自己。正因为意识到这一点,整个团队才逐渐自组织并形成自己的特色,真正成为一个团队。

Sprint结束时要举行Sprint评审会议,该会议的时长不要超过整个Sprint的5%。 评审会议至少要包含以下因素:产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后,团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog,并根据不同的速率计划出可能的完成日期。接着,整个团体就哪些工作已经完成,同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。

在Sprint评审会议结束之后和下个Sprint计划会议之前,Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint,回顾会议的长度一般为3小时。回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的,和那些如果采用不同方法可以取得更好效果的条目。这些包括:Scrum团队、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的最后,Scrum团队应该确定将要在下个Sprint中实现的有效改进方法。这些变化更适应于经验检验。

About sprint backlog

由于在Sprint的刚开始的时候,增加的任务工作量可能大于完成的任务工作量,所以燃尽图有可能呈上升趋势。

任何人,包括ScrumMaster都没有权利规定团队如何将产品Backlog转化成可交付的功能增量,而是由团队自己确定。每个团队成员利用自己的专业技能,解决遇到的问题。这种协同配合提高了团队整体效率。

团队的构成在Sprint结束时可能会发生变化,每次团队成员的变化,都会降低通过自组织而获取的生产力。因此,改变团队构成时务必要谨慎。

Some basic scrum rules

Scrum的最基本原则是“Inspect and Adapt”(检视然后适应),如果什么事情做得很好,问问自己为什么,然后寻找提升的办法。

一个自组织的团队有一个非常明显的每天的节奏:Daily Scrum之前非常安静,每日站会之后会有一段活跃的讨论,到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论,当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能够感受到这个节奏,则说明团队是很健康的,每日站会起到了很好的效果。

1. 需要有全职的有威信,有能力的产品负责人(PO-Product Owner).
2. PO要和Scrum Team、其他的利益相关者(stakeholder)一起工作
3. 有PO来创建和管理产品backlog.
4. Scrum每日站会必须的3个问题(完成了什么,准备做什么,有什么障碍)。
5. Scrum每日站会要在固定的地方时间不要超过15分钟。
6. 有规律的Sprint长度(不超过30天)
7. 在Sprint计划会议上创建Sprint Backlog和经过详细估算的任务列表。
8. 一定要有Sprint的燃尽图。
9. Team必须的设备及相关的供应要齐全。
10. 使用回顾会议确保过程在不断提升。
11. 有明确的对于“任务完成”的定义。
12. 按照合理的速率给出承诺(根据Sprint的工作量估计)。
13. 团队大小在7 +/- 2,最多不能超过12人。
14. 跨职能的团队包括ScrumMaster和PO.
15. 自组织的团队 - 团队成员志愿挑选任务。
16. Scrum master要跟踪进度,并且为团队扫清障碍。
17. 确保Team不被外界干扰。
18. Sprint之间不能间断。
19. 合理的节奏 - 根据固定时间段来确定任务量, 不只是一个进度表。
20. 质量是第一,不需要在质量上讨价还价 - 代码缺陷永远位于Backlog的最上层。

About product backlog

一个完整的backlog是一个的蓝图,可以根据它来把产品改造成为我们期望的样子。
但是在Scrum中,Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的,我们会持续的改变它去确保我们的产品是最合理的,最有竞争力的,最有价值的。

使用用户故事来描述产品Backlog条目是一个非常有效的实践,我们通常也把验收条件或验收测试作为产品Backlog条目的一个属性。

About Daily Scrum Meeting

每日站会和传统的项目会议有如下几点不同:
1. ScrumMaster或者其他任何人来指派任务。
2. 团队成员不是向ScrumMaster汇报情况,而是向其他的团队成员更新和同步信息。
3. 团队成员不会在会上讨论或者解决问题,大家会把问题记录下来,会后找相关的人讨论或召开具体的讨论会议。
4. 任何团队之外的人不得发言或干扰会议。

一个好的每日站会有如下几个特点:
1. ScrumMaster不会逐个的问每个人问题,如果是,那么这个会议已经沦为了报告会。
2. 团队成员互相交流,不是向ScrumMaster报告。
3. 每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会,你就不需要再担心超时了。
4. 站会结束后,ScrumMaster知道哪些问题需要帮助团队成员解决。

8/21/2010

零零散散的小东西

在需求定义上,我们需要采用业务导向的需求定义,保证每一个需求的完成都可以交付一定的商业价值。以往的需求往往是功能导向的,但是功能导向的需求对于用户来说不一定具备商业价值,但是业务导向的需求则可以保证这一点

Scrum团队是自组织的. 任何人,包括ScrumMaster都没有权利规定团队如何将产品backlog转化成可交付的功能增量,而是由团队自己决定.每个团队成员利用自己的专业技能,解决遇到的问题.这种协同配合提高了团队整体效率

最后,Sprint回顾会议是用来评审已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效,更加令人满意,并且工作更快乐

8/03/2010

沟通与管理(1)

好久没丢新垃圾了, 一些看到的见到的有用的东西

------
•在会议上,询问每个团队成员他们喜欢原来团队的什么方面,他们希望现在的团队有什么改变。
•使别人容易地得到你对问题和疑虑的回答。
•组织团队出游,团队出去吃午餐,确保新成员和旧成员坐在一起。
•作为ScrumMaster,确保你花一些时间和每个成员一对一交流,方便观察他们适应新团队动态的情况。

是使团队不受干扰直至Sprint的结尾

•如果在项目中已经太晚了,拒绝向团队中增加成员。
•同时引进所有新人,来减少逐步增加团队成员的成本。
•在团队中混合新人和旧人。
•要求新人使用重构、写单元测试、自动化验收测试来使他们提速。
•让新人和其他开发人员结对。

使用新人其实最关键是两个问题,第一是怎么快速培养新人,能让他们迅速适应岗位,第二是如何留住他们,只要解决这两个问题,新人就可以放心大胆地用

很多人怕新人犯错导致项目出问题,实际上这个问题出在监管上,新人在项目中肯定会犯错,这个时候你需要让一个负责任的老人去带他,起到这个事前提醒事后控制的作用

实际上许多人的离开,并非因为工资的原因,工资确实会导致一个人的离开,但很多时候不是主要原因,特别是对于一个踏入职场三年以内的人来说。他们最需要的是成长和受关注

关于该项目的目的首先要确定,究竟是以设计品质为标杆,还是以时间进度为标杆 — 如果是以品质为标杆,那么在可以接受的时间内,应该无条件的完成产品的设计上的品质要求;如果是以项目时间为标杆,那么可以优先解决产品中最紧急的问题,然后在下一次的升级版本中继续完善设计的部分

如果项目不是那么急,建议可给设计师多留一点点时间,并规划好评审会议与交付件的内容,目标时间应该以一个具体周期(比如一周)作为检查反馈的坐标,而不是整个设计阶段结束后才开始找设计师要东西。让设计师自己提出一个合理的时间,设计经理帮助协调资源(设计经理本人应该清楚具体设计内容需要的行业标准时间)是比较合理的。

作为管理层最不愿意参与的事情莫过于员工的自我管理,如果一个沟通过程(绝大多数情况是某些会议)显得缺乏准备,没有预期效果,那么我建议你最好不要先通知领导参加,否则他只能看到你处理事情上的不成熟

这个问题的最简单解决办法就是在项目开展初期,即明确各个部门的职权与关键点的评审责任,比如:页面实现一定要遵守页面设计效果图,代码效率一定不能低于某款产品的标准,软件开发一定要满足交互设计的预研效果

沟通的阀值是指沟通的心理底线,每个沟通的过程总是会有目的,达到这个目的会影响每个参与沟通的人的心理价位,一般来说,如果你要确定沟通中的有价值的部分,你需要回答四个问题:你的意见或者批评 — “有用的是什么”、“没用的是什么”、“如果这么做,得到什么”、“如果不这么做,失去什么” 如果沟通过程中,你说的话没有解决以上4个问题中的任何一个,那么你说的话基本是废话,没有沟通的必要。

一个关于开发周期确定的问题,可以降低到开发人员配置与项目周期的问题,而开发人员配置可以降低到人员数量和工作时间计算的问题,人员数量的问题可以降低到是不是有资源提供加班补助的问题。

如果你的成员说这个东西没时间做,潜台词就是“你没有给加班工资”,如果你的成员说这个东西有风险,潜台词就是“你给的钱和职位不足以让我承担这个风险”,如果你的成员说这个东西很简单,可以稍后考虑,潜台词就是“这玩意做得没意思,杀鸡不能用牛刀”,如果你的成员说我们慢慢来,心急吃不了热豆腐,GOOD,他可能准备跳槽了。

大部分沟通峰会,如果你注意观察的话,多数人都乐于提出现象,而不是问题本身,比如: 你们市场部不能老这样提出修改,产品都没做完,为什么要改呢? — 这个话根本没有说出问题的关键,问题出在为什么市场部可以提频繁的修改需求?谁给的权利?客户的要求由谁过滤的?修改的成本谁来承担?修改不好谁又来负责?是输入问题还是输出问题?

沟通要保证效率,就得在沟通之前准备好真正的问题,围绕问题,提供解决方法
-----