标签：决定 strong color 模型 事先 代码 兴趣 质量 类型
一、非团队和团队
1.非团队：只是一群乌合之众，临时聚集在一起。
2.团队：①有一致的目标。
②成员不一定要同时工作。（如接力跑）
③成员有各自的分工，互相依赖合作，共同完成任务。一个人的工作对另一个人有影响。
二、软件团队的模式
适用于不同的人员和需求的团队的各种形式。
1.一蜂窝模式：（比较混乱）
就是大家一哄而上去抢。可能是一个欢乐而随意的模式。
2.主治医生模式：（1主多从）
有一个主刀的人，还有其他帮助他的人。
也就是有一个首席程序员负责主要模块的设计和编码，其他人从各种角度支持他的工作（后备程序员、系统管理者、工具开发、编程语言专家、业务专家）
3.明星模式：（是主治医生模式的升级版，就是明星能有团队意识）
明星的光芒盖过了团队其他人的总和。
*明星也是人，也会有错误，如何让团队的利益最大化，而不是明星的利益最大化，如何让团队的价值在明星陨落之后仍然能保持？
真正有巨大成就的明星都能意识到团队的作用。
说实话，不是很明白主治医生模式和明星模式的区别？
4.社区模式：（人多，分工合作，保证质量，不随意）
社区由很多志愿者组成，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。
好处：众人拾柴火焰高，但是也要每个人均匀的分工合作，并且提高质量。
并不意味着“随意”。
5.业余剧团模式：（每次每个人的角色不同，有导演）
在每一个不同的项目中，每个人挑选的角色也不同。
且每个人在团队中听从一个中央指挥（导演）的指导和安排。
6.秘密团队：（神秘）
项目在秘密状态下进行，别人不知道他们具体在做什么。
好处：团队内部有极大的自由，较高的热情，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示等）。
7.特工团队：（有特殊技能的专业人士）
由一些有特殊技能的专业人士组成，负责解决一些棘手而又紧迫的问题。
现在还包括专门做网站安全性服务的团队。
8.交响乐模式：（种类多，统一，执行力强）
家伙多，种类丰富。
各司其职。
有统一的套路（谱子），同时看指挥。
曲子练习了多次，重在执行。
9.爵士乐模式：（个性化，互动，创意）
同交响乐模式似乎有些相对。
没有统一的谱子。
没有现场指挥。
即兴发挥。
强调个性化的表达，强有力的互动，对变化的内容有创意的回应。
10.功能团队模式：（能力不同，平等，交流频繁）
具备不同能力的同事们平等协作。
在一个功能完成后又重新组合，和别的角色一起去完成下一个功能。
没有管理和被管理的关系。
小组内的交流比较频繁。
11.官僚模式：（领导和被领导）
几个人报告给一个小头目，几个小头目报告给中头目，依次而上。
成员之间不光有技术方面的合作和领导。
组织上有领导和被领导的关系。
跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。
三、开发流程
一群人一起做软件开发的方式方法。
1.写了再改模式：（适用于小场面的一些程序）
就是不管三七二十一，先写了再说，如果有问题就再改动不断的进行修改。
好处：不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。
eg.只用一次的程序，看过就扔的程序，一些不实用的程序。
坏处：在要写到比较有实际用户、解决实际需求的软件时就不适用了。
2.瀑布模型：（单向、不可逆）
硬件行业中：产品一般遵循：【分析->设计->实现（制造）->销售->维护】的流程。
且一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。
在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题。
要让产品成功，最好把这个模型走两边，先有一个模拟版本，在此基础上收集反馈，改进各个步骤，并交付一个最终的版本。
用户的及早介入、讨论、复审是很重要的。要让顾客正式的、深入的、持续的参与到项目中来。
软件行业中的局限性：
①各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来。
②回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯。
③最终产品直到最后才出现。但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用。
适用范围：
①产品的正确性非常重要，需要每一步的验证。
②产品模块之间的接口、输入和输出能很好的用形式化的方法定义和验证。
③使用的技术非常成熟，团队成员都很熟悉这些技术。
④负责各个步骤的子团队分属不同的机构，或在不同的的地理位置，不可能做到频繁的交流。
3.瀑布模型的各种变形：
1）生鱼片模型（各相邻模块像生鱼片那样部分重叠）：
解决了各个步骤之间分离的缺点，但也有问题：上一个阶段什么时候结束的？
2）大瀑布带着小瀑布（步步嵌套）：
解决不同子系统之间进度不一，技术要求迥异，需要区别对待的问题。
要把各个子系统统一到最后做系统测试，用户只有到了最后才能看到结果。
4.统一流程（RUP）：
从瀑布模型开始的各种模型都有一个共同点：重计划，重事先设计，重文档表达。
团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程或工作流。
包括：业务建模。
需求。
分析和设计。
实现。
测试。
部署。
配置和变更管理。
项目管理。
环境。
RUP四个阶段：
①初始阶段。分析软件系统大概的构成。（开始阶段）
②细化阶段。分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。（具体的去做）
③构造阶段。开发出所有的功能集，把功能集成为经过各种测试验证过的产品。什么是功能集？？？
④交付阶段。确保软件能满足最终用户的实际需求。
5.老板驱动的流程：（ 由行政领导主导或是公司老板驱动。）
原因：老板的能力决定了一个团队是否能获得订单。
在大型企业内部，软件功能往往由行政体系来决定。
有些老板比一般人更懂市场和竞争。
软件团队尚未成熟。
缺点：领导对很多技术细节是外行。
领导未必懂得软件项目的管理很有可能太过权威性。
领导管理是行政命令。
领导精力有限。
6.渐进交付的流程：（开发->发布->听取反馈->根据反馈做改进）不断的循环
（直到）软件最后完成： 时间到了，钱花光了，用户满意了（或是不满意不继续给钱）。
但有问题是：产品团队得到用户的反馈太晚了。
MVP(最小可行产品，最小功能集)：
把产品最核心的功能用最小的成本实现出来，然后快速征求用户的意见。
指导思想与渐进交付相似，但是更强调更早获得用户反馈，为此可以在产品完成之前就发布，
也强调产品的核心价值，为了突出核心功能，不考虑辅助功能。
MBP(最强最美产品)：
对用户的需求了然于心，或者产品团队比用户更了解用户的需求。
7.TSP（Team Software Process）的原则：
①流程中的每一步都是可以重复、可以衡量结果的。
②各个成员对团队的目标，角色，产品都有统一的理解。
③尽量使用成熟的技术和做法。
④尽量多的收集数据。
⑤指定切实的计划和承诺。计划要由具体执行的角色来制定。
⑥增加团队的自我管理能力。
⑦专注于提高质量。
标签：决定 strong color 模型 事先 代码 兴趣 质量 类型
原文地址：http://www.cnblogs.com/zqqqj/p/6819356.html
