前段时间参加了两天敏捷开发管理培训，收获挺大，在这里做一下总结。

理解敏捷

整个培训过程中一直穿插着敏捷软件开发的原则进行讲解，这里摘录给我感触最深的几个：

  • 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意，经常地交付可工作的软件，相隔几星期或一两个月，倾向于较短的周期。
  • 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
  • 团队定期反思如何能提高成效，并依此调整自身的举止表现。
  • 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

敏捷流派主要有两个：Scrum 和 极限编程。Scrum侧重项目协作流程，极限编程侧重提高编程效率的技术实践。两者应该相辅相成。这里着重讲讲Scrum。

团队与角色

Scrum中有Product Owner、Team、Scrum Master三类角色。一个好的Scrum团队以下特点：

  • 通常5~9人；
  • 跨职能，跨模块人员构成；
  • 成员应全职投入；
  • 团队自组织管理；
  • 迭代内保持团队成员稳定。

做好一个Product Owner要点如下：

  • 定义产品功能；
  • 定义产品发布的日期和功能；
  • 对产品的投入产出比负责；
  • 根据市场情况对需求排列优先级；
  • 如果需要，在每个迭代合理调整产品特性及其优先级；
  • 介绍或拒绝开发团队的工作成果。

Scrum Master要引导团队自己去找答案，而不是做一个发号司令的人，做好一个Scrum Master要点如下：

  • Scrum正常运作的守护者；
  • 激发团队创造力；
  • 改善开发团队的外部环境；
  • 辅导团队提升运作效率；
  • 排除团队遇到的困难；
  • 保持团队紧密合作；

Team就是团队中的开发、测试或ui设计人员。

需求管理

Scrum通过编写用户故事来管理需求，好的用户故事的原则如下：

  • Independent独立的；
  • Negotiable：可讨论的；
  • Valuable：对用户或客户有价值的；
  • Estimatable：可估计的；
  • Small：小的；
  • Testable：可测试的。

之后要进行工作量估算，Product Owner(业务人员)必须在场梳理需求，每个项目成员针对用户故事的疑问向Product Owner提问，所有人弄清楚需求后开始。

大家先找一个参照需求，确定它的工作量，然后其他的需求就按照这个参照需求来估计，这种相对估计法确保每个人估计出来的工作量是一致的。

使用扑克牌，大家同时给出需求的估计值（而不是轮流进行），估值最高和最低的必须分别给出原因，这样做的好处让大家都独立思考。通过多轮估值让所有人了解需求，并估算出一个较为合理的工作量。

Scrum中的各项活动

简单来说，划分如下

项目计划|
Sprint0|
Sprint1|
Sprint2|
Sprint3|
项目总结|

按一个迭代周期来说，主要划分如下：迭代计划和评审一般要占用两个小时，而站立会议一般15分钟。

迭代计划1|
迭代计划2|
站立会议|
…|
站立会议|
迭代评审|
迭代回顾|

Spint0要做一些准备活动，如高层的业务流程图、初始的用户故事列表、测试策略、发布计划、团队建设、技术架构的选择、设计UI的风格等。

站立会议

晨会的要点：

  • 轮流发言，持Token者才可以发言；
  • 不讨论深入细节；
  • 不是对领导汇报，让团队中每个人都了解你的发言；
  • 不能单独讨论，自发的有序的进行发言；
  • 时间在15分钟以内。

站立晨会的三个经典问题：昨天我完成了哪些工作；明天我打算做什么；完成我的目标是否存在什么障碍。
站立晨会的目的不是为了让大家都回答那三个问题，而是让团队围绕这三个问题，制定当天的工作计划并暴露问题。

迭代验收和回顾

迭代验收会议，通过演示可工作的软件检查需求是否满足客户要求；迭代验收的好处：

  • 通过演示可工作的软件来确认项目的进度，具有真实性；
  • 能尽早获得用户对产品的反馈，使产品更贴近客户需求。
  • 收集反馈。

迭代回顾会议，目的是分享好的经验和发现改进点，促进团队不断进步，迭代回顾的好处：

  • 激励团队成员；
  • 帮助团队挖掘优秀经验并继承；
  • 避免团队犯重复的错误；
  • 营造团队自主改进的氛围。

利用敏捷改进现有工作

即使不使用敏捷方式开发，也可以利用它的一些好的想法和实践可以用来提升目前的工作效率。

  • 比如敏捷开发中如何调动团队积极性，让每个人看到的是团队目标，而不是个人目标。
  • 比如经常地交付可工作的软件：以此提高软件开发的质量和可交付性。
  • 比如借鉴敏捷中设定Sprint(冲刺)的开发过程，调动开发人员的积极性以及明确每个开发阶段的目的性。

其他问题

  • 需求文档 或者 使用说明文档 写了100多页，但是写完之后基本没人看，这样的问题应该很普遍，该如何解决？
    把Word文档迁移到Wiki上，大文档切细分成一个个独立的Wiki页面，Wiki可以统计页面的访问次数，有了足够的数据支撑之后就可以把访问次数少的页面去掉，以此来精简文档，这样留下来的文档内容就是真正有用的。
  • 业务部门的需求太多而且每个都非常紧急，怎么处理？
    业务部门拉一个人对需求按价值进行排序；需求收集例行化，主动收集，需求有一定的清晰度；回顾哪些需求不重要，做为武器。