敏捷读书笔记与思考 -- 长期维护

1.
Scrum的三大支柱支撑起每个经验型过程的实现：透明性，检验和适应；

2.
检验和适应的四个时机：
sprint计划会议；
每日例会；
sprint评审会；
sprint回顾会；

3.
敏捷核心思想：
个体和交互重于过程和工具；
可以工作的工具重于面面俱到的文档；
客户合作重于合同谈判；
随时响应变化重于循规蹈矩；

4.
敏捷核心思想概括起来就是：适应变化和以人为本
敏捷开发方法过程是面向人而非面向过程的；
敏捷开发方法时主动适应而非预先预定的；

5.

Scrum 中有3 种角色，分别是产品负责人（Product Owner）、ScrumMaster 和Scrum 团队。

敏捷开发的理念是信任开发团队，信任每一个人。

充分调动参与项目的人员的主动性，让他们自我组织、自我管理，由团队自身来掌握项目进度，比老板整天催促反而更有效率。

自我感想：
当然团队成员的选取时必须是那些遵循规则的人，善于钻空子和逃避责任的人并不适合敏捷团队。
敏捷开发从一个侧面体现了软件开发的民主思想，所有人共同遵守契约并为了共同的利益和目标而努力工作。

6.

敏捷开发的团队也需要管理，但这些管理是非命令式的，很多时候是战略指导和服务性质的

在敏捷开发中，管理者对团队和项目的管理表现在挑选合适的人、为团队创造一个开放而自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等。

7.
有一种误解，认为敏捷开发就是完全不需要计划、文档和架构设计。

敏捷开发也需要文档，也同样要计划。

但是计划赶不上变化，在这样一个不断变化的情况下要做出详细的计划是不可能的。因此敏捷方法认为不值得在这些因素上花费过多的资源，可工作的软件才是敏捷方法关注的重点。敏捷团队依靠变化来获取活力，他们更愿意使设计保持尽可能的干净、简单。

采用敏捷方法的项目初始设计是比较粗略的，并需要使用许多测试手段作为辅助，这就保持了设计的灵活性和易于理解性。

可以利用这种灵活性持续地改进设计，以便于每次迭代结束时的系统都具有最适合于那次迭代中需求的设计。摆脱一切对软件开发不合理的束缚就是敏捷。

8.
听听专家怎么说：

“敏捷联盟的发起人Martin Fowler 和Jim Highsmith 曾经这样解释过：敏捷开发所追求的是一种平衡——我们也建模，但不仅仅是画几个模型图存放在少人问津的项目文档库里；我们也需要文档，但从不浪费纸张去编造那些极少使用而又没有保存价值的大部头；我们也做计划，但我们同时也认识到在这纷繁复杂的环境中做计划是困难的。”

“但是，敏捷开发不是可以解决所有问题的银弹。在实际的项目中，受条件的限制，有些原则实施起来确实有困难，那该怎么办？要知道，敏捷并不要求你们一成不变地遵循这些条条框框，遇到困难时应该灵活地调整策略，这样才真正达到了敏捷的目的。”

9.

软件开发中优先级最高的事情是给客户提供有价值的、可以工作的软件，因此软件开发最重要的是给客户创造价值。

“敏捷开发随时拥抱变化、响应变化，而不是恪守计划”

软件开发团队进行高度的自我管理，管理者要充分信任开发团队

“实施敏捷开发是很痛苦的，这种转变不是一天两天就可以完成的。敏捷开发也不是银弹，不能指望它解决所有的问题。”

10.

团队每个人都必须有非常强烈的客户和市场意识，根据客户的需求设计最好的软件

A very good team player

Excellent communication skills

Open minded, pro-active, and self-motivated

11.

在项目的开始制定一个有效沟的通计划至关重要，对于敏捷开发尤其如此。

12.

通常在敏捷开发中，制定的产品Backlog 不是一成不变的。敏捷开发中的每个Story都要求是由市场和客户驱动的。

User Story 是从用户的角度对系统的某个功能模块所作的简短描述。