2，敏捷开发涉及到各项方方面面，就算是採用书本上的某些实践，比方用户故事，各个团队各个组织都有些定制化或改造过的做法，比方新加tech story。比方建立两张需求backlog。一张是原始需求，一张是user story。这些组织特色的实践值得归纳到团队-组织知识资产中。
3，字面意思的已定义过程（Defined Process）和经验主义过程并非矛盾的，由于经验主义过程只要有所表达，哪怕是口头表达，那么就是得到定义的过程，当然可能有些经验主义过程表达得非常是概要。而CMMI下的“已定义过程”是指“依据组织裁剪指南从组织标准过程集中裁剪得到的已管理过程，有得到维护的过程描写叙述。为组织过程资产提供过程相关的经验”。这是指项目採纳了组织过程资产并且裁剪到项目级，得到“已定义过程”，关联的术语有“project defined process"，在CMM时代，PDSP是项目计划的关键，PDSP是指Project Defined Software Process。中文经常翻译用项目自己定义软件过程。能够看到CMMI下的已定义过程与经验主义没有矛盾，反而是一致的---从组织积累的经验中选择适于项目的过程。而敏捷世界（尤其是Scrum）却对已定义过程另外有定义。在Cockburn的《敏捷软件开发》第2版中“理论的或者已定义的过程是一个理解得足够好能够自己主动化的过程（这个定义与CMMI对‘已定义的’一词的定义全然不同）（上述括号里文字来自书中）。wiki百科中的说明是The defined process control model requires that every piece of work be completely understood. Given a well-defined set of inputs, the same outputs are generated every time. A defined process can be started and allowed to run until completion, with the same results every time.
4，上下通达的收集各类改进建议并处理。
1。第一时间。
2，不推断可行性，尊重每一个改进提议提出者，鼓舞提交。
3，就算是抱怨。也值得收集，当然建设性意见更加欢迎。
4，从团队级到部门级到组织级；
5，及时处理并反馈；
6。通过改进建议来建设积累组织知识资产
5，Scrum的Retrospective将改进机会收集和处理放在团队级，对照以往的自主管理小组、QC活动而言。对软件开发团队更加详细，更有意义。
可是retrospective的经典做法会把没被选中的建议舍弃。我建议收集全部retrospective会议上提出的建议。
6。改进建议应当利用开放式的条目化状态管理工具（诸如缺陷管理工具，Jira, Mantis, Sharepoint列表，VSTS工作项）来收集跟踪处理。
Word和Excel既不方便跟踪状态，也不方便多人协作。鼓舞不只在组织级利用工具管理改进建议。并且在团队级和部门级都值得这样做。
7，建设可反复的标准培训。典型的课程有“敏捷概述”，“Scrum实施”（假设选择Scrum），”Scrum Master指南“，可能的课程有“TDD”，“持续集成”。“风险管理”。“用户故事指南”等等。
作者：张克强
--
Blog 从高效过程到卓越结果 http://blog.csdn.net/zhangmike
新浪微博 http://t.sina.com.cn/zhangkeqiang