缔造 实验四 团队作业1：软件研发团队组建

项目	内容
课程班级博客链接	班级博客
这个作业要求链接	作业要求
团队名称	缔造
团队的课程学习目标	1、组建软件项目研发团队； 2、完成实验任务； 3、培养合作意识，提升软件开发效率
这个作业在哪些方面帮助团队实现学习目标	1、通过成立软件项目研发团队，使得软件开发效率更高； 2、通过团队企业微信群的建立联系。
团队博客链接	团队博客

1、队名：缔造

2、团队成员组成，按以下列表形式给出，个人博客地址需加超链接，在备注中标记团队组长（PM）。

成员学号末五位	成员*名	个人博客地址	备注
10134	*英杰	链接	PM
10133	*永军	链接
10118	*敬博	链接
10136	*艳强	链接

3、成员风采：介绍每位队员的风格、擅长技术、编程兴趣、希望承担的软工角色（文档、开发、测试、PM等）、一句话宣言；阅读《现代软件工程——构建之法》第7章、第17章，理解MSF的9点基本原则的团队成员绩效。

|成员姓名|风格|擅长技术|编程兴趣|希望担任的软工角色|一句话宣言|
|:---|:---|:---|:---|:---|:---|:---|
|周英杰|做事有大局观|javaweb，java，c等等|c++|算法编写|破釜沉舟，百二属楚|
|赵永军|思想独立、做事细心|擅长python和写文档|python|开发和文档编写|官方划水最为致命|
|唐敬博| 做事心细，思想独特 |c语言和javaee|c语言|前端及部分后端|坚持不懈，加油|
|赵艳强|处事成熟、比较直接|web前端开发|web|前端|再接再厉|

4、团队特色描述，言简意赅的描述团队特点或核心竞争力；

团队主要特点：有一致的目标、超高的爆发力、追求卓越的精神;
核心竞争力：团队成员各有所长，能力互补，有一个领导经验丰富的队长，有一群编码测试和写文档经历丰富的队员，无论是Java,c,还是JavaEE，都有相应擅长的编码人员，不仅如此，团队成员能够相互信任，有效沟通，我们团队也会始终坚持“坚持吃苦在前，享受在后”的理念。

5、申请开通团队博客，点击以下链接提交团队信息，将团队博客加入到班级博客；

• 团队博客链接：链接
• 团队博客截图
  
• 提交团队信息
  
• 将团队博客加入到班级博客
  
• 组建团队企业微信群
  

6.完成《实验四 团队作业1：软件研发团队组建》各项任务实际花费的时间

各个阶段	实际花费时间（min）
估计时间	90
成员组建	10
设计团队名称	20
商讨团队口号	10
介绍团队风采	20
组建企业微信群	1
介绍团队特点	10
心得体会	20
总共花费的时间 （分钟）	101

7.阅读《现代软件工程—构建之法》第5章内容

7、阅读《现代软件工程—构建之法》第5章内容。
团队和流程
团队

• 主治医师模式(Chief Programmer Team, Surgical Team)
  就像在手术台，上那样，有一个主刀医师，其他人(麻醉，护士，器械)各司其职，为主刀医师服务。这样的软件团队中，有首席程序员(Chief Programmer)，他1她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。佛瑞德.布鲁克斯在主管IBM System 360项目时就采用了这种模式。
• 明星模式(Super-star Model）
  主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子4。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔.乔丹说过，“Talent wins games, teamwork wins championship."一些摇滚乐团的团队成员个性非常突出，团队时时都处于解体的边缘。
• 社区模式(Community Model）
  社区由很多志愿者参与，每个人参与自已感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区” 并不意味着“随意”，一些成功的社区项目( 例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签人的质量控制。
• 业余剧团模式(Amateur Theater Team)
  这样的团队在每一一个项目(剧目)中，不同的人会挑选不同的角色。在下一个剧目中,这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥(导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
• 秘密团队(Skunk Work Team)
  一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macintosh之后的系统时，就有两三个团队在不同时期进人秘密状态开发。21 世纪的一些创业团队也是处于类似状态。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰(不用每周给别人介绍项目进展，听领导的最新指示，等等)。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
• 特工团队(SWAT)
  就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
• 交响乐团模式(Orchestra)
  交响乐团的演奏有下面的特点。
  家伙多，门类齐全。
  各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
  演奏都靠谱，同时看指挥的。
  演奏的都是练习过多次的曲目,重在执行。
• 爵士乐模式(Jazz Band)
  不靠谱。他们演奏时都没有谱子。
  没有现场指挥，平时有编曲者协调和指导乐队，和迈尔斯常年合作的编曲吉尔.伊文斯(GilEvans)也是很有造诣的音乐家。
  也有模式,迈尔斯(姑且称之为架构师)先用小号吹出主题，然后他到一旁抽烟去了,其余人员根据这个主题各自即兴发挥;最后迈尔斯加入，回应主题，像是对曲子的总结。
  人数较少。
• 功能团队模式(Feature Team)
  很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
• 官僚模式(Bureaucratic Model)
  

这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一-重大隐患，在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。
流程

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

这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
“只用一次”的程序
“看过了就扔”的原型
一些不实用的演示程序

• 瀑布模型(Waterfall Model)
  尽管狭隘定义的瀑布模型有着这样那样的问题，可它还是一个反映人类解决问题思路的常用模型。它在软件工程实践中的局限性在于:
  各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来；
  回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯；
  最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用；
  如果产品的定义非常稳定，但是产品的正确性非常重要，需要每-一步的验证；
  产品模块之间的接口、输人和输出能很好地用形式化的方法定义和验证；
  使用的技术非常成熟，团队成员都很熟悉这些技术；
  负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流；
  . 瀑布模型的各种变形
  为了解决瀑布模型的问题，大家在实践中提出了各种变形:
  生鱼片模型(各相邻模块像生鱼片那样部分重叠);
  

这个模型解决了各个步骤之间分离的缺点，同时也带来了一些困扰——究竟什么时候上一个阶段会结束呢?
. 大瀑布带着小瀑布
为了解决不同子系统之间进度不一,技术要求迥异，需要区别对待的问题，有人引入了子瀑布模型：
在这种瀑布群下，要把各个子系统做到最后做系统测试(System Test)的阶段，难度不是一般的大啊!另外，在这样的开发流程中，用户只有到了最后才能看到结果，用户真是等不起。

• Rational Unified Process统一流程(RUP)
  从瀑布模型开始的各种模型都有-个共同点:重计划，重事先设计，重文档表达。这一类的方法中集大成者要算Rational统一流程( Rational Unified Process, RUP)。RUP把软件开发的各个阶段整合在一个统一的框架里。
  要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情，这些不同类型的工作在RUP中叫做规程(Discipline)或者工作流(Workflow)。简介如下。
• 业务建模
  为用户提供软件，就要理解目前用户的业务流程，但是精通计算机语言细节的工程师并不能马上理解对用户活动和期望值的各种自然语言描述。为了解决这个问题，业务建模(Business Modeling)工作流用精确的语言(通常是UML)把用户的活动描述出来。这个词有时也翻译为“商业建模”，但并不是只有存在金钱交易的商业活动才能符合建模的要求，任何和客户的正常工作相关的业务活动(例如政府为居民提供网上服务，学生到图书馆借书)都是建模的对象。这个工作流的结果通常是用例( Use Case) ,后面章节对用例有专门介绍。
• 需求
  有了用例之后，开发人员和用户(或者用户代表)要分析并确认软件系统得提供什么样的功能来满足用户的需求，功能有什么约束条件,如何验证功能满足了用户需求。这就是需求
  工作流的作用。
• 分析和设计
  分析和设计(Analysis & Design)工作流将需求转化成系统的设计。这一步结束之后，团队成员就能知道系统有哪些子系统、模块，它们之间的关系是怎样的。
• 实现
  在实现(Implementation)工作流中，工程师按照计划实现上一步产出的设计,将开发出的组件(Module)，连同验证模块(例如:单元测试)提交到系统中。同时，工程师们集成由单个开发者(或小组)所产生的结果,通过手工或自动化的手段,把可执行的系统搭建出来。
• 测试
  测试工作流要验证现阶段交付的所有组件的正确性、组件之间交互的正确性，以及检验所有的需求已被正确地实现。在这个过程中，发现、报告、会诊、修复各种缺陷，在软件部署
  之前保证质量达到预期要求。
• 部署
  部署(Deployment)工作流的目的是生成最终版本并将软件分发给最终用户。具体过程可以参考本书“稳定和发布阶段”一章。
• 配置和变更管理
  配置和变更管理工作流(Configuration and Change Management)负责管理RUP各个阶段产生的各种工作结果(例如源代码控制系统管理和备份各种源文件)，要记录修改人员、修改原因、修改时间等属性，有些团队还可以考虑并行开发、分布式开发等。
• 项目管理
  软件项目管理工作流(ProjectManagement)负责平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功地在各个阶段交付达到要求的产品。
• 环境
  环境( Environment)工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。
• 初始阶段
  此阶段的目标是分析软件系统大概的构成，系统与外部系统的边界在哪里(我们的系统究竟和什么别的外部实体打交道)，大致的成本和预算是多少，系统的风险主要来自哪里。成功度过初始阶段的项目会达到生命周期目标(Lifecycle Objective)里程碑。
• 细化阶段
  它的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，按优先级处理项目中的风险。团队要确定项目的具体范围、主要功能、性能、安全性、可扩展性等非功能需求。同时为项目建立支持环境，包括创建开发案例、创建模板并准备工具。细化阶段结束时，项目到达了第二个重要的里程碑:生命周期结构( Lifecycle Architecture)里程碑。
• 构造阶段
  在这一阶段，团队开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。构造阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。此时的产品版本也常被称为“beta” 版。
• 交付阶段
  这时候，团队工作的重点是确保软件能满足最终用户的实际需求。交付阶段可以有迭代(betal, beta2 等)，基于用户的反馈，团队利用这些迭代对系统进行修改、调整。除了对功能的调整，团队还要注意处理用户设置、安装和可用性等问题。在交付阶段的终点是第四个里程碑:产品发布( Product Release)里程碑。
• 老板驱动的流程(Boss-Driven Process)
  有下面几个因素：
  当软件订单的获得不是主要靠技术实力，而是靠个人关系，或者暗箱操作的时候，老板的能力决定了一个团队是否能获得订单，既然软件的具体功能并不重要(或者哪个团队做水平都差不多)，那么老板说做什么就做什么。
  在大型企业内部，软件功能往往由行政体系来决定。
  有些老板比一般技术人员更懂市场和竞争。
  软件团队尚未成熟，不懂得如何独立地进行需求分析，不懂得如何对行政领导有技巧地说“不”，也不知道如何说服利益相关者同意并支持正确的项目方向。既然不能驱动团队成员，那只能靠外力来驱动了。
• 渐进交付的流程(Evolutionary Delivery)，MVP和MBP
  下面几个条件满足一个即可：
  时间到了。
  钱花光了。
  用户满意了（或者很不满意，不再给钱了）。
• MVP——Minimum Viable Product ,最小可行产品,又称为Minimal Feature Set,最小功能集。
• TSP的原则
  使用妥善定义的流程，流程中的每- -步都是可以重复、可以衡量结果的。
  团队的各个成员对团队的目标、角色、产品都有统一的理解。
  尽量使用成熟的技术和做法。
  尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
  制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定(而不是从上级而来)。
  增加团队的自我管理能力。
  专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题)。

8.成本次作业的感受和体会

• 体会到了团队合作的主要优势有分工不同，有一加一大于二，跟主要的是有利于促进团体成员共同进步；但还是有一定问题的，比如：交流出现问题等等。