当我们在谈敏捷时我们在谈什么？( 二 ) _敏捷

敏捷中很多实践更多的被当做工具库，按需实践，很多实践甚至需要付出巨大成本，因此在我们实际工作中都需要被裁剪。
实话说，有些被纳入敏捷中的实践在工作中并不好用，更像是皇帝的新装。
迭代和增量式开发（IID）
迭代是敏捷开发最显著的特征。我个人的理解为人们无法做到像瀑布模型描述的那样准确完成所有的设计，并精确实施。
迭代的用途有下面一些：

响应在开发阶段接收到的最新需求和变化。
我们无法精确完成所有的前期设计。
不能接受在最后一刻才进行集成。
。。。

在现实中，迭代是一种克制和权衡。敏捷拥抱变化，但是尽量在迭代中别变化，否则固定的迭代就没有了意义。
迭代这个话题的另外包括迭代周期是否固定、周期多长的问题。
在实践中，迭代周期不固定非常难操作，团队的整体习惯难以培养，有点类似倒时差的感觉。
常见的迭代周期有一周、两周、四周等，迭代周期越长越像瀑布，迭代周期越短越像精益，而迭代周期适中就很像 Scrum 。
Scrum 一般以两周、四周作为迭代周期，适合大部分项目。
其实，由于每个迭代都要重复很多活动，迭代会增加成本。迭代在敏捷中的作用是：牺牲局部效率，减少分工，提高整体效率。
跨职能团队
敏捷的另外一个显著特点是跨职能团队。跨职能团队的意思是，不会将团队按照专业岗位划分，而是将不同的角色混编到一个团队。
在跨职能团队的每个人集成起来，让敏捷团队看起来像一个增强的开发者，团队和团队之间是原子化和去中心化的。
我对跨职能团队的理解是，软件开发无法做到像生产型企业一样有序传递信息，知识型团队和生产型团队有本质差异。
举个例子，生产型团队的加工过程都是被优化过的固定模式，所以他们更强调流程、秩序，产品从设计部门、组装部门、测试部门都有明确的标准、考核方式。
但是，软件工程不是这样的。软件工程长期以来被比喻为建筑业、制造业，其实更像是出版业。我们无法像工厂一样工作，几十上百人合作编写一部百万字的巨著。
知识性团队的信息传递变得更加不可靠、不确定且多变，跨职能团队才能合作更加紧密。
看板和消息辐射器
使用看板并不是敏捷最初的特点，甚至不是必选项，看板在敏捷中作为“消息辐射器”存在。
看板是“消息辐射器”最主要的形式。“消息辐射器”是指在团队日常工作中，需要一个信息发布的公告板，这样所有人都能及时同步获取所有的信息。
一般来说常见的消息辐射器有：

任务看板：用来同步团队工作状态和任务清单。
燃尽图：用来显示团队的进度状态，燃尽的意图是团队作为一个整体，不以某个人作为进度追溯单位，而是整体拉通看项目进展。
流水线健康看板：展示持续集成流水线的健康状态，避免因为构建失败阻塞其它人的工作。
。。。

部署“消息辐射器”的意图有：

团队保持透明，不需要对来访者（客户和干系人）隐藏信息。
团队内部共享信息，不需要隐藏问题、知识和困难。

持续集成和发布
即使在迭代中，也需要避免返工和增量式构建，因此敏捷提倡持续集成和发布。
让软件随时处于集成状态和可发布状态。传统意义上，集成需要花费程序员一些工作和时间，但是结合持续集成工具的使用，持续集成环境被设置好后，现在几乎没有成本。
持续集成是现代软件工程显著的特点，让上规模的软件能可靠交付的保障之一，也让团队有序扩展变得可能。
用户故事和待办事项
为了做到上述实践和期望，在敏捷中需要将任务拆分到足够小，但是又能单独被验收、测试和集成。
所以使用了用户故事（User Story）这个概念。一个好的用户故事需要满足 INVEST 原则，这个原则对于其它形式的任务拆分也适用。
INVEST 分别代表以下原则：独立性（Independent）、可协商性（Negotiable）、有价值（Valuable）、可以估算性（Estimable）、短小（Small）、可测试性（Testable）。