构建之法阅读笔记 02

　　这次是看完了第六章，关于第六章，我感觉有几个比较重要的问题：

　　敏捷开发是什么？

　　“最初的软件（20世纪六七十年代）的顾客都是大型研究机构、军方、美国航 空航天局、大型股票交易公司，他们需要通过软件系统来搞科学计算、军方项 目、登月项目、股票交易系统等超级复杂的项目。这些项目对功能的要求非常 严格，对计算的准确度要求相当高。 +20世纪八九十年代，软件进入桌面软件时代，开发周期明显缩短，各种新的 方法开始进入实用阶段。但是软件发布的媒介还是软盘、CD、DVD，做好一 个发布需要较大的经济投入，不能频繁更新版本。 互联网时代，大部分的服务是通过网络服务器端实现，在客户端有各种方便的 推送（Push）渠道。一般消费者成为主要用户。网络的传播速度和广度，使 得知识的获取变得更加容易，很多软件服务可以由一个小团队来实现。同时， 技术更新的速度在加快，那种一个大型团队用一种成熟技术开发2——3年再 发布软件的时代已经过去了。用户需求的变化也在加快，开发流程必须跟上这 些快速变化的节奏。”

　　这就是敏捷编程之所以出现的原因。

　　根据构建之法一书，我感觉这两个问题比较重要：

　　一、怎样才能做到让自己的团队变成一个敏捷的团队？

　　1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务； 每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自 主管理”不等于“没有管理”。

　　2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对 项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。  

　　3. 多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都 全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。

如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用， 也许还会适得其反，往往需要多次Sprint才能让Scrum走上正轨。换句话说，如 果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么 用不用Scrum都能写好软件！

　　二、对于敏捷开发有一些经验。

　　1. 敏捷宣言表明的是一些优先级，不必当作圣旨或者教条来争论。

　　2. Scrum Master不是一个官，而是一个没有行政权力的沟通者，就像微软的PM 那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master，大多行不通。

　　3. 一些项目需要很多暗箱操作和政治角力才能搞定，Scrum会把这些矛盾都摆到 明处。这有好处，也有风险。

　　4. 在复杂的项目里，要让一线团队成员做决定。

　　5. 创业公司的团队其实经常是运行在Scrum 的模式中（只不过大家太忙，没工夫 论证自己到底有多么Scrum）。

　　6. 在Scrum计划阶段的估计不是一个“合同”，领导们不要把它当成一个合同。估 计总是不准的。坚持短期的Sprint，这样即使不准的估计也不会有大的损害。

　　7. 不要和管理层谈“流程”，他们只关心“结果”。

　　8. 在大型团队、跨地区的团队，或者复杂项目中，Scrum并没有非常完美的答 案，Scrum的创始人也承认这一点。

　　总的来说，在这个软件开发行业高速发展的时代，团队敏捷开发的实现已经变得很重要，所以一定要对敏捷开发有所了解。