Sunday, May 13, 2012

华美汉盛 Adaptive Development Process 简介

零、引言


日前因競標項目,終於“被迫”要把公司這七年來在軟件開發流程方面的知識做一次小結,於是有了寫入標書的此文。

準確而言,這並非第一次寫,只是第一次用中文寫,早在 07 年底 08 年初便在公司內部 wiki 寫過一篇長達 10 屏的英文版:


此後零零星星還有一些英文寫作,隨着內部培訓的需要散落各處。直至去年年底開始給 BTV 的開發團隊講課,秉承一貫白板筆加嘴巴的風格,回來後也只懶惰地寫了篇《軟件開發流程第一講: 開宗明義 (綱要)》;後續課程見聽衆不催,便偷偷一併欠下不寫……

此次競標,終得靜心坐下,把往事悉數回顧,遂成此文。

注意——流程管理如一切精密之物,思想萬般,細節無數;此文僅覆蓋本人經驗所至,自覺精要部分,其他深入如商務分析、需求管理、開發日常(SCM/Unit Test/Code Review, etc.)、質監全程、發佈管理(Release Management)、系統運維(Operation)等等均未覆蓋。待某年某月空閒或“被迫”(again)再考慮動筆!

應標所需,寫作時遣詞造句略有發揮,但撥開辭藻,一切堅若磬石。予晚輩參考,與同行切磋,求前輩指正。

(另,競標成功,一切的努力都沒有白費:)

yihua
5/13/2012 晚



(Update: 前傳《軟件開發流程第一講: 開宗明義 (綱要)》)

一、背景


华美汉盛自成立伊始,针对软件项目需求多变、节奏快速之特点,一开始便采用了轻量应变的敏捷开发方式。脱胎 Scrum,历经数载,我们最终沉淀下了自己的流程:ADP - Adaptive Development Process,应变式开发流程。

敏捷的 ADP 锤炼得尤为适合移动互联网、后 PC 时代、云端服务的应用开发。

此类项目的突出特点:
  • 海量受众:各种受众,多样设备,时时有你未曾想到的需求
  • 市场多变:业界风向,竞争对手,处处有你需要响应的挑战

这为工程以稳健为要义的技术团队带来了难题——我们如何能够一方面聆听市场、迅速响应,另一方面在工程实施上却不能因此没了章法、乱了阵脚。

ADP 便是华美汉盛针对这一难题给出的答案。

二、思想


敏捷的 ADP 与非敏捷的瀑布模型(waterfall model)在思想上有典型的区别。

瀑布模型,顾名思义,便是“需求分析 > 设计 > 实现 > 测试 > 集成 > 维护”瀑布般、线形地完成一次软件的开发。这种模式,其实暗含了如下两点“假设”,或说“前提”:
  1. 需求不变:自始至终,项目需求始终是固定的、不变化的
  2. 认知不变:在整个开发过程中,对业务的理解和传递是一致的

在大部分项目中,尤其是 Web 2.0 时代以来、移动和互联网的兴起,大量面向最终消费者的应用开发项目,这些假设都是不成立的:一来用户们会不断要求新的功能,二来我们自己对原有需求的理解也会在现实中不断深化或演进。

针对上述传统瀑布模型无法解决的问题,ADP 的核心解决思想便是:承认变化,拥抱变化

如果说瀑布模型是以一种“万能之神”的“可预知”的态度,试图以有限的能力、以预知和冻结的方式控制、消除变化,最终获得工程层面的“稳健”;ADP 则是以回归“能力有限的人”的、务实应变的“适应变化”的态度,承认变化、拥抱变化、响应变化,这便是 ADP 精髓。

但,承认、拥抱、响应变化决非毫无章法地胡乱变化。我们有一整套完备的工程角色、流程步骤,使得一切变中有稳,精细可控。形象地概括起来,ADP 就像是“一系列的小型瀑布”,即:
  • 整个项目周期被分割成许多的迭代,每个迭代交替时允许吸纳充分的变化
  • 迭代内则是一个需求“冻结”的“小瀑布”,以保证迭代计划好的工作可以被稳健执行

三、项目管理实践


3.1 角色


在一个项目中,通常客户作为产品负责人(Product Owner),同时,ADP每个项目配备如下角色:
  • 业务分析员(BA,Business Analyst):负责与客户沟通、采集、管理所有业务层面的需求
  • 质监(QA,Quality Assurance):对产品质量及流程执行完备性进行监控;负责在业务需求驱动下,形成测试用例的设计、计划、执行,缺陷报告、跟踪、管理
  • 项目主管(PL,Project Lead):桥接业务与工程的关键角色,负责驱动项目、资源管理,这包括确保客户、BA、QA 与工程团队对需求的理解之一致,确保资源被合理估算和调度,确保计划被稳健执行,确保风险被有效预见并管理
  • 开发团队:负责完成各项具体开发任务

3.2 需求仓库


项目伊始,BA 便会与客户紧密交流,从商务角度,一来采集客户需求并准确归档成用户故事(User Stories),二则协助客户分析、判断、做出正确选择。

BA 采集到的需求(用户故事)并不会立即进入工程团队的“生产线”,而是会在需求仓库(Product Backlog)中被管理,它成为一个有效捕获用户各色(新的、变化的)需求、同时又不会影响工程团队当前工作的“缓存池”。

BA 管理该缓存池的过程中,将不断与客户一同明晰需求、判定轻重缓急,始终保持准确反映客户需求、项目进度的状态。

随后,PL 将协同 QA 及工程师从该池子中,依优先级选出需求,估算、计划、开发、测试并最终迭代式、增量式地发布产品。

3.3 团队容量


团队“容量(capacity)”在 ADP 中为重要概念,它将指导我们对资源作出准确判断,进行有效配备。

“容量”意指:在给定人数、时间的前提下,一个团队可利用的人时便是定数,能完成的工作量亦是。例如,每人每天工作 8 人时,一个两人的团队,分配一周,其“容量”便是:8 x 2 x 5 = 80 人时。

PL 在做计划时便需要根据团队容量决定一个迭代里可以完成几个需求;在发生变化致工作量增长时,需根据剩余容量决定响应方式。

3.4 估算


ADP 中估算是一项极其重要的工作,如果把用户故事(需求)比作小球,每个迭代中团队的容量比作杯子,我们只有在估算出了小球的大小之后,才能做好计划,才知道每个迭代中能放入多少小球。

在估算用户故事工作量大小的时候,我们一般遵循如下步骤,在一次估算会议中:
  1. 由 PL 负责为开发团队讲述每个用户故事及其细节
  2. 每位工程师据此提出自己的问题或看见的风险,PL 相应作答
  3. 当充分交流完毕,每位工程师提出自己的估算
  4. 若估算时间结果差距较大,估算最高者与最低者需各自陈述理由,但不作任何辩论。若有未明问题,PL 作进一步解答,无现成答案则记录下来,待与客户沟通。
  5. 在听取意见后,每位工程师再次给出新估算

每个用户故事如此进行一至数轮的估算后,将得到相当合理的值,小球的“大小”至此清晰。

该做法的好处是:
  • 促进整个团队对需求的理解,知识被“分布式”存储到每个人的脑海里,这在计划执行过程中,若遇到成员病假、变动时,其他成员可以立即有上下文承接其工作——这是很好的风险控制手段之一。
  • 发挥团队智慧,发现未知问题。同样,由于团队成员的技能各有所长,探讨的过程中,非常容易从不同角度发现 BA、PL 未曾想到的问题或细节,这样 BA、PL 便能及时与客户沟通,提前消除可能的风险。

3.5 项目计划


在 PL 得到团队给出的各个用户故事之估算大小后,辅以每迭代为定量的团队容量,计划便轻而易举了。PL 要做的仅仅是把已知大小的小球——用户故事,按优先级填满一个杯子——迭代容量即可。随后,将该计划草稿提交客户审核,在得到客户批准后执行即可。

当然,再好的计划,执行过程中同样会面临各种变化,重要的是 PL 必须全程保持对团队进展的把握,对新出现情况的理解,以及与客户保持顺畅的沟通,这样才能确保应变及时、客户知情、结果满意。

另外,有了“小球”填“杯子”的概念后,计划执行过程中进行需求变更管理也变得非常清晰明了。迭代过程中需求变更通常有两种情况,一是新需求的加入,而是原有需求的变动。需要把握的原则就是——任何一种变动都将带来小球“大小”的变动,在杯子定容(不加班,不加人)的前提下,必然对其他已放入的小球产生影响。PL 的重要职责就是确定此次变更带来了多少新的工作量,据此与客户沟通,以确认是把新工作量计划入下一迭代,或是“挤出”当前迭代的其他小球。

四、开发流程


一个典型的开发流程如下——

4.1 迭代零


经 BA 采集整理,PL(独自或带领工程团队)估算出优先级最高的需求的大小(单位:人时,例如完成需求 A 需要 8 人时),形成迭代一计划草稿,经客户审核,确保在迭代一开始前得到客户批准即可。

4.2 迭代一


以下三个角色、三条“线索”将“并行”发生:
  • BA 继续开发需求,与客户交流沟通,进一步提升项目的未来能见度(visibility)
  • QA 开发针对本迭代需求的测试用例(test case)
  • 开发团队执行迭代一计划,开发本迭代需求功能

在开发团队这条“线索”上逐渐开发完毕一些功能时,QA “线索”也逐渐开发完毕测试用例;这两条“线索”将在内部版本上“交汇”——开发团队把迭代内的阶段性成果发布到测试环境中,QA 便可以立即开始测试、报告缺陷,开发团队相应修复;直至迭代结束前,开发团队将发布一个经 QA 充分测试的版本给客户。

在迭代其间,项目组长亦将挑选经由 BA 定义清楚的需求,同时组织开发团队估算后,生成迭代二计划草稿,提交客户审核,收集反馈,确保在迭代二开始前获得客户批准。

4.3 迭代二至迭代 N


同迭代一
  • 需求团队与客户开发下一迭代需求
  • 开发团队执行迭代计划,经 QA 测试并发布
  • 项目组长与客户生成迭代三计划

如此周而复始至项目结束。在此模式下,我们拥有了:
  • 充分的应变调整机会——客户永远可以在当前迭代规划下一迭代的调整
  • 稳健的工程实施节奏——已计划的需求将被冻结并准时发布,确保阶段性目标被不断达成

“最坏情况”下,客户只需等待一个迭代的周期,便能让变动的需求进入。如遇特殊情况,必须当前迭代调整,ADP 同样有如下应变步骤稳健支持:
  1. 与客户充分沟通,定义变更范围,估算资源变动,明晰容量剩余
  2. 若资源并无增加,那将在迭代内自然消化
  3. 若资源增加,当前剩余团队容量不足,则优先考虑将其他未开始或相对次要的需求移出当前迭代,为吸纳变化“腾出空间”
  4. 若此变动必须发生,且当前迭代需求亦必须完成,此时可清晰告知客户将加班“扩容”,以及相应的成本增加

五、小结


简言之,整个 ADP 实作过程中,与客户的充分交流贯穿始终。

我们一方面以上一迭代已发布的产品,辅以经验,让客户对未来保持充分的能见度;另一方面,以即时到位的交流,让客户随时知悉项目进展、资源动态,能以完备信息做出最佳决定,直至项目成功发布。

我们相信:
  • 鲜活的交流 优于 死板的列表
  • 与客户一同探索并掌握未知 优于 以有限能力试图预知一切
  • 做出客户一直满意的、成长中的产品 优于 按规格书验收完却毫不满意的最终产品

No comments: