零、引言
日前因競標項目，終於“被迫”要把公司這七年來在軟件開發流程方面的知識做一次小結，於是有了寫入標書的此文。
準確而言，這並非第一次寫，只是第一次用中文寫，早在 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）在思想上有典型的区别。
瀑布模型，顾名思义，便是“需求分析 > 设计 > 实现 > 测试 > 集成 > 维护”瀑布般、线形地完成一次软件的开发。这种模式，其实暗含了如下两点“假设”，或说“前提”：
- 需求不变：自始至终，项目需求始终是固定的、不变化的
- 认知不变：在整个开发过程中，对业务的理解和传递是一致的
在大部分项目中，尤其是 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 中估算是一项极其重要的工作，如果把用户故事（需求）比作小球，每个迭代中团队的容量比作杯子，我们只有在估算出了小球的大小之后，才能做好计划，才知道每个迭代中能放入多少小球。
在估算用户故事工作量大小的时候，我们一般遵循如下步骤，在一次估算会议中：
- 由 PL 负责为开发团队讲述每个用户故事及其细节
- 每位工程师据此提出自己的问题或看见的风险，PL 相应作答
- 当充分交流完毕，每位工程师提出自己的估算
- 若估算时间结果差距较大，估算最高者与最低者需各自陈述理由，但不作任何辩论。若有未明问题，PL 作进一步解答，无现成答案则记录下来，待与客户沟通。
- 在听取意见后，每位工程师再次给出新估算
每个用户故事如此进行一至数轮的估算后，将得到相当合理的值，小球的“大小”至此清晰。
该做法的好处是：
- 促进整个团队对需求的理解，知识被“分布式”存储到每个人的脑海里，这在计划执行过程中，若遇到成员病假、变动时，其他成员可以立即有上下文承接其工作——这是很好的风险控制手段之一。
- 发挥团队智慧，发现未知问题。同样，由于团队成员的技能各有所长，探讨的过程中，非常容易从不同角度发现 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 同样有如下应变步骤稳健支持：
- 与客户充分沟通，定义变更范围，估算资源变动，明晰容量剩余
- 若资源并无增加，那将在迭代内自然消化
- 若资源增加，当前剩余团队容量不足，则优先考虑将其他未开始或相对次要的需求移出当前迭代，为吸纳变化“腾出空间”
- 若此变动必须发生，且当前迭代需求亦必须完成，此时可清晰告知客户将加班“扩容”，以及相应的成本增加
五、小结
简言之，整个 ADP 实作过程中，与客户的充分交流贯穿始终。
我们一方面以上一迭代已发布的产品，辅以经验，让客户对未来保持充分的能见度；另一方面，以即时到位的交流，让客户随时知悉项目进展、资源动态，能以完备信息做出最佳决定，直至项目成功发布。
我们相信：
- 鲜活的交流 优于 死板的列表
- 与客户一同探索并掌握未知 优于 以有限能力试图预知一切
- 做出客户一直满意的、成长中的产品 优于 按规格书验收完却毫不满意的最终产品
No comments:
Post a Comment