202205-为党和国家办事 实验五 团队作业2：软件项目案例分析

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

一.软件项目团队的特点和模式

1.软件项目团队的特点

• 团队有致的集体目标， 团队要- -起完成这 目标。一.个团队的成员不一 定要同时工作，例如接力赛跑。王屋村搬砖的“非团队”成员则不然，每个人想搬多少就搬多少，不想干了就结算工钱走人。
• 团队成员有各自的分工，互相依赖合作，共同完成任务。王屋村搬砖的“非团队”成员则是各自行动，独立把任务完成，有人不辞而别，对其他的搬砖人无实质影响。

2.软件项目团队的模式

• 一窝蜂模式：

  例如小朋友们刚开始踢足球的时候，大家都一窝蜂地去抢球，球在哪里，一堆人就跟到哪里

• 主治医师模式（Chief Programmer Team，Surgical Team）

  就像在手术台上那样，有一个主刀医师，其他人（麻醉，护士，器械）各司其职，为主刀医师服务。这样的软件团队中，有首席程序员（Chief Pro-grammer），他/她负责处理主要模块的设计和编码，其他成员从各种角度支持他/她的工作（后备程序员、系统管理员、工具开发、编程语言专家、业务专家）。佛瑞德·布鲁克斯（Frederic BrooksJr.）在主管IBM System360项目时就采用了这种模式。在一些学校里，软件工程的团队模式往往从这一模式退化为“一个学生干活，其余学生跟着打酱油”。

• 明星模式（Super-star Model）

  主治医师模式运用到极点，可以蜕化为明星模式，在这里，明星的光芒盖过了团队其他人的总和，2004年到2012年的“翔之队”就是一个例子。明星也是人，也会受伤，犯错误，如何让团队的利益最大化，而不是明星的利益最大化？如何让团队的价值在明星陨落之后仍然能够保持？是这个模式要解决的问题。真正有巨大成就的明星都能意识到团队的作用，迈克尔·乔丹说过，“Talent winsgames, team work wins championship.”

• 社区模式（Community Model）

  社区由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。“社区”并不意味着“随意”，一些成功的社区项目（例如开发和维护Linux操作系统的社区），都有很严格的代码复审和签入的质量控制。

• 业余剧团模式（Amateur Theater Team）

  这样的团队在每一个项目（剧目）中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥（导演）的指导和安排。在学生实践项目或培训项目中，这样的事情经常发生。

• 秘密团队（Skunk Work Team）

  一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macin-tosh之后的系统时，就有两三个团队在不同时期进入秘密状态开发。21世纪的一些创业团队也是处于类似状态。这种模式的好处是：团队内部有极大的自由，没有外界的干扰（不用每周给别人介绍项目进展，听领导的最新指示，等等），团队成员有极大的投入。

• 特工团队（SWAT）

  就像电影电视中的特工组《加里森敢死队》等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。例如2000年之前，很多公司都需要专业人士去解决Y2K问题。这些团队成员必须了解传统语言和老式系统，才能胜任这样的任务。现在还有一些专门做网站安全性服务的团队，也属于这一类型。

• 交响乐团模式（Orchestra）

  当某个软件领域处于稳定成长阶段的时候，众多大型软件公司的开发团队就会采取这种模式，例如微软公司的Office软件，从Office97、Office XP、Office2003、Office2007到Office2011、Office2013……

• 爵士乐模式（Jazz Band）

  强调个性化的表达，强有力的互动，对变化的内容有创意的回应。这看上去跟“敏捷的开发模式”有点类似。这样的团队模式和上面的“交响乐团模式”在很多方面都对立，但是两种模式都产生了很受欢迎的音乐作品，因此不能简单地说孰优孰劣。

• 功能团队模式（Feature Team）

  很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。这些功能小组也称为Feature Crew，小组内的交流比较频繁。

• 官僚模式（Bureaucratic Model）

  这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种模式如果应用不好，最后会变成“老板驱动”的开发流程，见后面的介绍。

二.典型软件过程模型特点

1.生鱼片模型（各相邻模块像生鱼片那样部分重叠）

2.渐进交付的流程（Evolutionary Delivery），MVP和MBP

• 这个流程是史蒂夫·迈克康奈尔（Steve McConnell）在1996年总结的，但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中：[开发→发布→听取反馈→根据反馈做改进]
• MVP[注释7]——Minimal Viable Product，最小可行产品，又称为Minimal Feature Set，最小功能集。具体的做法是：把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。

3.敏捷流程

• 敏捷开发原则

  1. 尽早并持续地交付有价值的软件以满足顾客需求
  2. 敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势
  3. 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短
  4. 业务人员和开发人员在项目开发过程中应该每天共同工作
  5. 以有进取心的人为项目核心，充分支持信任他们
  6. 无论团队内外，面对面的交流始终是最有效的沟通方式
  7. 可用的软件是衡量项目进展的主要指标
  8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
  9. 只有不断关注技术和设计，才能越来越敏捷
  10. 保持简明—尽可能简化工作量的技艺—极为重要
  11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
  12. 时时总结如何提高团队效率，并付诸行动

• 敏捷的团队

  软件开发流程有好多种，我们怎么衡量一个开发流程是否对当前的项目/团队合适？我觉得Scrum/Sprint能成功实施的关键在于Scrum Master。我听到有些团队也实施Scrum，但是他们随机挑一个成员来做Scrum Master，好像Scrum Master就是招呼大家开开会，记录每个人的进度而已。这种方法失败的可能性很大。一个好的Scrum Master能在两种语境（描述软件需求的商业语境，描述实现细节的技术语境）间自如地翻译和切换，事实上是一个强有力的项目经理（PM，参见本书“项目经理”一章）。如果团队还要求他/她做全职的开发工作，这样的人就更难找了。敏捷对团队的要求很简单：自主管理（Self-manag-ing）、自我组织（Self-organizing）、多功能型（Cross-functional），但是这很难做到。软件项目的团队各式各样（请看“团队和流程”一章），假设一个团队做得还不错，现在要变成敏捷流程，那团队要做下面的改变：

  1. 自主管理：以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
  2. 自我组织：以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
  3. 多功能型：以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
     如果你的团队很弱，那么强行把敏捷（或者其他高级方法）套在上面也没有用，也许还会适得其反，往往需要多次Sprint才能让Scrum走上正轨。换句话说，如果你的团队已经有这么厉害（自主管理、自我组织、多功能型）的一帮人，那么用不用Scrum都能写好软件！

三.软件项目团队设置项目经理的缘由、项目经理的职责

1.设置项目经理的缘由

• 团队成员之间交流的成本急剧增长
• 有很多开发和测试之外的事情，需要专人负责

2.项目经理的职责

他们对项目流程负责，即项目从立项到上线按时完成。正确地协调团队内部外部，调配各部门资源和时间，有效进行风险管理，保证一个项目顺利按计划结项，是一个项目经理的核心价值。Program Manager：微软的职位名称。微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广。

• 交流成本问题
• PM做开发和测试之外的所有事情
• 风险管理

四.团队学习总结

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

我们选择的是D软件案例分析任务

有很多IT技术社区网站提供IT人士发布博客的功能，Markdown 是一种常用的博客编辑器，请使用以下CSDN博客功能，结合使用体验分析CSDN 的 Markdown 编辑器好用么？它对于各种文件格式、插入图像、动画、表格、代码块的支持如何？发现了什么问题？请描述在使用CSDN博客中碰到的问题，以及改进的建议；CSDN 的 Markdown 编辑器与博客园的博客编辑器相比，有什么优缺点（至少列出5条）。

• CSDN博客文章管理：https://editor.csdn.net/md/

一.团队成员使用频率表

二.被测软件各方面总结

1.解决的问题

• CSDN的编辑器实现了可以自动生成目录可以在撰写完文章之后自动生成目录；
• CSDN的编辑器实现了草稿以及预览在同一界面
• CSDN的编辑器提供了文本模板

2.在数据量/界面/功能/准确度上的优缺点

? 在分别使用博客园以及CSDN的markdown编辑器编辑这篇文章后，有了很多的思考以及总结，

? (1)优点

• 很清晰的看出文章的体系结构，因为有目录的存在，可以使阅读者很轻易的找到需要查阅的部分；
• 文本模板功能，对新手用户很友好，容易上手，渐变操作；
• 从传统的博客注重排版设计到CSDN博客注重博客内容，CSDN编辑器很大程度上解决了排版难的问题；
• 因为草稿与预览在同一界面，所以很轻松的可以发现在编写时时的问题，这又与传统博客编辑不同；
• 界面总体来说很简洁，但是该有的功能一个也不少，能让人直观的了解功能栏的工具时干什么的

? (2)缺点

• 最大上传图片不i能超过5MB
• 网页源代码不能清楚的表示博客内容
• 不能快捷操作各种工具

3.被测软件实际用户体验（以清华大学本科生石同学为例）

? （1）用户背景与需求

? 基本信息：石同学 2019级清华大学本科生

? 专业：工科实验班类（能源电气方面）

? 需求：需要一个发布实验结果的平台

? （2）用户使用软件的图片

? （3）概括用户使用过程，判断用户使用体验

? · 使用过程：

? 用户首先打开CSDN编辑器，选择了模板中的新手模板，进行对编辑器的熟悉；随后新建了一个自己的新编辑，利用各种工具撰 写自己的文章

? · 用户体验

? 用户体验感良好，CSDN编辑器新手上手快
?

? （4）对用户的采访

? 问：你觉得CSDN编辑器这个平台对你本次书写这篇文章帮助大不大？

? 答：以前没有用过专业的编辑器，都是靠word自己修改格式，我觉得CSDN平台的编辑器至少不用让我在操心格式的问题了，之前 每次格式都要改好久，靠word生成的目录，吃了好几次亏了。

问：你以后会经常使用CSDN吗？

? 答：当然，好用方便的工具大家都爱。

? 问：那你对CSDN能提出一点修改意见吗？

? 答：因为我写的文章里面图片很多，我希望能上线一个新的调整图片的功能，能让我自由的排版我的图片

4.本次任务PSP列表

5.对于本次作业的感想与体会

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