敏捷Scrum运作Tips

部门开始推行敏捷了，采用SCRUM。其实SCRUM作为一种方法论，并不难理解与落地，难的是人的观念与习惯，如何转变。作为IT人员，其实都了解敏捷，做不到没有任何借口，只能是意愿问题。但对于非IT企业的业务部门，接受敏捷思想确实有一定难度。因此落地上，产品运维阶段，适合采用SCRUM。毕竟只是在IT内部玩嘛，对于业务是感知不到差别的，照常提需求、验收，若是以前就有需求评审会的话。而对于项目，则较难落地。一是业务不跟你玩，业务不喜欢不确定性，喜欢按照既定流程稳扎稳打，而且人家没时间陪你试验新概念；二是涉及甲乙双方，要严苛按照范围、计划走，敏捷若没玩好，交易成本可以无限大。

有意思的是，部门去年推行过敏捷，通过项目管理软件的kanban功能，要求各团队把工作录入到线上运作，结果不了了之。而今年通过海报形式，却完美落地了。一方面是推行力度的加强，另一方面却是由于方式的改变。线上kanban，不直观、不显眼，还需有人维护系统，有一定学习成本，还能找到系统问题从而拒绝使用，而换了贴纸，绕着办公室一个团队贴一张，第二天就全部门上手使用了。天天讽刺业务部门，excel邮件满天飞，就是拒绝系统。好比拖拉机开的爽，轿车倒开不惯。所以有的时候，管理问题，线下比线上更具效果，虽然管理成本大。

---

Agile manifesto

individuals and interactions over processes and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to changes over following a plan

之所以互联网适用敏捷，因为适合是快速粗放增长的特性。一个APP一个月上线，生命周期半年，当然不用管文档与工具。先出一版能用的软件，抢占市场，然后迭代。2B产品，特别是大公司的重量级产品，ERP能用十年，相关人员都够换几波的了，全靠流程化运作与充足的wiki支撑。或者涉及实施方的项目，全靠合同与SOW扯皮，能不专注在前期合同上吗？又如拥抱变化，业务的变化是无止境的，项目的关键是控制变更，目的确定了，那就是以最短路径到达，不能过分强调变化。当然敏捷的思想，任何角色、任何场景都是值得学习的。这里强调的，不能为了敏捷而敏捷，或者把其看做对传统项目管理的革命。

---

Agile principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4. Business people and developers must work together daily throughout the project.项目过程中，业务人员与开发人员必须在一起工作。

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7. Working software is the primary measure of progress.可用的软件是衡量进度的主要指标。

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9. Continuous attention to technical excellence and good design enhances agility.对技术的精益求精以及对设计的不断完善将提升敏捷性。

10. Simplicity–the art of maximizing the amount of work not done–is essential.要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11. The best architectures, requirements, and designs emerge from self-organizing teams.最佳的架构、需求和设计出自于自组织的团队。

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

---

five activities

1. product backlog refinement；

2. spring plannning

   1. what can be done?

   2. how to get it done?

3. daily stand-up

   1. what did i get done yesterday?

   2. what will i get done today?

   3. any impediments blocking me?

4. sprint review

5. sprint retrospective

   1. what shall we start doing?

   2. what shall we stop doing?

   3. what shall we keep doing?

以月为冲刺周期，因团队规模小，采用了简化版的会议形式，缩减为三个例会：

1. 月度版本会议（成果及问题；改善；下个迭代期计划）2H

2. 每日站会 15min

3. 每周五总结会议 （这周做了什么，下周计划，任何阻碍/帮助）30min

---

three roles

1. development team

2. product owner

3. Scrum master

PO与SM，可以理解成一个做正确的事情，另一个正确的做事情；PO连接客户与管理团队，而SM连接管理团队和开发团队；开发团队聚焦每一个冲刺期内的质量，及各冲刺周期的关系，不断提升能力。目前团队规模小，产品经理身兼PO及SM。。

---

three artifacts

1. product backlog

2. spring backlog

3. increment

产品积压项面向功能点function，冲刺挤压项面向特性feature

---

requirement management

1.  user story：As a [a user role], I want to [accomplish a result], So that [I can get some business value]

2. 3C

   1. card

   2. conversation

   3. confirmation

3. INVEST

   1. independent

   2. negotiable

   3. valued

   4. estimated

   5. sized appropriately

   6. testable

4. PSPI: potentially shippable product increment

5. DOD definition of done

6. DOR definition of ready

重点是用户故事，用故事点评估工作量，颗粒度如何衡量。

---

test driven work

1. TDD test driven develpment

---

relative estimation

---

agile planning &tracking

1. release level；

   1. decide when to release what, at refinement meeting;

   2. feature burn-up chart

2. sprint level;

   1. burn-down chart

   2. planning poker

3. daily