1.1 FDD特征驱动建模

广州软件开发过程中常常使用的以下敏捷开发方法：
Feature
Feature（特征）是一个基本的开发单位，是（FDD）项目中的一个增量，是指用户眼中最小的有用的功能，可以在很短时间内实现（一般在两周之内）。
 
FDD中的角色
1. Domain expert(s) ：领域专家
2. Chief Architect(s) ：首席架构师
3. Chief Programmer(s) ：主程序员
 
Feature Team一般由Domain expert ，Chief Programmers，Class Owners组成，一个Chief Programmers可以带领多个Class Owners。

2.3.1基本流程

FDD方法包括5个过程，其中的按照功能设计和构建是反复的迭代过程。
 
图 7 FDD基本流程
Ø 开发整体模型
        这是FDD开始一个项目的初始工作，在主设计师的指导下，带领领域专家和开发小组成员一起工作。主要是收集系统的功能需求，然后使用四色原型进行域建模。
 
图 8 四色原型
Ø 构建功能列表
这个过程确定所有用于支持需求的功能。由领域专家和开发小组进行功能分解。根据领域专家对领域的划分，将整个领域分成一定数量的区域（主要功能集），每个区域再细化为一定数量的活动，活动中的每一步被划分称为一个功能，形成具有层次结构的分类功能列表。
Ø 计划功能开发
项目经理、开发经理和开发小组根据功能的依赖性、开发小组的工作负荷以及要实现的功能的复杂性，计划实现功能的顺序，完成一个功能开发计划。它提供了对项目的高层视图，让业务代表了解功能开发、测试和发布日期，以便业务代表和部署小组能够计划交付哪些功能的日期。
Ø 按照功能设计
    项目经理和上一阶段指定的各个功能集的主要程序员一起对功能进行详细设计。同时在域模型的基础上进行分析、设计，得出分析模型、设计模型。由于一次设计并不全面，因此也可以直接进入设计模型。根据设计的结果制定出项目的里程碑。这里会有一个设计评审的环节。本阶段的成果应该包括了：详细设计、项目里程碑计划等。
Ø 按照功能构建
    按照设计进行编码实现，由程序员实现各自负责的类。在代码完成后有必要的组织代码复查、评审。在测试和检查通过后检入到配置管理库中进行构建。
    
第5和第4 阶段是一个迭代的过程，迭代周期一般为2个星期。这样经过不断的迭代，不断的实现功能集中的功能。每一个里程碑的时候进行评估、回顾。并考虑下一个里程碑 的继续，直到最后项目的完成。
 

2.3.2最佳实践

Ø 领域对象建模
是对象分解的一种形式，主要包括构造类图，用于描述问题领域中重要对象的类型及其相互关系，为系统设计提供了一种整体框架，使得系统可以按照特征迭代增量地进行开发。
Ø 按照特征开发
    按照一组小功能、对客户有价值的功能列表进行开发并跟踪过程。FDD将需求问题分解成可以解决的小问题，对每个问题分解为分层列表的功能需求，即特征。然后，开始设计并实现每一个特征。一旦系统的功能特征被标识以后，它们通常在FDD方法中用于驱动和跟踪开发过程。
Ø 类（代码）拥有权
FDD规定每一个类都有一个指定的人/角色负责类代码的一致性、性能和概念的完整性。FDD方法采用的开发技术是面向对象，类定义一个单一的概念和实体，最合适作为最小的代码分配要素，代码的所有权即为类的所有权。
Ø 特征小组
FDD把类即特征分配给一个确定的开发者。由于一个特征的实现会涉及到多个类及其所有者，因此，特征的所有者（特征组长）需要协调多个开发人员的工作。特征小组与开发小组类似。但有一个重要的区别：特征小组的组长更像是教练而不是超级程序员。
Ø 审查
指的是检查软件错误的复审方法，这是FDD确保软件设计和代码质量的一个关键技术。审查将开发小组和FDD以主程序元为主的结构完美地结合起来，这种混合是一种新型的开发方式。
Ø 定期构建
定期地取出已完成功能的全部源代码和它所依赖的库、组件，组成完整的可以运行的系统。构建增加功能的基线，确保总是有一个可以运行、向客户演示的软件系统，可以使客户观察到系统开发的进度和实现的功能是否是需要的。
Ø 配置管理
一个FDD项目只需要保证对完成的代码文件最新版本的确认和历史追踪。根据开发软件的复杂性，分析制品、设计制品以及测试用例、测试脚本等也应该受控于版本控制。
Ø 可视性进度报告
项目成员应该根据完成的工作向各级管理报告工作进度，FDD提供了一个简单、低开销地收集准确和可靠项目信息的方法，提供了大量直观、直接的报告样式，向项目所有相关人员报告项目进度。

3.腾讯敏捷研发框架——TAPD

用简单的公式表示为:TAPO=f{FDD(需求分析/建模);Scrum(敏捷过程模型);XP(实践方式)}

3.1迭代计划

在项目启动的时，项目组会制定一份5项目计划6，主要是进行项目的阶段划分，确定重大的里程碑等。以后在每个迭代中，产品人员就会根据当前的项目情况以及用户的反馈来对项目计划中的某些需求进行分解细化，初步确定下一迭代的任务。在下个迭代开始时，开发人员，产品人员通过IPM会议将本迭代的任务明确下来，并制定本迭代的详细计划，采用故事卡来记录本迭代要完成的特性。

迭代考虑的因素	解释
项目紧急程度	即一个功能是不是用户当前非常需要的，如果是，则会尽量在早期迭代中实现
功能点大小	确保选择的功能点可以在2-3周内完成，对于大的功能点，需要再进行分解细化
影响人群	优先选择大量用户的共同需求，对于个性化的需求，可以在以后完善时实现
围绕主题	每个迭代要实现的特性，尽可能围绕一个主题

采用故事卡记录每个迭代的任务，可以很清晰的描述单个任务，但是任务之间的关联性不好表达，该如何处理这个问题的呢?
在项目初期规划的时候，就会画一幅网站地图，该地图很好的描述了产品各个功能间的关系，在每个迭代的任务明确后，产品人员就会在网站地图中将本迭代要做的功能标识为红色，这样，大家就可以从网站地图上清晰的看出本迭代要实现的功能间的联系了。
 
应对需求变更
需求变更或有了新的需求时，如果随时加入本次迭代或者在本此迭代内立即调整，尽管从短期来看满足了用户的需要，但是会造成开发团队对计划的不尊重，制定计划时就会不认真，因为大家知道这个计划是不会按时完成的;相反，如果严格执行计划，大家就会严肃对待这个计划，并尽最大努力保证计划的按时完成，这样，团队成员就会信任这个计划，并将其作为自己的一个短期的目标，提高了大家的工作积极性和团队的士气。因此，对于每个新需求要纳入下一个迭代。由于每个迭代的周期都比较短，一般是以周为单位的，所以基本都可以满足到用户的需求。
 
迭代任务确定后的工作分工
在确定了本次迭代的任务后，并不急于分工，而是先进行工作量的评估。对于一个任务，每个人给出自己评估的工作量，如果评估的很不一致，则表明大家对需求的理解还不是很到位，此时，产品人员再解释一下需求，然后进行第二轮的评估。一般情况下，经过2-3轮的评估，大家对这个任务所需要的工作量就可以达成一致了。当每个任务的工作量估计都确定后，由开发人员自己挑选任务。
先评估工作量再分配任务，可以使工作比较透明，任务分配也比较公平。同时，由于大家共同确定工作时间，而不是某个人拍脑袋，也提高了计划的准确性。而且，因为每个人都要评估所有的任务，也使得大家对项目更加了解，团队合作也更加顺畅。

3.2需求开发

需求开发是将大模块拆分为各项特性，根据特性的大小再拆分为各个功能，达到对整体需求的细化;根据各项特性的重要性定出优先级;按照优先级和关联性将各个功能分配到每次迭代开发中，让开发人员清晰的知道各个特性需要实现的时间。
定期对各项特性表进行维护，拥抱变化，实时根据具体需求来调整远期计划，并及时通知到开发的相关人员。特性列表里面明确列出了当前版本所包含的特性，下个迭代所包含的特性，以及后期对特性的规划。
 

3.3 UI设计

互联网应用软件中，UI(User Interface)设计是最重要的环节之一。TAPO提出了:1)需求沟通2)需求确认，3)评审，4)合作，5)质量和进度五个方面进行UI设计。
1) 需求沟通
产品经理召开常规需求分析会议，用邮件通知到UI人员。UI设计人员有选择参与需求阶段的讨论，参与需求评审，频繁与产品经理沟通，保证每周有一次固定沟通。产品经理可能会参与交互稿件的原型(简易原型)设计，后期设计师再参与修正。同样，设计师为了更好的为产品服务，也参与需求讨论，提出问题。双方在需求前期也会有工作的交叉。
2) 需求确认
产品经理尽量避免在迭代周期内变更需求;产品经理在需求确定后提交给UI的需求
需包括时间、质量、优先级等方面的要求。
UI人员在收到需求后一天内反馈UI实现进度，如有困难或问题及早与产品方沟通。
3) 评审
视觉/交互设计评审采用公开和扁平化的方式进行。评审工作一次完成，尽量避免多层的评审
4) 合作
产品经理在UI资源紧缺情况下，可自行完成交互设计原型，后期再由交互设计师再进行修正。必要时，产品经理完成交互原型设计。
UI设计人员充分了解需求，可对产品经理提出有建设性的建议;UI设计人员在产品经理需要时候提供设计工具和其他相关培训。
在UI资源紧缺情况下，为避免进度受到影响，产品经理可以在需求说明中自行完成交互设计原型，后期再由交互设计师再进行修正。
UI设计与产品经理的充分沟通和相互信任。产品经理和UI设计人员双方在长期的合作中达成默契和信任，是项目能够顺利推进的首要前提。
5) 质量和进度控制
对于一般质量要求的UI，优先保证项目进度。为配合项目计划时间加快进度，可适
当降低质量。

3.4 每日晨会

晨会上每个人的发言不超过3分钟为宜，整个会议15分钟为宜。这是按照5人团队来制定的。如果团队人数超过5人，甚至达到10人、20人，那么建议成立两个团队。
Scrum的晨会是站立着开的，一方面是为了不让会议拖沓，另一方面也是为了让大家注意力集中（如果坐下肯定有人会顺便打开电脑，然后开始上网）。
在每天的晨会上，团队成员每人都叙述对昨天的工作做一个总结，总结由Scrum Master记录在白板上。
总结的内容包括：
1. 工作完成的情况。只需要选择以下状态即可：未开始、正在开发、已完成。
2.工作遇到的难点（如果未按时完成）；工作中值得注意的地方（可以是系统框架的体会、业务的特殊性、封装了哪些公共功能等）。
3.今天要做什么（如果昨天的工作已完成）。
 
当某人遇到问题的时候，其他成员如果有解决办法或者建议，那么可以“举手”，但不用说出解决的办法，由Scrum Master安排两人结对编程。
后来也做了一些改进比如为了让成员的参与程度更强一些，现在多数团队就会采取每个人轮流主持的方式;还有些分布式团队会通过即时通信软件每天去交流，最后由一个人去统一输出;也有些团队采用电话会议的方式，解决效率更高效.
 

3.5 时间盒

产品的每一个迭代都有一个明确的时间盒(Time box)。在每一次迭代开始的时候会召开一次IPM会议即本次迭代的计划会议。会议中团队中的所有成员，包括:产品人员、开发人员、测试人员、项目经理等，一起去敲定本次迭代要完成的任务，一旦任务敲定下来，本次迭代就会严格按照这个去落实执行。

3.6 故事墙

故事墙(story wall)就是白板，平时工作中很多团队都会使用，这些团队会把每天开发的一些产品特征采用故事的方式在白板里面展示出来，整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目及产品特性的开发演变过程，同时也可以清晰的了解团队成员各自工作完成度的情况，在团队中营造了一种争先的工作氛围。
 

3.7 迭代总结

在每一个产品发布的时候都会有一个总结。具体的做法是，把做得好的和不好的总结出来。做得好的在下一次迭代发扬光大，做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加，包括项目的开发人员、测试人员、QA、项目经理、产品经理等，每个人都要总结他在上一个迭代中碰到了什么问题，通过便签纸的方式贴出来，项目经理实际上可以看成是Scrum Master，包括站起来总结这样一些东西，包括团队下一次迭代继续发扬什么，必须要注意什么东西，最后就会得出一个excel的文档，包括上一个迭代中出的问题和具体的解决办法。

3.8 灰度发布

灰度是一种半透明的状态，产品上线发布非面向用户全体，而是有策略有节奏地逐批放量。它是一种典型的敏捷化发布方式(集市型)，敏捷思想注重活动的全员参与，采用灰度，测试不仅是测试人员的事，逐步的放大用户群也降低了缺陷影响的范围和风险，不必对每一次非正式版的发布进行全面回归测试。通过灰度放量实现敏捷原则之一。现场客户。，让足够多的眼睛来发现缺陷和提出体验建议，建立快捷的用户反馈搜集渠道，快速响应，投入到下一次发布。区别于传统的测试观，灰度强调早发布、常发布、注重用户反馈。
灰度发布首先在资源上灰度放量形态缓解了发布环节人力的疲惫和紧张;在质量上降低了发布风险，缩小风险影响的范围;在业务上可以拉近与用户的距离，密切关注体验反馈，明确产品方向。

3.9 用户参与

如何加强用户的参与度，这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析，分析用户在这个产品上整个体验的过程是怎样的，通过后台的数据可以看到整个活动的曲线。
同时用户参与(CE一Customer Engagement)也可以通过一些科学的手段去保证，包括市场调研、用户研究、数据挖掘、产品体会等，这就是通过一些对用户反馈、用户观察的工具去配合对用户做研究。比如一个卖家用户研究，经常会由产品经理和用户研究人员深入到用户工作现场，通过观察用户一天或者一段时间的产品使用行为，同时配合一些相关的工具进行科学分析，最终得出产品在交互设计方面的改进建议。