码迷,mamicode.com
首页 > 其他好文 > 详细

团队和流程

时间:2020-03-26 23:19:57      阅读:118      评论:0      收藏:0      [点我收藏+]

标签:自己   aos   流程   培训   建模   oss   mini   info   订单   

团队和流程

软件团队的模式

一窝蜂模式Chaos Team

一个欢乐而随意的团队模式,员工没有明确的分工,大家一起追逐和解决一个突然出现的问题。

主治医师模式Chief Programmer Team

这样的软件团队中,有首席程序员,他负责处理主要模块的设计和编码,其他成员从各种角度支持他的工作。

明星模式(Super-star Model)

这种模式就是主治医师模式运用到极致的模式,在这里明星的光芒盖过了团队其他人的总和。

社区模式(Community Model)

社区一般都有很多志愿者参与,每个人参与自己感兴趣的项目,贡献力量。社区不意味着随意,成功的社区项目有很严格的代码复审和质量控制。

业余剧团模式(Amateur Theater Team)

在这样的团队中,每个人会挑选不同的角色,下一个项目中这些人也许会换一个完全不同的角色类型。每个人在团队中听从一个中央指挥的安排。一般这种模式会出现在培训等业余的环境中,但是在竞争性比较强的团队中不会存在完美的民主氛围。

秘密团队(Skunk Work Team)

这种秘密状态开发的好处是团队内部有极大的自由,没有外界的干扰(介绍项目、听从指示等),一般这样的团队拥有独特的使命,往往能够发挥超高的效率完成看似不可能的任务。

特工团队(SWAT)

这样的团队由一些有特殊技能的专业人士组成,负责解决一些棘手又紧迫的问题,如安全性服务团队。

交响乐团模式(Orchestra)

当某个软件处于稳定成长阶段时,很多的开发团队就会采用这种模式,该模式下的各成员各司其职,负责的部分各不相同,而且每个成员专门处理类似的问题,大家都很专业,由指挥统领全局。

爵士乐模式(Jazz Band)

与交响乐团相比,该模式的成员职责不固定,不专门处理类似的问题,没有统一的指挥,各自即兴发挥。这种模式强调个性化的表达,强有力的互动。

功能团队模式(Feature Team)

很多开发团队采用这种模式,每个小组内具备不同能力,负责不同部分的同事们平等协作,共同完成一个功能。

技术图片

官僚模式(Bureaucratic Model)

这种模式出现于大机构的组织架构,几个人报告给一个小头目,几个小头目再汇报给上一级。这种模式成员之间不仅有技术方面的合作,还有组织上的领导关系,因为团队不同难以绩效评估,导致很多无谓的算计。

技术图片

开发流程

写了再改模式(Code-and-Fix)

通常出现在一窝蜂团队模式,不需要准备太多,大家上来就写代码,写不出来就改,也许能改好,当面临只用一次的程序或某些演示程序时,这个方法是有用的。

技术图片

瀑布模型(Waterfall Model)

这个模型是从其他成熟行业,如建筑工程,借用来的,这些“硬”行业的产品一旦大规模生产,要再返回去修改就非常困难,这个模型就描述了这种单向的、不可逆的生产过程。

这种单向的模型局限性很大,温斯顿指出在设计大型系统时,应该同时完成相邻步骤的回溯,解决上一阶段未能解决的问题:

技术图片

温斯顿还指出要让产品成功,最好把这个模型走两遍,先有一个模拟版本,在此基础上收集反馈,改进各个步骤,并交付一个最终的版本:

技术图片

他也提到在该模型中文档的重要性,如下列几种文档:

技术图片

这种模型在软件工程实践中的局限性在于:

1、软件生产过程中各步骤之间是分离的

2、回溯修改很难甚至不可能,但是实际开发中回溯需要时时回溯

3、最终产品直到最后才出现,但是软件的客户,甚至软件工程师本人都需要尽早知道产品的原型并试用

当出现下列情况时,也可以采用瀑布模型:

1、产品的定义非常稳定,产品的正确性非常重要,需要每一步的验证

2、产品模块之间的输入输出定义稳定

3、团队成员很熟悉使用的技术

4、负责各步骤的子团队分属不同的机构,或在不同的地理位置,不可能做到频繁交流

瀑布模型的各种变形

生鱼片模型,这种模型的各相邻模块像生鱼片那样部分重叠,解决了各步骤之间分离的缺点:

技术图片

子瀑布模型,它解决了各子系统之间进度不一,技术要求不同,需要区别对待的问题:

技术图片

该模型的缺点时最终测试难度大,且没有解决最终产品最后出现的问题。

统一流程RUP

统一流程Rational Unified Process把软件开发的各个阶段整合在一个统一的框架中。要完成一个复杂的软件项目,团队的各种成员要在不同阶段做不同的事情,这些不同类型的工作在RUP中叫做规程(Discipline)或者工作流(Workflow),各阶段工作如下:

1、业务建模Business Modeling:它用精确的语言(通常是UML)把用户的活动描述出来,这个工作流的结果通常是用例(Use Case)

2、需求:分析软件系统要提供的功能,功能有什么约束条件,如何验证功能满足了用户需求

3、分析和设计:设计系统,包括有什么子系统、模块以及它们之间的关系

4、实现:按照计划开发出组件,然后搭建可执行的系统

5、测试

6、部署:生成最终版本并将软件分发给用户

7、配置和变更管理:负责管理各阶段产生的各种工作结果,要记录修改人员、修改原因、修改时间等属性

8、项目管理:负责平衡各种可能产生冲突的目标,管理风险,克服各种约束

9、环境:向软件开发组织提供软件开发环境,包括各种工具

RUP把软件开发分为几个阶段,一个阶段的结束称为一个里程碑(Milestone)每个阶段内可能有几次迭代,这样就能比较灵活的完成任务,这样的阶段有4个:

1、初始阶段:分析软件系统大致的构成,大致的成本和预算、系统风险、系统与外部系统的边界。该阶段完成后项目会达到生命周期目标(Lifecycle Objective)里程碑。

2、细化阶段:建立健全体系结构、编制项目计划,为项目建立支持环境、创建开发案例、创建模板并准备工具。该阶段完成后项目会达到生命周期(Lifecycle Architecture)里程碑

3、构造阶段:团队开发出所有的功能集,并经过各种测试验证,构造阶段结束后项目会到达初始功能(Initial Operational)里程碑,此时的产品版本也被称为beta版

4、交付阶段:此时团队工作的重点是确保软件能满足最终用户的实际需求,交付阶段可以有迭代(beta1、beta2),根据用户的反馈不断的完善调整。该阶段结束后项目到达产品发布(Product Release)里程碑。

RUP驼峰图:

技术图片

老板驱动的流程(Boss-Driven Process)

这种模式下开发流程实际上是由行政领导主导,或直接由公司的老板推动的。这种模式可能会出现在软件团队未成熟的时期,也有可能是因为软件订单的获得不是靠技术,而是靠人脉。这种模式下,领导对许多技术细节都是外行,领导的权威影响了自由的交流和创造。

渐进交付的流程(Evolution Delivery)、MVP和MBP

渐进交付这种模式比较接近于迭代式开发流程,当需求和架构基本明确后,软件团队进入了一个不断演进的循环中:

技术图片

MVP(Minimum Viable Product)流程的核心是把产品最核心的功能用最小的成本实现出来,然后快速征求用户意见,这样就不至于拖了很久弄好第一版,结果用户没有购买意愿的尴尬局面。MVP的思想和渐进交付类似,但是它更强调用户的反馈。

MBP(Maximal Beautiful Product)是与MVP相对的一种模式,它把产品最全、最美的形态都展现出来,一举征服用户。

TSP的原则

优秀的模式和流程都有一些共同点,这些共同点抽象总结为TSP(Team Software Process)原则:

1、使用妥善定义的流程,流程中的每一步都是可重复、可衡量结果的

2、团队中的各个成员对团队的目标、角色、产品都有统一的理解

3、尽量使用成熟的技术和做法

4、尽量收集数据,并利用这些数据来帮助团队做出理性的决定

5、制定切合实际的计划和承诺,团队计划要由负责具体执行的角色来定(而不是从上级而来)

6、增加团队的自我管理能力

7、专注于提高质量,争取在软件生命周期的早期发现问题,做全面而细致的设计工作

团队和流程

标签:自己   aos   流程   培训   建模   oss   mini   info   订单   

原文地址:https://www.cnblogs.com/yinyunmoyi/p/12578174.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!