瀑布 vs 迭代
传统瀑布模型
问题1
Analysis -- design – code –test – deploy
无法应对需求的变化 做出来的不是客户想要的
问题2
项目只有准时交付(代价是加班)和延期 不会有提前交付
因为项目估算是一个概率的正态分布 总是有80%的在预期内20%在预期外
由于前期定计划的时候(design) 是分模块的或是需要depending在其他功能或是项目组上
即使你早做好了也没有用 --- 浪费了提前完成的时间
20%在预期外 说明总有人会落后于计划 这是一个概率现象 无法避免 除非你加班
这就导致了项目会被整体拖慢，这就导致了为什么传统的软件开发只有60分和不及格
优点
方便规划成本
迭代开发
优点1
快速应对需求变化，提供客户最想要的功能
优点2
合理安排人员分配
不因为做的快慢有所奖惩 能有效的利用提前完成的时间，对会出现的delay加大投入
对于个人而言需要更多的互助， 不像在瀑布中每个人完成自己的模块就ok
优点3
用户能及早的参与体验 而不是在最后UAT阶段 降低风险
问题1
不方便在前期估算成本/合同等
--- 解决方式 合同中不写具体的如何实现，只写最后达到的目的
问题2 【关键】
跨部门 跨team之间的交流
由于迭代需要多批次的发布，将本来在SIT阶段任务拆分成很多个，急剧地增加了沟通的成本。
--- 解决方式 将不同team的人放在一起组成一个团队(closure function team) 消除跨team之间的沟通成本 但这也是最难实现的 而且我们不只是跨team 还跨国家 跨时区
如果解决不了这个问题 迭代开发可能会弄巧成拙
管理者
工作能力不需要很强(如果一个人能力太强 会轻视周围的人 最后弄的自己很累)
需要有包容心，让别人发挥出最好的水平，更加主动的和别人沟通
