谈谈敏捷那些事

从H3C实习开始到现在差不多有六年多，这六年里，经历项目越来越多，对与软件开发流程的思索也越来越多。不同的公司，不同的项目，不同的管理方式，各显优劣，一时之间也很难去评价。评价虽难，但想法是有的，好吧，我决定将这些想法记录下来。
想法的开端就是敏捷模式。

软件模式评判之我见

第一次听说敏捷这个词，感觉就一个字：快。 快，也一直是我追求的一种工作形态。但仅仅快是不行的，还要好。“快而好”是评判软件管理模式的硬性指标。但这个“快而好”，是要建立在交付的前提下，同时，优秀的软件管理模式也要能够兼容团队人员能力的成长。所以，“面向交付，快而好，能持续增长团队人员能力”是我对管理模式优秀与否的一个基本评判。

如果仅从方法论的角度考虑，敏捷大体上满足了我对一种优秀项目管理模式的评判。

敏捷：方法论的一种

方法论是指以解决问题为目标的体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。敏捷作为一种方法论，它的原则在于：个体与交互重于过程和工具，可用的软件重于完备的文档，客户协作重于合同谈判，响应变化重于遵循计划。这就是敏捷的四大宣言。

敏捷：方法论建模

方法论要运用到实践，建模是必不可少的环节。敏捷建模（AM）大体上包括以下几个环节：

Sprint（Iteration），Sprint plan，Sprint review， Sprint retrospect，Standup meeting，Demo，Pair Programming，Refactoring。不同的项目可能会增加或裁减一些环节，但我目前碰到的项目这几项基本都包含在内。下面是敏捷模式开发的一个基本流程：



敏捷： 角色

Scrum中有3种角色，分别是产品负责人（Product Owner）、Scrum Master 和 Scrum 团队，他们各自的职责如下：

产品负责人（Product Owner）

Product Owner 需要确定产品的功能和完成时间，并对产品的收
4000
益负责，要根据市场需求确定产品功能的优先级。在每个Sprint开始之前，Product Owner可以修改功能需求和优先级。而且，Product Owner 有权决定接受或否决各个Sprint的工作成果。

Product Owner 的角色通常由市场部门的人员或开发部门门内部主要使用该产品的人员来担任，主要工作是根据市场需求确定产品功能，将其列入Product Backlog中，并为这些功能确定优先级。

Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。

在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。

Scrum Master

Scrum Master的职责是：负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫清障碍；保证开发团队不受外力的干扰和阻扰；掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和 Sprint评审会议。

Scrum Master 通常由传统开发中的Team Leader 来担当。

Scrum 团队

一般由5~10个能全职工作的成员组成较为理想。

团队成员横跨各个职能，通常包括开发、测试、文档设计人员等。

敏捷：管理工具

JIRA：JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富，其超过150项特性得到了全球115个国家超过19,000家客户的认可。

KANBA：


敏捷：开发过程

如何进行Scrum开发？

1）我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2）Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3）有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4）Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5）在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6）做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7）当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8）最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中。