项目管理

-------------------------------------------------- 
风险 概率 影响 
-------------------------------------------------- 
规模估计过低 60% 严重的 
交付期限太紧张 50% 严重的 
用户需求变化频繁 75% 严重的 
技术达不到预期效果 30% 轻微的 
质量保证体系的措施实施不利 60% 严重的 
软件体系结构设计不合理 40% 灾难性的 
人员流动 30% 严重的

 

 

Agile——敏捷开发，作为CMM神话崩溃后被引入的一套新的软件开发模式，这几年来被广泛引起关注，并被寄予厚望。敏捷开发在其他业界的应用是否理想不得而知，但以下总结了我所在公司的敏捷开发试验，希望可以达到管中窥豹的目的。

敏捷开发宣言——
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。

以上的宣言比较抽象，基于该理念，以下是ThoughtsWork咨询公司的推崇的n个敏捷开发实践：
Iteration
迭代开发。可以工作的软件胜过面面俱到的文档。因此，敏捷开发提倡将一个完整的软件版本划分为多个迭代，每个迭代实现不同的特性。重大的、优先级高的特性优先实现，风险高的特性优先实现。在项目的早期就将软件的原型开发出来，并基于这个原型在后续的迭代不断晚上。迭代开发的好处是：尽早编码，尽早暴露项目的技术风险。尽早使客户见到可运行的软件，并提出优化意见。可以分阶段提早向不同的客户交付可用的版本。
IterationPlanningMeeting
迭代计划会议。每个迭代启动时，召集整个开发团队，召开迭代计划会议，所有的团队成员畅所欲言，明确迭代的开发任务，解答疑惑。
Story Card/Story Wall/Feature List
在每个迭代中，架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。每个Story应该可以在最多1个星期内完成开发，交付提前测试（Pre-Test）。当一个迭代中的所有Story开发完毕以后，测试组再进行完整的测试。在整个测试过程中（pre-test，test），基于Daily build，测试组永远都是每天从配置库上取下最新编译的版本进行测试，开发人员也随时修改测试人员提交的问题单，并合入配置库。
敏捷开发的一个特点是开放式办公，充分沟通，包括测试人员也和开发人员一起办公。基于Story Card的开发方式，团队会在开放式办公区域放置一块白板，上面粘贴着所有的Story Card，按当前的开发状态贴在4个区域中，分别是：未开发，开发中，预测试中，测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card，更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。
在开发人员开始开发一个Story时，ta需要找来对应的测试人员讲解Story功能，以便测试人员有一致的理解，同时开始自动化系统测试脚本的开发。
Standup Meeting
站立会议。每天早上，所有的团队成员围在Story Wall周围，开一个高效率的会议，通常不超过15分钟，汇报开发进展，提出问题，但不浪费所有人的时间立刻解决问题，而是会后个别沟通解决。
Pair Programming
结对编程是指两个开发人员结对编码。结对编程的好处是：经过两个人讨论后编写的代码比一个人独立完成会更加的完善，一些大的方向不至于出现偏差，一些细节也可以被充分考虑到。一个有经验的开发人员和一个新手结对编程，可以促进新手的成长，保证软件开发的质量。
CI/Daily Build
持续集成和每日构建能力是否足够强大是迭代开发是否成功的一个重要基础。基于每日构建。开发人员每天将编写/修改的代码及时的更新到配置库中，自动化编译程序每天至少一次自动从配置库上取下代码，执行自动化代码静态检查（如PCLint），单元测试，编译版本，安装，系统测试，动态检查（如Purify）。以上这些自动化任务执行完毕后，会输出报告，自动发送邮件给团队成员。如果其中存在着任何的问题，相关责任人应该及时的修改。
可以看到，整个开发组频繁的更新代码，出现一些问题不可避免。通过测试部又在不停地基于最新的代码进行测试。新增的问题是否能够被及时发现并消灭掉，取决于自动化单元测试和系统测试能力是否足够强大，特别是自动化系统测试能力。如果自动化测试只能验证最简单的操作，则新合入代码的隐患将很难被发现，并遗留到项目后期，形成大的风险。而实际上，提升自动化测试的覆盖率是最困难的。
Retrospect
总结和反思。每个迭代结束以后，项目组成员召开总结会议，总结好的实践和教训，并落实到后续的开发中。
ShowCase
演示。每个Story开发完成以后，开发人员叫上测试人员，演示软件功能，以便测试人员充分理解软件功能。
Refactoring
重构。因为迭代开发模式在项目早期就开发出可运行的软件原型，一开始开发出来的代码和架构不可能是最优的、面面俱到的，因此在后续的Story开发中，需要对代码和架构进行持续的重构。迭代开发对架构师要求很高。因为架构师要将一个完整的版本拆分成多个迭代，每个跌倒由拆分成很多Story，从架构的角度看，这些Story必须在是有很强的继承性，是可以不断叠加的，不至于后续开发的Story完全推翻了早期开发的代码和架构，同时也不可避免的需要对代码进行不断完善，不断重构。
TDD
测试驱动开发。正如上面讲的，迭代开发的特点是频繁合入代码，频繁发布版本。测试驱动开发是保证合入代码正常运行且不会在后期被破坏的重要手段。这里的测试主要指单元测试。

敏捷方法反思：
自己参与的敏捷开发项目总的来说不是很成功，这可能也是业界遇到的通病：
1、对于全新的软件，在项目早期测试人员就参与并实现自动化测试脚本，但实际上软件的界面等非常不稳定，导致测试人员返工的工作量很大。
2、对于全新的软件，资料人员过早参与，后期返工工作量大，原因同第一点。
3、自动化系统测试工作量大，测试人员投入大量的精力在使测试自动化起来，而没有足够的精力放在真正的测试软件的功能是否正常。即便是这样，自动化系统测试脚本也多流于形式，测不出深层次的问题。
4、代码动态检查工具执行不理想，流于形式。没有人对Purify有深刻的理解和应用经验，报告中查出来很多告警，但不知如何消除。
5、由于快速搭建原型，没有在架构上进行严谨的设计，导致后期一直堆砌代码。
6、异地开发模式下无法实现快速构建、快速交付，团队普遍感觉很疲惫。
7、敏捷开发不提倡加班，但实际上不管是CMM还是Agile哪一种开发模式跟是否加班都没有必然联系。

 

 

 

 

 

瀑布模型的过程已经在大量软件实践中被证明是不可行的，但在实际开发工作中，仍然被大量的使用。我认真思考这个问题，可能有一个因素导致了这种落后的方法仍在继续，那就是老板的因素。

 

这个原因就是瀑布模型太简单。

       瀑布模型有多简单，只要一个接触过软件开发的人能说完整个过程：

       需求分析-->概要设计->详细设计->编码实现->测试

       这个过程是完全按找软件的各个工作内容来划分开发阶段的。

       这个模型的告诉大家，当软件测试完了，软件就开发完了。最爱听这句话的人是谁？当然是老板了。老板要的是什么？老板要的是管理，要的是成本控制，按照瀑布模型做东西，老板好理解，目标可以看的见，他觉得比较省心。

 

        实际上这里忽略了一个最大的问题，需求的不确定性和软件本身的复杂性。没有一个构架师或系统分析师能在一开始把软件的过程中的所有问题都想清楚的。软件过程中产生的问题是在软件开发的推进过程中发现并解决的，而且软件本身的有些设计也是在软件开发的过程中验证的。所以确定了软件的开发过程中需要适时作出调整，这个调整就是敏捷开发中说的适应变化。

             瀑布模型的结症在这里，无法适应变化，当软件发展过程中，发现需求要变更，就需要重新评估一下设计，然后更改已经实现的代码，当然还要通知测试需求测试用例，这样一来需求变化的过程才处理完成，这个过程没有错，只要产生的变化，任何软件的开发方法都是这么做的。问题是这么一来就打乱了我们原定的计划，打乱了我们看似美好的瀑布过程，甚至有的软件根本不知道该怎样该才好，本来觉得良好地设计变成了垃圾。错在哪里？错不在变化，错不在需求，错在计划，错在瀑布模型，瀑布模型是管理者心中的乌托邦，渴望而不可及。

      因为你总是想在事情开始的时候把一切都考虑到，结过最后的结果是什么都有问题。

      于是人们提出了不同于瀑布的开发方法，其中很好的一种实践就是敏捷方法。其实敏捷根本不是什么系统的一套过程规范，敏捷是一种思路，是一种解决问题的思路。在我理解敏捷的思维有一下几条：

       1、整体思维，不拘泥于细节，就是最需求和做设计的时候，追求一个整体的结果，而不是设计界面元素，通信细节这些琐碎的内容。所以敏捷方法的整体需求文档和设计文档都比较简练，有时候思维结果还很抽象。不过早的进入细节，是这里边最重要的思想。这个思维活动的结果是整体关系，如果探讨细节那一定是在验证整体。

       2、小版本计划，大家都说小版本迭代，其实过程的开始时一个小版本计划，在一次迭代过程中，项目还是瀑布模型的。当然这就不可避免的又产生了开头想不清楚，中间产生了变化的问题，但项目计划比较小。所以也更可控。

       3、构架师的作用，这个方法中，构架师的整体把控能力及其重要，一切都在变，没有一个优秀的构架师敏捷就变成了混乱。

 

       4、最郁闷的人：敏捷方法中，最郁闷的就是老板了，因为他要花更多的时间来跟踪项目。