首页 > 代码库 > 构建之法 第六章 敏捷流程

构建之法 第六章 敏捷流程

敏捷是一种很“年轻态”的思路/策略,是以“万事万物都在不停地发展变化”为指导去组织软件工程的需求分析、内部的调和、代码编写甚至维护,所以我读起来会觉得很有共鸣。然而并不是所有的地方都适合让“敏捷”去闯一闯。

1.敏捷开发原则

【适应瞬息万变的形式,力求在大潮中可持续发展;年轻态】

【个人进行了分析组合】 1. 可用的、尽早交付的软件是项目进展的主要指标 2. 保持可持续的发展,以需求作为发展优势 3. 自我管理。无论是交流还是信任还是共同工作

2.敏捷流程

  1. 找出product backlog【与之前的需求分析不同,这里的backlog不是很“厚”】
  2. 决定当前的sprint即sprint backlog【分解为16小时以下的backlog,团队成员根据任务量和自身条件认领backlog】
  3. sprint【每日一例会,各自汇报做了什么,有什么困难,下一步计划】

另外,如何让敏捷流程不流于形式?

  • 定义好任务量。特别是“还剩多长时间”
  • sprint的时候团队保持高度运转,不以外力作用而(暂时)停工或者受到其他影响
  • sprint之后如果发现大问题,还要DCR(design change request)
  • 任务都完成了不等于可以高枕无忧了。至少(往往)20%的测试任务要花掉80%的时间

3.关于敏捷的另外几条神来之笔

  1. 敏捷的团队非常“自我”——自我管理、自我组织,好像非常易于变型的填充物,很多成员都可以有很多“功能”;
  2. 不要和管理层谈“过程”,他们只要结果【见人下菜】
  3. 大多数被测试、被研究的新东西都很有效果。
    • 参考http://baike.baidu.com/link?url=beVwHx-Synb517sWsjPQ2bsHuzc5qCCX0QrSZ8Ow91TvoPEEEhES7R43SUI_ylpAKv0O5hBoWNwwePhGntQ05lTlqJtpZ7bdIBhSatWAXo-aZcVU8UM0qGoD1n3NruSxt-oMS41qOn9lQWSQBvhK
    • 很有意思的心理学实验结论;似乎做表面文章的时候经常会和这个结论打交道。然而“任何刺激因素(如薪水)都不是非常有效的,因为它总有效用饱和的那一刻”
  4. 我们需要敏捷(agile)的开发流程,而不是匆忙(rushed)或者忙乱(chaotic)的流程
  5. 敏捷不是万能,它只是能够帮助你更早知道自己能否如期完成任务【因为产品会很早就迎来用户“检查”】

构建之法 第六章 敏捷流程