敏捷软件需求

下半年在团队内举办了读书季活动，然而自己却没有按照计划读完书，本来想找个理由安慰自己一下，但转而一想，这也正是读书季活动的意义：给每个团队成员一点抽空读书的压力。所以趁临近假日工作压力没有那么大的时候，补一补。我们坚持做几期，做正确的事，相信会有好的结果。

不过对比其他同事写的读书笔记，内容翔实，有营养，而我写的更像是读后感了，只谈一些概要思想。

敏捷软件需求，随手从书架上拿的书，看着挺厚实。我对于这种厚厚的，同时又是外文翻译为中文的，都有些犯怵，因为翻译的人很难即是专家又是作家还是翻译家，所以行文常常很晦涩，但是这本书读下来却还行，不需要怎么坚持就能读完，大概原因可能是作者实践经验非常丰富，一些例子给人启发，导致没有那么累。

前面公司导入敏捷培训的时候，接触到的大部分的敏捷思想、实践、方法，都是关注于一个团队如何运作的，我当时其实就在考虑一个问题，多个敏捷团队之间如何管理？因为敏捷团队会非常多，N多团队如何协同来保证完成一个大的IT项目，需求如何进行管理。

这本书正可以解答上面的疑惑，作者开门见山的给出了敏捷全景图，里面就包含了项目组合、项目集和具体项目的关系，虽然这本书的主旨是谈各层面上的需求以及如何管理，但是作者丰富的经验和领域知识，会给你许多惊喜。作者可以说是以“需求”为线索，串联起了敏捷所有的活动，不仅仅是项目内的，还有项目集和项目组合的。

有一些重点觉得需要关注的：

• 每个故事都指定一个主工程师

• ATDD比TDD更容易实施

• 愿景、投资主题、篇章(epic)、特性、故事、任务

• 需求包括，功能需求，非功能需求和设计约束

• 系统用户体验的几个因素: 生产力/准确性/回忆/情绪反应

• 限制在制品，是为了提高交付速率

• 随着复杂度提高，简单性成为需要得以保持的一种本质属性

• 很多敏捷专家认为记录与回放的自动化工具过时了，不适合敏捷

• 敏捷需求收集对数据管理团队也有用，工作坊，访谈，头脑风暴等

• 对于任意复杂度的系统可以用25到50个特性进行描述

• 客户满意度的kano模型，基本特性的优化，兴奋特性和愉悦特性，线性业绩。这个对于指导我们进行需求的分类和排序有非常大的意义，避免大量无效的资源投向需求黑洞。

• 非功能需求：FURPS(FUNCTIONALITY/USABILITY/RELIABILITY/PERFORMANCE/SUPPORTABILITY)