标签：自己 aos 流程 培训 建模 oss mini info 订单
一个欢乐而随意的团队模式，员工没有明确的分工，大家一起追逐和解决一个突然出现的问题。
这样的软件团队中，有首席程序员，他负责处理主要模块的设计和编码，其他成员从各种角度支持他的工作。
这种模式就是主治医师模式运用到极致的模式，在这里明星的光芒盖过了团队其他人的总和。
社区一般都有很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。社区不意味着随意，成功的社区项目有很严格的代码复审和质量控制。
在这样的团队中，每个人会挑选不同的角色，下一个项目中这些人也许会换一个完全不同的角色类型。每个人在团队中听从一个中央指挥的安排。一般这种模式会出现在培训等业余的环境中，但是在竞争性比较强的团队中不会存在完美的民主氛围。
这种秘密状态开发的好处是团队内部有极大的自由，没有外界的干扰（介绍项目、听从指示等），一般这样的团队拥有独特的使命，往往能够发挥超高的效率完成看似不可能的任务。
这样的团队由一些有特殊技能的专业人士组成，负责解决一些棘手又紧迫的问题，如安全性服务团队。
当某个软件处于稳定成长阶段时，很多的开发团队就会采用这种模式，该模式下的各成员各司其职，负责的部分各不相同，而且每个成员专门处理类似的问题，大家都很专业，由指挥统领全局。
与交响乐团相比，该模式的成员职责不固定，不专门处理类似的问题，没有统一的指挥，各自即兴发挥。这种模式强调个性化的表达，强有力的互动。
很多开发团队采用这种模式，每个小组内具备不同能力，负责不同部分的同事们平等协作，共同完成一个功能。
这种模式出现于大机构的组织架构，几个人报告给一个小头目，几个小头目再汇报给上一级。这种模式成员之间不仅有技术方面的合作，还有组织上的领导关系，因为团队不同难以绩效评估，导致很多无谓的算计。
通常出现在一窝蜂团队模式，不需要准备太多，大家上来就写代码，写不出来就改，也许能改好，当面临只用一次的程序或某些演示程序时，这个方法是有用的。
这个模型是从其他成熟行业，如建筑工程，借用来的，这些“硬”行业的产品一旦大规模生产，要再返回去修改就非常困难，这个模型就描述了这种单向的、不可逆的生产过程。
这种单向的模型局限性很大，温斯顿指出在设计大型系统时，应该同时完成相邻步骤的回溯，解决上一阶段未能解决的问题：
温斯顿还指出要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本：
他也提到在该模型中文档的重要性，如下列几种文档：
这种模型在软件工程实践中的局限性在于：
1、软件生产过程中各步骤之间是分离的
2、回溯修改很难甚至不可能，但是实际开发中回溯需要时时回溯
3、最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用
当出现下列情况时，也可以采用瀑布模型：
1、产品的定义非常稳定，产品的正确性非常重要，需要每一步的验证
2、产品模块之间的输入输出定义稳定
3、团队成员很熟悉使用的技术
4、负责各步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁交流
生鱼片模型，这种模型的各相邻模块像生鱼片那样部分重叠，解决了各步骤之间分离的缺点：
子瀑布模型，它解决了各子系统之间进度不一，技术要求不同，需要区别对待的问题：
该模型的缺点时最终测试难度大，且没有解决最终产品最后出现的问题。
统一流程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驼峰图：
这种模式下开发流程实际上是由行政领导主导，或直接由公司的老板推动的。这种模式可能会出现在软件团队未成熟的时期，也有可能是因为软件订单的获得不是靠技术，而是靠人脉。这种模式下，领导对许多技术细节都是外行，领导的权威影响了自由的交流和创造。
渐进交付这种模式比较接近于迭代式开发流程，当需求和架构基本明确后，软件团队进入了一个不断演进的循环中：
MVP（Minimum Viable Product）流程的核心是把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见，这样就不至于拖了很久弄好第一版，结果用户没有购买意愿的尴尬局面。MVP的思想和渐进交付类似，但是它更强调用户的反馈。
MBP（Maximal Beautiful Product）是与MVP相对的一种模式，它把产品最全、最美的形态都展现出来，一举征服用户。
优秀的模式和流程都有一些共同点，这些共同点抽象总结为TSP（Team Software Process）原则：
1、使用妥善定义的流程，流程中的每一步都是可重复、可衡量结果的
2、团队中的各个成员对团队的目标、角色、产品都有统一的理解
3、尽量使用成熟的技术和做法
4、尽量收集数据，并利用这些数据来帮助团队做出理性的决定
5、制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来定（而不是从上级而来）
6、增加团队的自我管理能力
7、专注于提高质量，争取在软件生命周期的早期发现问题，做全面而细致的设计工作
标签：自己 aos 流程 培训 建模 oss mini info 订单
原文地址：https://www.cnblogs.com/yinyunmoyi/p/12578174.html
