在博文视点专家团里看到篇很不错的文章，转帖过来与大家分享。
= 白话过程改进 =
'''Easy into "Software Process Enhancement'' '''
*
文档属主: [:ZoomQuiet:周琦]
* 文档版本:
* v0.7~080114 完成主体内容,发布初稿
* v0.6~080110 完成实例内容
* v0.5~080101 创建文档,设定大纲
软件过程改进，这是我现在的工作范畴，但是什么是
软件过程改进？真不好说；可以复杂
的说很多，也可以简单的一句话定义，得时都无法恰当的传达过程改进的
活动全部；
那么简单的将我心目中靠谱的软件过程给大家白话一下吧.
== 导入 ==
简单的说，过程改进就是在持续的改进活动中将软件
开发过程优化到顺畅高效的状态。
就业界的专业分析统计，软件
项目中，能够按时按质完成的几乎没有，15%的
项目将完全失
败，75% 以上的项目都有延期现象，
软件项目的
管理真这么困难嘛？
其实优秀的
项目管理模型一直在我们身边，不信？
== 实例 ==
16:00 小莉接到小周电话，说晚上父母要来视察，得准备好晚饭
17:00 小莉空出时间电话确认了一下人数，小周父母的饮食习惯，花5分钟，确认了晚上的
菜谱，并想好要买什么来补充
19:00 小莉在超市采购时接到小周电话，说临时追加小周妹妹小琪也来家宴，立即調整菜谱
追加了只乌骨鸡
19:15 小莉到家，先淘好米，将饭闷上；然后开始洗菜；优先处理好汤料，大火先滚着；
19:30 小周到家，先帮忙试味，确认汤的咸淡是否吻合小周父母的习惯，然后小火开始煲着
；
19:45 从邻居家借了个老式高压锅，将乌骨鸡剔出胸肉，其余剁块儿扮料入锅焖香辣鸡；
焖鸡的时候，准备好凉拌菜，果盘入冰箱；
20:00 小周家人到达，先出冷菜和香辣鸡; 坐定后，取鸡胸肉切丁和预留的黄瓜丁爆炒鸡丁上
桌;
20:45 米饭，鸡汤同时好，盛饭盛汤；
21:00 出果盘,聊天,评论今天小莉的手艺.
22:00 小周完成清理，结束家宴;
这就是一次非常完整的项目过程！
=== 理解 ===
小莉 ～ 项目经理+开发团队+配置管理
小周 ～ 客户代表
小周家人 ~ 客户
电话通知准备晚饭 ～ 项目
需求
电话确认饮食习惯 ~ 需求分析
确认了晚上的菜谱，并想好要买什么来补充 ~ 项目计划
临时追加小周妹妹小琪 ~ 需求变更
調整菜谱追加了只乌骨鸡 ~ 变更管理
先淘好米，将饭闷上；然后开始洗菜；优先处理好汤料，大火先滚着 ~ 项目预研
小周到家，先帮忙试味 ~ 测试先行，单元测试，快速迭代
邻居家借了个老式高压锅 ~ 模块复用
焖鸡的时候，准备好凉拌菜，果盘入冰箱 ~ 模块化开发，并行开发
坐定后，取鸡胸肉切丁和预留的黄瓜丁爆炒鸡丁上桌 ~ 集成测试，beta版本发布
米饭，鸡汤同时好，盛饭盛汤 ~ 集成迭代,小版本发布
聊天,评论今天小莉的手艺 ~ 结项,经验总结
小周完成清理，结束家宴 ~ 版本发布
多么完整的开发团队哪，在6小时内完成了一次项目从设计到开发到交付的所有事儿！
== 浅说 ==
好吧，世界上效率和复杂度同时最好的，真的应该算厨房
系统了，
这一系统每天三次,都得完全成功,否则,就给人非常不愉快的体验(食不好的人,脾气都大)……
而其中的确涉及到了同软件工程完全对等的各个层面的控制和管理。
不过，拿作饭来完全比对软件开发工程，只是想说明，软件管理/过程改进其实不是什么非
常非常精尖的不可理解的活动，
而是恰恰相反，是我们日常就可以接触到的，非常平常，朴素的活动：沟通和协调！
软件项目之所以，复杂，正是复杂在沟通的层面和涉及的团队的巨大的不同；
但是长久以来，我们又不自觉的使用了越來越复杂的沟通渠道和协调方式来对应同样越來
越复杂的软件项目；所以，形成了各个软件公司都完全不同，但是同样越发复杂的项目管
理过程；
其实，只要作到有效的沟通～任何人可以在最短时间内获得任何团队内外的关键信息；
有效的协调～任何问题／矛盾都可以在第一时间发觉并协商
解决，那么，这个软件项目就
很难失败！
但是，想作到如同作饭一般顺畅无碍，软件组织还是有很多人为的障碍要跨越的。
不过，既然是白话过程改进，那么，我就不深入探讨软件过程改进的各个方面，
而是比照我们日常可以接触得到的最优化过程~烹调进行畅想过程改进的目标:
##状态（我的个人体验）过程改进乃是开始催生可促生靠谱的人的组织!
== 白话 ==
回想烹调技艺的精进,最困难的有两方面:
1. 高级食材的获得~龙肝凤髄不是任何人都可以随意获得来给自个儿老爸老妈作菜的!
1. 对温度/作料/时间的把握~五味均衡那是厨艺入道后的境界,不是我们斗升小民可以轻易达到
的!
比照软件开发,反而是最容易的:
1. 高级食材 ~ 那么多自由软件/开源软件的源
代码是公开的,是那些聪慧通明的先辈的智慧结晶,
媲美龙肝凤髄的高级材料可以任我们程序员使用！
1. 对温度/作料/时间的把握 ~ 那么多设计模式,测试框架,都是以往大师们的心血凝成,我们可以随
意使用!
但是,烹调最简单的部分:
* i. 将食物作熟~保证营养容易吸收
* ii. 烹调出好味道来~这么多调味品,而且对于食客的口味了解也非常简单,中国8大菜系基本可
以够定9成9的国人了
* iii. 和帮厨的协同好~就是将食材洗净切好扮好淹好...不要太easy 哪,按照方便的形式整理好就
成
比照软件开发,却是最最最困难的:
* i. 将食物作熟~项目成功按时完成,这简直是每个项目经理的噩梦,不论准备的多充分总有意外
从而导致项目失败或是部分失败
* ii. 烹调出好味道来~让
用户认同我们的软件产品?!
用户是恶魔!
想讨好所有用户是根本不可能的!最可恨的是:用户根本不知道自个儿需要什么,只有你作出来
成品后才好整似睱的挑刺,反正用户永远正确有理...
* iii. 和帮厨的协同好~ERP/CRM/CMM无数项目管理系统,
流程,规范,想干的是什么?就是想让同作一份
菜的厨房师傅们协同好哪! 可是结果呢?
=== 所以 ===
所以,过程改进,就是要将软件开发过程,逐步改进的象烹调一样顺畅自如!
保证项目完成::
* 这有关风险和变更管理,因为每个项目的时间/人力/物力是有限的,而且市场/用户永远在快速变
化
* 如同菜价,食客的心情口味一直在变动
* 那么,如何在有限的时间/人力/物力中,将项目完成?
* 控制好时间和目标而已:
* 如果时间不够就减少
功能点
* 如果功能点增加了,就放弃不重要的功能点
* 如何控制好? -- 加强信息反馈!
* 如同掌勺:及时精确的获得当前菜价,结合时令掌握受众的口味偏向,就可以在已知预算中选择
合理的配菜,处理出讨巧的菜式,获得认可
确保用户认可::
* 这有关需求和配置管理,用户的需求应该从一开始就被完好的追踪和管理
* 如果象家常菜制作过程中,受众本身就掺合了制作,随时可以提出改进
建议并迅速得到实施
* 这产品就成了开发和用户共同完成的作品,如何不得到认可?
确实团队協同::
* 这有关版本和发布管理,软件每个部件的来由都应该得到精确的
记录和追踪
* 如果象作菜过程中,每个人都明白最终结果和自个儿处理的食材的标准
* 那么,协同的团队中,每个人都应该明白所有相关成员的作用,控制范畴,自个儿的功能点上下文,
任何问题都明确和谁商定可以得到正确的回复
== 小结 ==
目标来自预估;风险源于变化!
进度受限资源;任务支撑进度!
态度决定质量;效率受制管理!
我期待的成熟团队可以作到
拥抱变化::
* 想想作菜时任何一次失误~比如不小心盐洒多了~立即得到修正(多放点水/糖)
* 我们不能禁止变化,所以,一定要适应它,但是一定要以最小成本和时间来处理掉它,否则,总会在
一个月圆之夜它会变身成人狼将你的一切工作破坏光的!
良好心态::
* 战略上轻视,战术上重视
* 老毛的经验是绝对实用的!
* 在过程改进中,调整心态,开放思想,重视自个儿的劳动成果,为了确保自个儿的代码有最多的人
关心和使用,不惜一切代价!
认清未来和现在哪个重要?!::
* 不要幻想未来一下子可以得到一个神奇的运行良好的产品
* 一个朴素的但是可以稳定运行的产品永远比一个华丽的但是错误百出的产品要好上万倍!
--
'''过程改进乃是开始催生可促生靠谱的人的组织!
作者：
http://wiki.woodpecker.org.cn/moin/ZoomQuiet
金山维基内部文章
http://wiki.rdev.kingsoft.net/moin/EasyIntoPEG
使用CC内容许可
http://creativecommons.org/licenses/by-nc-sa/3.0/
