202214-无霸哥 实验五 团队作业2 ：软件项目案例分析

项目概况	内容
班级博客链接	2019卓越工程师班
作业要求链接	实验五 软件项目案例分析
团队名称	无霸哥
团队课程学习目标	（1）学习团队软件项目流程（TSP）、软件项目团队的角色分工，软件项目经理的职责。 （2）掌握敏捷流程原则及相关概念。 （3）软件案例分析。
这个作业在哪些方面帮助团队实现学习目标	（1）了解软件项目团队设置的分工和协作。 （2）通过团队的方式进行项目的学习体验。 （3）了解掌握瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点
团队博客链接	无霸哥

正文

任务1：以团队协作学习方式，阅读《现代软件工程—构建之法》第5、6章内容，理解并掌握软件项目团队的特点和模式、结合理论课学习内容理解瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点，理解并体会卡内基梅隆大学（CMU）软件工程学院总结的TSP原则；阅读《现代软件工程—构建之法》第9章内容，了解软件项目团队设置项目经理的缘由、项目经理的职责。

1.软件项目团队的特点

• 具有明确一致的目标，有很强的凝聚力
• 具有合理的开发过程，例如接力模式
• 具有各自的分工，协作共同完成任务
• 具有规范的工作标准和框架

2.软件项目团队的模式

模式	特点
主治医师模式	首席程序员“主刀”负责处理主要模块的设计和编码，其他成员作为“辅助医生”
明星模式	主治医师模式运用到极点
社区模式	由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬
业余剧团模式	团队中各人扮演各人的角色，每个人都可尝试不同角色
秘密团队	在秘密状态下进行，别人不知道他们具体在做什么。
特工团队	软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题，效率很高，但对成员的技术要求相应也会很高
交响乐团模式	像交响乐团一样各司其职，当某个软件领域处于稳定成长阶段的时候,众多大型软件公司的开发团队就会采取该模式。
爵士乐模式	负责人给出主题，成员们各自提出意见方法，收尾时总结，与交响乐团模式存在很多对立面
功能团队模式	具备不同能力的同事们平等协作公共完成一个功能，要求每个小组必须与其他小组就编程规范达成一致
官僚模式	每个人将工作情况与内容成果报告上交给上级

3.软件项目开发流程

• 写了再改模式
  史蒂夫·迈克康奈尔在这里”提到了不少开发流程。第一个提到的开发流程——Code-and-Fix，看起来和一窝蜂团队模式非常像。
  
  这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来,写不出来就改，也许能改好。当面临下面的任务时,也许这个方法是有用的。
  ·“只用一次”的程序
  ·看过了就扔”的原型
  ·—些不实用的演示程序
  但是，要写一个有实际用户、解决实际需求的软件，这个方法的缺点就太大了。要注意的是，许多学校里的软件工程作业的要求符合上面那三点，所以难怪同学们觉得没有必要用其他的开发方法,“写了再改”足矣!
• 瀑布模型
  当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建筑工程)借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循〔分析→设计→实现（制造）→销售→维护]这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。
  温斯顿·罗伊斯( Winston Royce）在1970年的论文“Managing the Development of LargeSoftware Systems”"中第次明确地描述了这个模型（虽然他没有用Waterfall这个词)。但是要注意的是，温斯顿并不推崇严格意义上的瀑布模型，相反他指出了此模型的各种缺陷，并提出了一些改进的办法。
  例如，温斯顿正确地指出了在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题,如图5-9所示。
  
  又如，温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本，在此基础上收集反馈,改进各个步骤,并交付一个最终的版本:
  
  温斯顿还指出，用户的及早介人、讨论、复审是很重要的。他建议:要让顾客正式地、深入地、持续地参与到项目中来。
  他也提到在这个模型下文档的重要性。下面的图中显示了6种文档。
  
  那么、瀑布模型有适用范围么?我认为有:
  ·如果产品的定义非常稳定,但是产品的正确性非常重要,需要每一步的验证
  ·产品模块之间的接口、输人和输出能很好地用形式化的方法定义和验证
  ·使用的技术非常成熟,团队成员都很熟悉这些技术
  ·负责各个步骤的子团队分属不同的机构，或在不同的地理位置，不可能做到频繁的交流
• 瀑布模型的各种变形
  ·生鱼片模型（各相邻模块像生鱼片那样部分重叠)这个模型解决了各个步骤之间分离的缺点,同时也带来了一些困扰——究竞什么时候上一个阶段会结束呢？
  
  ·大瀑布带着小瀑布为了解决不同子系统之间进度不一,技术要求迥异,需要区别对待的问题,有人引人了子瀑布模型:
  
   在这种瀑布群下，要把各个子系统统一到最后做系统测试( System Test)的阶段，难度不是一般的大啊!另外，在这样的开发流程中，用户只有到了最后才能看到结果，用户真是等不起。
• 统一流程（RUP）
  要完成一个复杂的软件项目，团队的各种成员要在不同阶段做不同的事情,这些不同类型的工作在RUP中叫做规程（Discipline)或者工作流(Workflow )。
  
• 老板驱动的流程（Boss-Driven Process）
  开发流程由行政领导主导，或者由公司的老板驱动。
• 渐进交付的流程
  这个流程是史蒂夫·迈克康奈尔在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的循环中:
  
• 敏捷流程
  1.开发原则
  ·尽早并持续地交付有价值的软件以满足顾客需求
  ·敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势
  ·经常发布可用的软件,发布间隔可以从几周到几个月,能短则短
  ·业务人员和开发人员在项目开发过程中应该每天共同工作
  ·以有进取心的人为项目核心，充分支持信任他们
  ·无论团队内外,面对面的交流始终是最有效的沟通方式
  ·可用的软件是衡量项目进展的主要指标
  ·敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
  ·只有不断关注技术和设计,才能越来越敏捷
  ·保持简明——尽可能简化工作量的技艺——极为重要?
  ·只有能自我管理的团队才能创造优秀的架构、需求和设计
  ·时时总结如何提高团队效率,并付诸行动
  
  
  2.开发步骤
  第一步:找出完成产品需要做的事情——Product Backlog.
  第二步:决定当前的冲刺( Sprint）需要解决的事情——Sprint Backlog.
  第三步:冲刺。
  第四步:得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

4.TSP原则

• 使用妥善定义的流程,流程中的每一步都是可以重复、可以衡量结果的。
• 团队的各个成员对团队的目标、角色、产品都有统一的理解。
• 尽量使用成熟的技术和做法。
• 尽量多地收集数据(也包括对团队不利的数据),并用数据来帮助团队做出理性的决定。
• 制定切合实际的计划和承诺，团队计划要由负责具体执行的的角色来制定（而不是从上级而来）。
• 增加团队的自我管理能力。
• 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作(而不是在后期匆忙修复问题）。

这些原则虽然抽象，但是每个团队在做Postmortem(参见15.3节)的时候，可以对照检查，看看自己的团队在刚刚过去的软件生命周期中到底提高了多少。

5.项目经理
 典型的软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要,我们叫他们项目经理——PM。
 PM的M就是Manager，但是P有这几种: Product Manager、Project Manager、ProgramManager，在不同的行业和公司，他们的作用各不相同。这一章主要介绍微软的项目经理—Program Manager。
 Product Manager :产品经理—正确地做产品。目前国内公司大部分PM都是指这个职位。产品经理对一个或多个产品或产品线负责，而互联网产品涉及到这些方方面面:产品定位、市场发展、需求分析、运营、营销、市场推广、商务合作。产品经理横跨这些部门，寻找资源,持续推进产品。随着产品的发展，不同公司，对PM要求会不一样。核心要求是,根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。
 Project Manager :项目经理——正确地做流程。在某些公司，这个职位与产品经理分开单列。他们对项目流程负责，即项目从立项到上线按时完成。正确地协调团队内部外部，调配各部门资源和时间,有效进行风险管理，保证一个项目顺利按计划结项，是一个项目经理的核心价值。
 Program Manager :微软的职位名称。微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划( Product Planner )，他们和市场部门的专职人员一起，负责产品的长期发展和市场推广。

PM应具有的能力

• 观察、理解和快速学习能力
• 分析管理能力
• 一定的专业能力
• 自省的能力
• 领导力

6.讨论截图

任务2：以团队协作学习方式，从B、C、D三个软件案例分析任务中选择一个课题来进行。

通过讨论，我们选择了B任务进行学习。
1.发布动态


2.小组成员使用情况

小组成员	使用时间/h
牛靖威	4
王孜睿	4.5
曹霖枫	5

3.问题讨论

• 很多开发人员和IT专业的学生都在移动设备上学习、工作、社交，在移动设备上的APP 能满足这类目标用户的需求么？
  在移动平台上也学习了很久，经常在B站或者学习APP上搜教程，在CSDN或博客园上寻找问题的解决办法，这个过程体验下来也确实解决了不少问题，学到了不少东西，下通过下图展示的资料可以看出网上确实有许多值得学习且非常有用的东西，但整个学习下来感觉网上的东西有些许杂乱且不够全面，也可能是计算机方面的知识细节太多，版本更新速度太快，以致与有时候找不到合适的知识和解决办法。
  

• 这类APP会被微信公众号取代吗？
  个人感觉不会，下图是我关注的公众号每天发布的一些文章，在关注一段时间后，我发现我更愿意去利用公众号拓宽自己专业方面的视野和知识面，而在学习和搜寻解决办法方面，我更愿意去使用网站和APP的方式
  

任务3：完成《实验五 团队作业2：软件项目案例分析》团队博文作业

• 完成情况：已完成。

任务	花费时间/h
任务1	3
任务2	4
任务3	2
合计	9

• 体会心得：通过这次实验，我们了解了项目经理的由来以及完成的任务和所要具备的能力，同时也学习了软件项目的模式以及开发流程，组队开发项目的思路也更加明确，在这次团队项目中，小组成员之间的合作也更加得默契和流畅。

• 完成截图：