卡其脱离太 实验四 团队作业1：软件研发团队组建

项目	内容
课程班级博客链接	班级博客
团队名称	卡其脱离太
这个作业要求链接	作业要求
团队的的课程学习目标	通过完成项目学习，掌握团队开发的模式和流程，团队的概念和各种团队模式体会
这个作业在哪些方面帮助团队实现学习目标	通过学习分析项目案例，学习到怎样更好的进行结对协作并发挥最大效益以及如何进行更好的团队协作
团队博客链接	团队博客

任务二：团队组建

任务要求：

（1）在实验三结对基础上，结对小组两两自由组合，组建软件项目研发团队；

（2）申请开通团队博客，点击以下链接提交团队信息，将团队博客加入到班级博客。

（3）阅读《现代软件工程—构建之法》第5章内容。

任务内容：

1.队名：卡其脱离太

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

成员学号后五位	成员*名	个人博客地址	备注
10130	*学铭	博客链接	PM
30110	*飞	博客链接
30131	*林江	博客链接
30107	* 雅伦	博客链接

3. 成员风采：介绍每位队员的风格、擅长技术、编程兴趣、希望的承担的软工角色(文档、开发、测试、PM等)、一句话宣言等

成员*名	擅长语言	擅长技术	编程兴趣	希望的承担的软工角色	宣言
*学铭	C/C++	算法	爱好算法，喜欢创新	PM（算法工程师）	天总会亮的，没有太阳也会亮的。
*飞	JAVA	SSM、thymeleaf等	不太喜欢编程，但我会尽力让自己爱上编程	测试	世间万物中，表里如一者，又有几何。
*林江	JAVA	UI	想法很多，希望能设计出一款自己满意的APP。	UI设计	天地不仁，以万物为刍狗。
* 雅伦	Python	数据分析处理	编程不是我擅长的领域，但我会努力去克服它	文档	律己而强，勤勉则刚

4.阅读《现代软件工程—构建之法》第7章、第17章，理解MSF的9点基本原则和团队成员绩效

MSF的9点基本原则：

• 推动信息共享与沟通（Foster open communications）
  • 所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。当然，对牵涉到的技术机密、安全性等信息要采取必要的保护措施
• 为共同的远景而工作（Work toward a shared vision）
  • 这个目标必须是明确的，没有二义性；这个目标不是当前就能达到，必须是通过努力才能达到的；这个目标不是空泛的，它应该对项目成员每天的工作都有指导作用。每天你来上班，如果发现你做的事情对项目的远景没有帮助，你应该和老板提出来。
• 充分授权和信任（Empower team members）
  • 平等协作---成员之间、团队之间是平等协作的关系；充分授权给团队和成员。
• 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
  • 无责任的旁观者和有重大责任的当局者的看法自然是不一样的。对此事负责的角色要自己拿主意。
• 重视商业价值（Focus on delivering business value）
  • 如果你还没有能说清楚你的产品解决了什么问题，为谁解决问题，为什么你的产品会解决这些问题，以及客户怎样付钱让你解决问题，那你就不应该贸然创业。
• 保持敏捷，预期变化（Stay agile,expect change）
  • 软件工程，唯一不变的是变化。所以干脆别幻想客户的需求会在第一-时刻很明确，然后保持不会变。但要注意，我们是预期变化，不是期望变化。
• 投资质量（Invest in quality）
  • 不是质量第一，而是解决用户的问题第一。
• 学习所有的经验（Learn from all experiences）
  • 把经验总结出来；分享经验。是为了：让团队成员从别人的成果和失败的例子中学到东西；帮助新项目重复以往成功的做法；培育团队总结的习惯和“批评与自我批评”的文化。
• 与顾客合作（Partner with internal and external customers )
  • MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同之后，就闭门造车，直到产品完成才告诉用户，给他们一个惊喜。

团队成员绩效：

• 评价体系:采用二维评价体系。

完成任务\贡献	10%	70%	20%
超额
合格
未完成

• 完成任务维度：主要由团队成员和直接经理商量年度目标,直接经理有较大的自由度决定“超额完成/完成/未完成”的比例。例如大部分成员都可以得到“完成”这一评价。
• 团队贡献维度:还是严格根据人员百分比，评出团队中最好的20%、中间的70%，以及最需要改进的10%。(由于我们小组只有四个人，所以只评出团队中最好的1人、中间的2人以及最需要改进的1人)

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

• 5.1 非团队和团队
  • 团队与非团队的区别是什么？
    • （1）团队是一群志同道合的人聚集在一起专注于某一件事，互相鼓励，不离不弃，具有“契约精神”；
    • （2）非团队是一群乌合之众，可以随时一拍而散，各自行动，对其他人不理不顾，只在乎自己利益最大化，不在乎是否会影响其他人。
• 5.2 软件团队的模式
  • 主治医师模式(Chief Programmer Team, Surgical Team)
    • 就像在手术台，上那样，有一个主刀医师，其他人(麻醉，护士，器械)各司其职，为主刀医师服务。这样的软件团队中，有首席程序员(Chief Programmer)，他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作(后备程序员、系统管理员、工具开发、编程语言专家、业务专家)。佛瑞德.布鲁克斯在主管IBM System 360项目时就采用了这种模式。
  • 明星模式(Super-star Model)
    • 主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化?如何让团队的价值在明星陨落之后仍然能够保持?是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔.乔丹说过，“Talent wins games, teamwork wins championship."一些摇滚乐团的团队成员个性非常突出，团队时时都处于解体的边缘。
  • 社区模式(Community Model）
    • 社区由很多志愿者参与，每个人参与自已感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴;或者捡到的柴火质量太差，最后火也就熄灭了。“社区” 并不意味着“随意”，一些成功的社区项目( 例如开发和维护Linux操作系统的社区)，都有很严格的代码复审和签人的质量控制。
  • 业余剧团模式(Amateur Theater Team)
    • 这样的团队在每一一个项目(剧目)中，不同的人会挑选不同的角色。在下一个剧目中,这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥(导演)的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。在业余玩票、培训的环境中，每个人可以尝试不同角色，大家还可以比较平等地讨论。但是在竞争性强烈、创造性要求高的团队，不会存在完美的民主气氛，就像职业足球比赛，每个人的责任都不可或缺，但是不会每个人都有同样的控球时间。
  • 秘密团队(Skunk Work Team)
    • 一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macintosh之后的系统时，就有两三个团队在不同时期进人秘密状态开发。21 世纪的一些创业团队也是处于类似状态。这种模式的好处是:团队内部有极大的自由，较高的热情，没有外界的干扰(不用每周给别人介绍项目进展，听领导的最新指示，等等)。一个团队的成员如果有很大的自由度，又有独特的使命，这对于大家来说，是很大的驱动力。这样的团队往往能发挥超高的效率完成看似不可能的任务。
  • 特工团队(SWAT)
    • 就像电影电视中的特工组“加里森敢死队”等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
    • 就像电影电视中的特工组“加里森敢死队”等- -样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决--些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题s。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
  • 交响乐团模式(Orchestra)
    • 交响乐团的演奏有下面的特点。
      • 家伙多，门类齐全。
      • 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
      • 演奏都靠谱，同时看指挥的。
      • 演奏的都是练习过多次的曲目,重在执行。
  • 爵士乐模式(Jazz Band)
  • 不靠谱。他们演奏时都没有谱子。
  • 没有现场指挥，平时有编曲者协调和指导乐队。
  • 也有模式。
  • 人数较少。
  • 强调个性化的表达，强有力的互动，对变化的内容给予有创意的回应。
  • 功能团队模式(Feature Team)
    • 很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。
  • 官僚模式(Bureaucratic Model)
    • 这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种结构有一重大隐患，在做绩效评估的时候，各个小老板、中老板都要为自己手下的弟兄们争名夺利，而有意无意地忽略了全局最优的绩效评估标准，导致很多无谓的算计、纠结、甚至有人会贬低别的团队的贡献。
• 流程
  • 写了再改模式(Code-and-Fix)
    • 这个流程的好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。
      • “只用一次”的程序
      • “看过了就扔”的原型
      • 一些不实用的演示程序
  • 瀑布模型(Waterfall Model)
    • 当软件行业还在年幼的时期，它从别的成熟行业（硬件设计,建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循：分析→设计→实现（制造）→销售→维护，这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。
      • 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来
      • 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯
      • 最终产品直到最后才出现，但是软件的客户，甚至软件工程师本人都需要尽早知道产品的原型并试用“最终产品直到最后才出现”是很令人头痛的局限性。
  • Rational Unified Process 统一流程(RUP)
  • 老板驱动的流程(Boss-Driven Process)
  • 渐进交付的流程(Evolutionary Deliverry)，MVP和MBP
    • MVP——Minimum Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。
    • 正如所有的方法论那样，MVP也有它的适用范围，和它相对应的，是Maximal Beautiful Product（最强最美产品，MBP）的思路，如果对用户的需求了然于心，或者产品团队比用户更了解用户的需求，为何不把产品最全、最美的形态展现出来，一举征服用户？

6. 组建团队企业微信群，给出群成员截图

7. 团队特色描述，言简意赅的描述团队特点或核心竞争力

我们小组擅长市面上主流的Web框架，例如Spring boots、SSM、SSH等，具有独立开发项目的能力。对于算法方面，我们小组也有比较深入的研究，掌握较多的经典算法。同时我们小组擅长的编程语言基本覆盖了主流的编程语言，且各个成员有着各自擅长的领域，更有两位同学在平时拥有独立完成项目的能力。相信我们小组可以再软件工程这一门课里崭露头角。

任务总结：

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

任务	耗时
任务一	3h
任务二	2h
任务三	1.5h

2.谈谈完成本次作业的感受和体会

成员	感受和体会
周学铭	1.本次实验通过复审完成质量较高小组的项目成果，进一步发现了自己的不足。同时经过对项目的复审，找出了一些BUG，再通过这些找到的BUG对自己的项目进行复审，进一步完善了自己的项目，体会到了复审的重要性。 2.通过团队建设，各个成员都介绍了自己的特长，以及希望承担的工作，从中我们认识到了通过团队配合，取长补短，我们团队的核心竞争力才会变得更加强大。
何飞	1.通过本次实验，创建了团队，今后我们就要进行团队项目，希望今后团队项目做得越来越好。 2.通过运行其它小组的项目，学习了他人的技术，了解了自己的不足之处，希望今后可以弥补自己的不足之处，能够做得更好
常雅伦	本次作业任务一通过案例项目的分析，我意识到了自己与他人的差别，这也让我明白只有在实践中才能锻炼自己，提升能力，在运行别人源码的过程中，也学到了许多编码的知识。在本次任务二的学习中与同伴在理论上讨论了关于团队的概念和各种团队模式，体会到了一个团队要完成一个项目，需要各个成员做好分工协调工作，以及在项目启动时的开发计划尤为重要，这为我们之后的团队合作项目奠定了基础。
谢林江	在本次任务二的学习中与同伴在理论上讨论了关于团队的概念和各种团队模式，体会到了一个团队要完成一个项目，需要各个成员做好分工协调工作，以及在项目启动时的开发计划尤为重要，这为我们之后的团队合作项目奠定了基础。
小组体会：在本次任务二的学习中与同伴在理论上讨论了关于团队的概念和各种团队模式，体会到了一个团队要完成一个项目，需要各个成员做好分工协调工作，以及在项目启动时的开发计划尤为重要，这为我们之后的团队合作项目奠定了基础。