week 1 

1.Project Management Methodologies

1.1 waterfull 

参考：https://blog.****.net/ningmengban/article/details/75059086

 1.1.1 介绍：

   这种模式有明确的阶段活动，阶段顺序固定，自上而下、相互衔接，形如瀑布流水逐级下落。

瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。    

    其过程是上一个阶段的工作完成输出结果并通过审核，才能“流动”到下一个阶段；否则返回前面，甚至更前的阶段活动。基于这种模型太过强调文档的作用，过程太理想化，在项目运用过程中，它以下的弊端就很突出：  

   各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

   单一流程，不可逆，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

   测试只是其中一个阶段，缺乏全过程测试思想。早期的错误可能要等到开发后期的测试阶段才能发现，发现问题越晚造成代价越高。

   在软件需求分析阶段，完全确定用户的所有需求是比较困难的，不能应对需求不断变更的项目

1.1.2 优点

• 为项目提供了按阶段划分的检查点。

• 当前一阶段完成后，您只需要去关注后续阶段。

1.1.3 缺点

• 需求很明确的软件开发项目；

• 在开发时间内需求没有或很少变化；

• 分析设计人员应对应用领域很熟悉；

• 低风险项目（对目标、环境很熟悉）；

• 用户使用环境很稳定；

• 用户除提出需求以外，很少参与开发工作。

1.2 agile

参考：https://johng.cn/soft-dev-mode-comparison/

相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

特点：及时应对需求变更

软件敏捷开发宣言中提出了以下12个原则：
1、持续、尽早交付有价值的软件以满足客户，是我们优先要做的首要任务。
2、拥抱需求变更，甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。
3、频繁交付可执行的软件，从几周到几个月，交付时间越短越好。
4、在整个项目过程中，业务人员和开发人员必须每天在一起工作。
5、激发每个团队成员的积极性来打造项目。为他们提供所需的环境与支持，并且信任他们可以完成工作。
6、在一个开发团队内部最有效的传递信息的方式是面对面的交流。
7、可执行的软件是进度的首要检验对象。
8、敏捷过程倡导可持续发展。赞助商，开发人员和用户应该尽可能保持一致的步伐。
9、保持关注先进的技术与设计会增强敏捷性。
10、尽量用艺术化来简单阐述未完成的工作是很有必要的。
11、最好的架构，需求，和设计出自于自我组织管理的团队。
12、每隔一段时间，回顾反思如何让团队变得更高效，并相应地调整其行为

模型优点
1、迭代快，开发周期短；
2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档；
3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队；
4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗；

模型缺点
1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通；
2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。

 

1.3 prince 2

1.3.1 介绍

每一个流程都详细标出关键的输入、输出和具体目标及要执行的活动，这为计划偏差提供了自发的控制。依靠严格的监控，项目在控制和组织的方式下得到执行。

参考：https://zh.wikipedia.org/wiki/PRINCE2