初探敏捷

带着个小团队学习敏捷运作也有三个多月了，目前执行了近八轮迭代，对比以前的瀑布式运作，感觉运作差别比较大的主要是每日晨会、测试前移、持续交付；

第一次尝试敏捷，就在我们今年的部门重点项目w上试点，确实有点突然。因为敏捷运作对于我们来说是一种全新的项目运作方式，按正常试点流程，应该会先在一些小项目上进行完整实验之后，再铺开推广会比较合适些。

故事编写

         由于项目规模比较大，所以业务进行需求梳理的工作量非常之大，而且进度要求很紧张，完整梳理下来，光史诗级故事就有近二十个，再把这些大故事细分后，小故事就轻易上百了，而且还是感觉故事梳理得不够细致，很多子故事缺少细致推敲。

这一块究其原因，主要还是在于功能照搬了X信应用，而不论其功能是否适合于公司具体办公业务场景。只做了简单界面功能copy，并未去深究功能背后的具体操作场景与业务价值。这样就导致需求描述过于粗浅，很多描述上很简单的故事，待到进行纳入迭代计划、准备进行开发时才发现后面隐藏的巨大工作量，例如第二轮迭代时，一个简单的选好友建群故事，就耗费了我们队内一个开发主力前后约两个星期的工作量，直接导致计划内其他故事无法交付。

         其实，需求梳理这一块，敏捷运作跟以前的瀑布式模型并没有太大本质性区别，该做的业务需求分析还是得做，只是交付成果由以前的use case变成了故事，将边界条件与前后置条件变成了验收条件，但终究都是为了满足业务功能实现、实现业务价值。特别是业务操作场景与重点验收条件都是绝对不能少的。

迭代计划安排

从这几轮迭代计划排定的经验来看，迭代计划的安排一定只能有产品开发负责人来制定，业务、SM都只能做局部故事优先级排定参考，因为他们往往并不懂具体开发，无法为每个故事的开发工作量做出准确评估。

在故事梳理过程中发现，各大史诗故事其实很容易就会对应上将来要开发的各大功能模块，每个史诗故事下的子故事都是为了实现此功能模块需要满足的具体业务处理场景的功能。

因此迭代计划的安排，首先应该从最高优先级的史诗故事开始着手，而且每轮迭代的交付范围应该尽可能控制在一两个高优先级史诗故事内；

而对于优先交付的史诗故事，各个子故事也会有实现优先级的排序，而此优先级排定需要从多个维度考虑——价值、风险、成本、依赖性。这四个维度中，需求方理所当然会优先关注价值，而SM自然会优先考虑交付风险与交付成本。而至关重要的依赖性，只能是由产品开发负责人PO来识别，因为前两个角色缺乏高层次的开发技能，并不能有效识别出故事实现的核心难点。

在大多数情况下，价值与风险是比较容易识别的，而成本与依赖项是隐藏比较深的，特别是依赖性，一来是有赖于实现方案是否已经明确，二来有赖于故事梳理是否足够简单。越是复杂的故事，潜藏的依赖关系越多，就越难以识别。

最为一名SE，笔者自然重点关注依赖项识别。对于依赖项的识别，最重要的还是要提前做好基础方案预研工作，而且此类工作做得越细致越好。每个子故事，在纳入迭代计划前，都必须是已经提前做好充分技术方案预研了的，都应该是零交付风险或低交付风险的。如果故事的实现方案还不清楚，最好不要纳入下轮迭代计划。

其次，在制定迭代计划时，提前将故事实现的开发任务进行分解，也有利于依赖项的识别。而且提前进行开发任务分解，也有利于系统的架构层次设计，有利于功能模块的职责分离，有利于开发出松耦合、可重用的代码。

在移动应用开发过程中，比较常见的开发分工方式是纵向切割式，即按界面功能维度来为不同开发人员划分开发任务，每个开发人员负责某个（或某几个）功能，这个功能的实现包括从界面呈现到底层数据处理全流程的开发。这种分工方式下开发出来的代码，各个业务模块功能看似独立，其实高度耦合、可重用度极低、重复代码非常多。体现在我们IOS开发中的情况就是：每个视图View界面的业务逻辑也全部写在其ViewController中，导致这个ViewController类无比复杂，既要处理界面事件响应，又要处理业务逻辑，还要管理网络请求与数据持久化。

其实，如果以前做过web开发，特别是比较深层次的java开发，这种情况就会好许多。一个app，即使再简单，也是可以遵照mvc架构设计思想进行大的功能分层的，而且需要特别说明下的是，对于mvc中的“C”，也就是控制器层，并不就是指所有业务处理逻辑都要放在viewController中处理，而应该根据具体业务处理复杂度来分析，看看是否有进一步进行功能分离的可能。

 

         对于迭代计划的制定，scrum是很注重交付承诺的，计划一旦制定，就要求一定要保证交付，因此交付范围在一个迭代周期中是尽量不会发生变化的。对于此，笔者进行了一种尝试，除了制定一个正常的交付范围，另外再划定一定数量的冲刺故事（我们一般叫i*.5版本）。冲刺故事作为一种正向激励，鼓励大家进行高效率开发。而冲刺故事的范围与工作量都是很有讲究的，一般情况下，每个开发人员，应当尽量只安排一个冲刺故事比较好，而且这些故事，都应该是预计会划归到下一轮迭代中的高优先级故事。

         对于迭代计划中故事数量的安排，主要还是要根据故事开发工作量与组内成员开发能力来定，从我们组的交付能力来看，我们全组主要开发人员是4人，其中开发主力2人（我作为subpo，主要负责技术方案预研、重点问题支持、开发进度跟踪），每轮迭代交付故事数在15~20之间，总点数正常是在60~80之间（目前是以半天为1个点进行评估）。

 

结合验收条件评审的迭代计划会

         在迭代计划制定完后，每轮迭代的第一周的周一，是我们组内本轮的迭代计划会议的召开时间，这一天上午主要是将本轮迭代故事的分工，开发人员领到故事后，将其编写在故事卡上，每个故事卡只写一个故事，格式是：正面顶行写故事标题，右侧划出1/4列宽来记录开发责任人、预估点数、开始日期，左侧3/4的空间用来填写故事详情，底部留两栏用来做故事实现的进度跟踪，卡片背面也有大用处，用于编写开发人员自己识别到的重要处理逻辑与验收条件。

         开发人员将故事编写完后，我们会召集业务需求方、测试人员一起来参加我们组内的迭代计划会，这个会议一般在周一下午举行，其实是一次需求澄清会，由测试leader主导，各开发人员主讲。会议形式是站会，将故事列表投影到白板上，按照故事列表中的排列顺序，每个故事的开发责任人站到白板前，为大家讲解他对于这个故事的实现思路与考虑到的验收条件（包括业务场景、边界条件、呈现细节等）。在此过程中，对于需求的任何理解偏差或者疑问，都由业务需求人员进行讲解。对于开发人员考虑到的验收条件，由测试人员来进一步阐明，以明确此故事的完整业务场景与标准验收条件，供开发人员与需求人员来评审验收条件是否合理并完整。

         在这个过程中，因为每个故事的实现方案是由开发人员自己经过思考形成的，所以在具体开发实现过程中执行遵照程度会比较高，而且因为会议有需求人员参与，基本能保证需求实现的正确性。而且，在开发人员讲解方案实现的过程中，很容易提前识别出隐藏需求或工作量，很有利于需求的进一步细化以及交付范围的修正。

         在这一个会议中，对会议效果影响比较大的是需求的明确程度与测试人员验收条件描述的准确性——需求不明确，会使大家无法聚焦真正的功能实现，产生大量低效率的释疑性质的讨论，浪费会议时间；而如果验收条件编写不清晰，会使开发人员无法获知到真正的最终交付标准，无法明确功能交付深度。

         这个会议建议以站会的形式进行，这样更能突出效率，一般应尽量控制在一个小时以内，如果每轮迭代故事太多或者交付能力尚不太确定，可以将这个会议分两次举行，每周的周一举行一次，这样能更精确地掌控开发进度，识别交付风险。

而会议主持人尽量是测试leader，而不要是subPO或者SM，因为后两者主导的会议，往往意味着交付压力，会给开发人员制造无形的精神压力，不利于他们思路得自由发挥、尽抒己见。这一点，在我们前四轮迭代计划会的举办过程中，已经得到了充分验证。

 

每日晨会

         每日晨会是SCRUM的一大标志性特色，也是以站会形式举行，由PO主持，测试leader也需要参加，时间尽量控制在十分钟以内。会议大致过程是，开发团队成员都围在故事墙前，按顺时针顺序挨个说三句(或段)话，内容仅限于回答这三个问题：昨天你做了什么？今天准备做什么？开发过程中遇到了哪些问题？

这个会虽然简短，但是对PO的要求其实是很高的，首先是要引导大家聚焦具体工作事项，说话内容一定要聚焦到每个人具体开发的故事上面；其次要把控好会议时间，对于遇到的问题，一定不能发散讨论，会上只做问题收集，会后再挨个单独沟通。

在我们组内的会议中，笔者还进行了一种尝试——弱化PO角色导向，强化团队观念。因为晨会是由PO主导，大家就会不由自主地把晨会当成工作汇报会议，而且汇报对象就是PO自己。

其实这种导向是很错误的，每日晨会不应该是工作汇报会议，而应该是进度知会与问题求助会议，而且应该是个人对团队贡献值的知会。所以开会时笔者会尽量表现得比较随意，会前开开小玩笑，尽量避免站在第一个发言的位置，尽量让开发人员面向大家发言，为此笔者甚至会故意来回走动——去故事墙上贴标签或者埋头记录故事进度——努力达到这种效果，让大家当我不存在，至少当成一个普通团队成员来对待。

 

结对编程

在敏捷运作过程中，笔者还进行了结对编程的尝试，但是目前来看，效果并不如预期那么明显——能力弱的员工并没有预想中的那样得到很快的能力提升。

这一方面可能还是因为团队运作时间还不够长，而成员能力成长是一个长期过程。不过相关经验，笔者也在此简单说下：就是能力强弱员工两两配对，去做同一功能模块的相近的开发工作，能力强的员工开发核心功能，能力弱的员工开发周边功能，通过开发过程中的交流与经验指导，以期能在较短时间内使能力弱的员工的开发能力得到一定提升。

Code Review

另外，对于新员工能力培养，进行CodeReview是一种很好的方式。不过Code Review也是一件很讲究技巧性的活，如果组织不好，也就会变成走形式，并不能真正发现问题、提升代码质量、提高新员工开发能力。

在笔者这个项目中，Code Review也做得不够好，代码审查的力度太粗，虽然发现了一些功能方案思路上的问题，但是具体代码中的问题，依然没能有效识别出来。

之前组内有6位员工，每周进行一次三小时的代码QC，每次QC两名同事的代码。从后来的代码开发质量来看，这样的频率还是太长了，最好能每两天甚至每天即进行一次QC，就直接将这两天里各人开发的代码。