构建之法-5-团队和流程

构建之法-5-团队和流程_第1张图片
团队和流程.png

只有一个好的团队,才能做成大事。
——鲁迅没说过

5.1 非团队和团队

提出了一个问题:什么是一个团队?随便凑一伙人算是团队吗?这个说不好,但是一个好的团队应该会满足两个特点:

  1. 团队有一致的集体目标,团队要一起完成这目标。一个团队的成员不一定要同时工作,例如接力赛跑。(王屋村搬砖的“非团队”成员则不然,每个人想搬多少就搬多少,不想干了就结算工钱走人。
  2. 团队成员有各自的分工,互相依赖合作,共同完成任务。(王屋村搬砖的“非团队”成员则是各自行动,独立把任务完成,有人不辞而别,对其他的搬砖人无实质影响。)

5.2 软件团队的模式

构建之法-5-团队和流程_第2张图片
软件团队的模式

每种模式都各有优劣,不同的团队可能会有不同的最佳合作模式。


5.3 开发流程

做开发总得有一个完整的开发流程。

我们在开发、运营、维护软件的过程中有很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中,叫“软件开发流程”,软件开发流程的目的是为了提高软件开发、运营和维护的效率,以及提升用户满意度、软件的可靠性和可维护性。

构建之法-5-团队和流程_第3张图片
开发流程
5.3.1 写了再改模式(Code-and-Fix)
构建之法-5-团队和流程_第4张图片
写了再改模式.png

这种模式就像小孩“过家家”一样,开发的程序用过一次就扔了,不足取。

5.3.2 瀑布模型(Waterfall Model)
构建之法-5-团队和流程_第5张图片
收集反馈并改进.png

构建之法-5-团队和流程_第6张图片
在这个模型下文档的重要性
5.3.3 瀑布模型的各种变形
  • 生鱼片模型
    这个模型解决了各个步骤之间分离的缺点,同时也带来了一些困扰—究竟什么时候上一个阶段会结束呢?

    构建之法-5-团队和流程_第7张图片
    生鱼片.png

  • 大瀑布带着小瀑布
    在这种瀑布群下,要把各个子系统统一到最后做系统测试(System Testing)的阶段,难度非常大!另外,在这样的开发流程中,用户只有到了最后才能看到结果,用户真是等不起。

    构建之法-5-团队和流程_第8张图片
    子瀑布模型

5.3.4 Rational Unified Process 统一流程(RUP)
构建之法-5-团队和流程_第9张图片
RUP的工作流(纵轴)和开发流程的各个阶段(横轴),图中的阴影面积代表不同角色在各个阶段的参与程度。由于阴影面积起起伏伏,这个图又被称为RUP驼峰图
5.3.5 老板驱动的流程(Boss-Driven Process)
  • 领导对许多技术细节是外行。
  • 领导未必懂得软件项目的管理,领导的权威影响了自由的交流和创造。
  • 领导最擅长的管理方式是行政命令,这未必能管好软件团队或任何需要创造力的团队。
  • 领导的精力有限,领导很忙时,团队怎么办?
5.3.6 渐进交付的流程(Evolutionary Delivery),MVP和MBP
构建之法-5-团队和流程_第10张图片
不断演进的evolution循环

这种流程比较像敏捷开发模式。

  • MVP(Minimal Viable Product,最小可行产品)
    把产品最核心的功能用最小的成本实现出来(或者描绘出来),然后快速征求用户意见。例如,一个社交网站已经有很多用户,都是免费的,产品团队想设计一个付费的VIP服务,MVP的做法可以是这样—在目前的用户入口页面中加一个“VIP服务”的链接,指向一个简单的介绍页面(用最小成本做出来)。观察到底有多少用户点击这个链接。如果点击量太小,那么这个VIP服务就不用做了。

用MVP的思路,团队会找出最关键、最小的功能集,快速实现,三个月就可以听到用户的反馈

  • Maximal Beautiful Product(最强最美产品,MBP)
    更像是憋大招,一下子拿出划时代意义的产品,例如iPhone,iPod。。。。这对产品团队有更高的要求。

结束

有人说,现代软件工程分为四个阶段:

和PM吵
和设计吵
和测试吵
和用户吵

你觉得应该如何避免吵架?

你可能感兴趣的:(构建之法-5-团队和流程)