202203-Typhoon-Team 实验五 团队作业2:软件项目案例分析

项目 内容
课程班级博客链接 2022年春软件工程课程班(2019级计算机科学与技术)
团队名称 Typhoon-Team
作业要求链接 实验五 团队作业2:软件项目案例分析
团队的课程学习目标 1. 学习团队软件项目流程(TSP)、软件项目团队的角色分工,软件项目经理的职责。
2. 掌握敏捷流程原则及相关概念。
3. 软件案例分析。
这个作业在哪些方面帮助团队实现学习目标 1. 通过阅读《现代软件工程—构建之法》内容,对团队软件项目流程(TSP)、软件项目团队的角色分工,软件项目经理的职责有了深入的了解及学习,并且掌握了敏捷流程原则及相关概念。
2. 通过软件案例分析,对CSDN有了一定程度的学习和了解。
团队博客链接 Typhoon-Team

一、任务1:以团队协作学习方式,阅读《现代软件工程—构建之法》第5、6、9章内容

《现代软件工程—构建之法》第5章

5.1 非团队和团队

团队共有特点:
(1)团队有一致的集体目标,团队要一起完成这目标。
(2)团队成员有各自的分工,互相依赖合作,共同完成任务。

5.2 软件团队的模式


图1 足球队的团队分工

(1)蜂窝模式
  一堆人上来就干,没有协调性因为这样的团队存活时间不长,所以被观察到的不多
(2)主治医师模式
  首席程序员(ChiefProgrammer),他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作( 后备程序员、系统管理员、工具开发、编程语言专家、业务专家)工作,其余人打辅助,不少学校的软件工程的团队作业沦为这种模式,只靠团队中一两个完成任务,其余人打酱油。
(3)明星模式
  主治医生的极端版本
(4)社区模式
  Unix和Linux属于这种,依靠严格的质量管理和志愿者参与完成
(5)业余剧团模式
  学生的实践培训项目大概属于这种
(6)秘密团队
  苹果研发发Macintosh以后的系统和不少创业公司团队属于这种
(7)特工团队
  由特殊技能的专业人士组成,比如早年解决千年虫的团队和负责网络安全的团队
(8)交响乐团模式
  大多数大型软件公司开发团队采用这种模式,比如office系列


图2 交响队模式

(9)爵士乐模式
  和交响乐团相比,这种模式有以下特点:

  • 不靠谱。他们演奏时都没有谱子。
  • 没有现场指挥。
  • 也有模式,迈尔斯(姑且称之为架构师)先用小号吹出主题,其余人员根据这个主题各自即兴发挥;最后迈尔斯加入,回应主题,像是对曲子的总结。
  • 人数较少。

(10)功能团队模式
  很多软件公司的团队最后都演变成功能团队,简而言之,就是具备不同能力的同事们平等协作,共同完成一个功能。
(11)官僚模式
  这种模式脱胎于大机构的组织架构,几个人报告给一个小头目,几个小头目报告给中头目,依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导,同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难,因为各自头顶上都有不同的老板。

5.3 开发流程

  • 写了再改模式
      史蒂夫·迈克康奈尔在这里”提到了不少开发流程。第一个提到的开发流程——Code-and-Fix,看起来和一窝蜂团队模式非常像。

  这个流程也有好处,不需要太多其他准备或相关知识,大家上来就写代码,也许就能写出来,写不出来就改,也许能改好。当面临下面的任务时,也许这个方法是有用的。

“只用一次”的程序
看过了就扔”的原型
—些不实用的演示程序

  但是,要写一个有实际用户、解决实际需求的软件,这个方法的缺点就太大了。要注意的是,许多学校里的软件工程作业的要求符合上面那三点,所以难怪同学们觉得没有必要用其他的开发方法,“写了再改”足矣!

  • 瀑布模型

  当软件行业还在年幼的时期,它从别的成熟行业(硬件设计,建筑工程)借用了不少经验和模型。在那些“硬”的行业中,产品大多遵循〔分析→设计→实现(制造)→销售→维护]这个流程。由于在“硬”行业中产品一旦大规模生产,要再返回去修改时就非常困难,甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程。
温斯顿·罗伊斯( Winston Royce)在1970年的论文“Managing the Development of LargeSoftware Systems”"中第次明确地描述了这个模型(虽然他没有用Waterfall这个词)。但是要注意的是,温斯顿并不推崇严格意义上的瀑布模型,相反他指出了此模型的各种缺陷,并提出了一些改进的办法。例如,温斯顿正确地指出了在设计大型系统时,要做相邻步骤的回溯,解决上一阶段未能解决的问题。又如,温斯顿指出,要让产品成功,最好把这个模型走两遍,先有一个模拟版本,在此基础上收集反馈,改进各个步骤,并交付一个最终的版本:

  温斯顿还指出,用户的及早介人、讨论、复审是很重要的。他建议:要让顾客正式地、深入地、持续地参与到项目中来。他也提到在这个模型下文档的重要性。下面的图中显示了6种文档。

  那么、瀑布模型有适用范围么?我认为有:

  • 如果产品的定义非常稳定,但是产品的正确性非常重要,需要每一步的验证
  • 产品模块之间的接口、输人和输出能很好地用形式化的方法定义和验证
  • 使用的技术非常成熟,团队成员都很熟悉这些技术
  • 负责各个步骤的子团队分属不同的机构,或在不同的地理位置,不可能做到频繁的交流
  • 瀑布模型的各种变形
  • 生鱼片模型(各相邻模块像生鱼片那样部分重叠)这个模型解决了各个步骤之间分离的缺点,同时也带来了一些困扰——究竞什么时候上一个阶段会结束呢?

  大瀑布带着小瀑布为了解决不同子系统之间进度不一,技术要求迥异,需要区别对待的问题,有人引人了子瀑布模型:

  在这种瀑布群下,要把各个子系统统一到最后做系统测试( System Test)的阶段,难度不是一般的大啊!另外,在这样的开发流程中,用户只有到了最后才能看到结果,用户真是等不起。

  • 统一流程(RUP)
      要完成一个复杂的软件项目,团队的各种成员要在不同阶段做不同的事情,这些不同类型的工作在RUP中叫做规程(Discipline)或者工作流(Workflow )。

  • 老板驱动的流程(Boss-Driven Process)
      开发流程由行政领导主导,或者由公司的老板驱动。

  • 渐进交付的流程
      这个流程是史蒂夫·迈克康奈尔在1996年总结的,但是它其实已经很接近现在大家谈论较多的迭代式开发流程。当系统的主要需求和架构明确之后,软件团队进入了一个不断演进的循环中:

  • 开发步骤
    第一步:找出完成产品需要做的事情——Product Backlog.
    第二步:决定当前的冲刺( Sprint)需要解决的事情——Sprint Backlog.
    第三步:冲刺。
    第四步:得到软件的一个增量版本,发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

《现代软件工程—构建之法》第6章

6.1 敏捷流程

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


图4 敏捷流程图

图5 MSDN上的敏捷流程图

6.2 敏捷的步骤

  • 第一步:找出完成产品需要做的事情——Product Backlog。产品负责人领导大家对于这个Backlog中的条目进行分析、细化、理清相互关系、估计工作量等工作。每一项工作的时间估计单位为“天”。
  • 第二步:决定当前的冲刺( Sprint )需要解决的事情一Sprint Backlog。整个产品的实现被划分为几个互相联系的冲刺。产品订单上的任务被进-步细化了, 被分解为以小时为单位(参见WBS工作划分的办法)。如果一个任务的估计时间太长(如超过16个小时),那么它就应该被进一步分解。订单上的任务是团队成员根据自己的情况来认领。如果团队成员能主导任务的估计和分配,他们]的能动性得到较大的发挥。
  • 第三步:冲刺。在冲刺阶段,外部人士不能直接打扰团队成员。一切交流只能通过Scrum大师( Scrum Master)来完成。这一措施较好地平衡了“交流”和“集中注意力”的矛盾。有任何需求的改变都留待冲刺结束后再讨论。冲刺期间,团队通过每日例会( Scrum Meeting)来进行面对面的交流。
  • 第四步:得到软件的一个增量版本,发布给用户。然后在此基础上又进-一步计划增量的新功能和改进。

6.3 敏捷对团队的要求

  假设一个团队做得还不错,现在要变成敏捷流程,那团队要做下面的改变:
(1) 自主管理:以前领导布置了任务,我们实现就可以了,现在要自己挑选任务;每次Sprint结束之后,还要总结不足,提出改进,并且自己要实施这些改进。“自主管理”不等于“没有管理”。
(2) 自我组织: 以前做好自己的事情就好了,安心下班。现在每个人要联合起来对项目负责,有人工作落后了还要帮助他改进,项目缺少某类资源还要自己顶上去。
(3)多功能型:以前规格说明书由PM来写,测试由测试人员来做,现在每个人都全面负责,自己搞定规格说明书,和别人沟通,同时自己搞定测试。

6.4 敏捷流程的经验教训

  实践者的经验教训:
(1) 敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论。
(2) Scrum Master不是一个官,而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。
(3)一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。
(4)在复杂的项目里,要让一线团队成员做决定。
(5)创业公司的团队其实经常是运行在某种快节奏的敏捷的模式中(只不过大家太忙,没工夫论证自己到底有多么敏捷)。
(6)在Scrum计划阶段的估计不是一个“ 合同”,领导们不要把它当成-一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。
(7)不要和管理层谈“流程”,他们只关心“结果"。
(8)在大型团队、跨地区的团队,或者复杂项目中,Scrum并没有非常完美的答案,Scrum的创始人也承认这一-点"。

6.5 敏捷出现与定义

  敏捷(Agile)是一股思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论( Methodology);这些方法论又是建立在许多行之有效的最佳实践方法( Best Practices)之上的。敏捷的原则并不是从石头缝里面蹦出来的,它和前人总结的软件工程原则有着千丝万缕的联系,敏捷在互联网时代出现不是偶然的。

  • 敏捷适用范围

图6 敏捷适用范围

  敏捷不是万能的。敏捷的方法能帮助你更早地知道你是否能如期完成任务,仅此而已。敏捷的方法(迭代的方式)能帮你尽快让用户看到项目的部分价值。当你尽早交付部分价值时,也许用户对你目前交付的东西已经很满意了,这样你就不用再花时间来实现其他需求。另一种可能是,用户看到了部分系统,他们有新的需求,这样你就可以实现新的需求,而不用再浪费时间实现过时的需求了。

《现代软件工程—构建之法》第9章

9.1 PM含义及职能

职位名称 具体职能
Product Manager:产品经理—正确地做产品。 互联网产品涉及到方方面面:产品定位、市场发展、需求分析、运营、营销、市场推广、商务合作。产品经理横跨这些部门,寻找资源,持续推进产品。核心要求是,根据市场和用户需求,协调各部门资源,正确地把握产品定位和方向,解决用户的痛点,持续优化产品。
Project Manager:项目经理正确地做流程。 对项目流程负责,即项目从立项到上线按时完成。正确地协调团队内部外部,调配各部门资源和时间,有效进行风险管理,保证一个项目顺利按计划结项,是一个项目经理的核心价值。
Program Manager:微软的职位名称。 负责除产品开发和测试之外的所有事情。从某种意义上说,是前面两种角色的综合。

9.2 PM的出现让团队内部的互动出现了两个新特性:

(1) 负责一个功能的开发/测试人员和相关的PM密切合作,再由PM代表这一小组去和
别的小组或客户代表打交道,大大降低了交流的成本;
(2) 有专人负责开发/测试之外的许多事务和项目进度的管理,让开发和测试人员专注于技术方面的工作。

9.3 微软公司PM分类

分类 职能
有做功能设计的PM 有些功能或产品需要深入掌握各个计算机科学分支的专业知识才能做好。例如 Visual Studio中的各种计算机语言、框架、TFS的项目的项目经理,sQL Server、Windows Server、Azure、Bing Search核心算法等团队的PM
有商业和客户了解的PM 有些PM需要对商业和客户有很强的了解能力,例如 Office办公软件的PM
有广泛经验和知识面,具备商业拓展能力的PM 有些PM需要具备广泛的经验和知识面,以及商业拓展能力,例如互联网MSN部门的PM
有些是驱动流程的PM 例如推动几百人的团队完成一个版本的开发,又如保证
Windows Phone在能在几十种不同硬件上发布
让软件国际化、本地化的PM 专门深入某一领域的PM例如负责软件的国际化/本地化(Globalization/Localization)
做技术转化的PM 还有和研究人员合作,琢磨如何将前沿技术引入主流产品,做技术转化的PM

9.4 Program Manager和Project Manager的区别?。

Project Manager Program Manager
是团队的行政领导,带领大家在项目中工作 和大家平等工作,推动团队完成软件的功能
通常是团队和外界打交道的唯一代表 一个团队可以有很多PM
对项目的功能有最后的决定权 和其他团队成员一起形成决议
管事也管人 管事不管人
不一定做具体工作 一定做具体工作

9.5 成为一个合格的PM,需要哪些能力呢?

能力 具体实现
观察、理解和快速学习能力 PM要能够在一个新的领域中很快上手。PM要能理解用户,能站在用户的角度上考虑问题,观察发现用户不善于表达的需求,体察团队成员的言外之意,倾听老板/客户/利益相关人的弦外之音。要有能够理解别人的处境、心理、动机的能力—─同理心。一个PM平时或许能玩转很多高技术的工具,但是当工作需要时,他/她能突然把自己变成一个完全不懂技术的菜鸟用户,从用户的角度来看问题。
分析管理能力 每天项目中发生的事情千头万绪,PM要能够分析出重点,找到优先级,做判断、做决定
一定的专业能力 PM的专业就是理解和表达,你能否理解不同人的心理、需求和言外之意?你能否借助文字、图表、草图,甚至代码来清晰准确地表达自己的想法?PM要始终能满怀激情地向用户兜售产品。PM通常也能写代码,能玩转Excel、PPT、Visio、甘特图,会PS,有文字功底,写的博客有人爱读。还要有大量的阅读,对IT行业、用户心理、社会都要有广泛的了解。
自省的能力 失败之后要有自省和自我改进的能力。

9.6 在一个项目中,PM 的具体任务是什么呢?他们的任务是:

(1) 带领团队形成团队的目标/远景,把抽象的目标转化为可执行的、具体的、优美的设计;
(2) 管理软件的具体功能的生命周期(需求/设想/设计/实现/测试/修改Ⅰ发布/升级/迁移/淘汰);
(3) 创建并维护软件的规格说明书,让它成为开发/测试人员及时准确的指导,而不是障碍;
(4) 代表客户和用户的利益,主动收集用户反馈,预期用户新的需求。协调并决定各种需求的优先级;
(5) 分析并带领其他成员对缺陷/变更需求形成一致意见,并确保实施;
(6) 带领其他成员确保项目保持功能/时间/资源的合理平衡,跟踪项目进展,确保团队发布令客户满意的软件;
(7) 收集团队项目管理和软件工程的各种数据,客观分析项目实施过程中的优缺点,推动项目成员持续改进,从而提振士气。
过程创新可能超越产品创新,但两个创新并驾齐驱则胜于任何一个。

9.7 风险分类:

风险的类别 风险的来源
人员 客户,最终用户,利益关系人,项目成员,合作伙伴。
流程 项目的预算,成本,需求。
技术 开发和测试工具,平台,安全性,发布产品的技术,与我们产品相关的技术。
环境 法律,法规,市场竞争环境,经济情况,技术大趋势,商业模式,自然界。

团队讨论协作学习任务1学习内容的讨论截图

  • 采用企业微信群进行学习讨论

点击更多




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

选择 C 软件案例来进行分析:

C)现在学习资料很多,但是很多同学在学习新技术的时候还是很茫然,有没有更好的学习路径? 大家可以体验一下“CSDN技能树”,这个软件包含了很多IT技能的学习资料(文章、课程)和练习题,可以边学边练,解锁全部知识点后,还可以获得一枚勋章,活动链接:https://bbs.csdn.net/topics/605609934。
作为核心用户,CSDN技能树是否满足你们对类似软件产品的期待? 你们发现这些技能树有什么亮点?这个软件产品状态离预期还差哪些方面?
推荐评测以下CSDN技能树:
Python 技能树:https://edu.csdn.net/skill/python
CS入门技能树:https://edu.csdn.net/skill/gml
C 语言技能树:https://edu.csdn.net/skill/c

  • 记录每位成员使用的时间和时长
团队成员 使用总次数 使用总时长(小时)
张圆圆 8 0.5+0.4+0.6+0.5+0.6+0.7+0.6+0.7=4.5
孙得弘 6 0.5+0.6+0.4+0.5+0.7+0.8=3.5
姜婷 7 0.6+0.5+0.6+0.5+0.4+0.8+0.6=4

团队调研与评测

  CSDN技能树,为需要学习Python,Java,C,CSS等IT知识的用户提供了一个很好的学习平台,其学习内容众多,包含了很多IT技能知识点的学习资料(文章、课程)和练习题,可以边学边练,还可一边学习相关知识点,一边在界面“我的笔记”区域记下相应知识点的笔记,在查看学习相关资料时,遇到不理解或者感到困惑的问题,还可在评论区留下自己问题,与众多用户一起讨论与交流,学习解决不明白的知识点,也可查看他人留下的评论,为他人所提出的问题给出自己的建议和看法,使得学习更加有趣高效。

  • 调研过程
    • 测试环境
      手机客户端:EMUI9.0.1
      PC网页端 :Windows 10 (64位)
    • 使用过程
      • 网页端
          以C语言技能树使用为例,主界面左侧有C语言技能树的相关知识点的目录,便于用户按照自身需求查看对于知识点,中间为所罗列的详细知识点界面,选择所要进行学习的章节,点击“开始学习”或者点击所要学习的知识点即可进入学习界面。

图7 技能树主界面
  在知识点主界面,主要分为三大部分,左侧为所学习技能树的目录结构,中间为所提供的学习资料详情,中间部分的上方菜单栏包括参考资料, 练习题,评论讨论,笔记功能四个部分,用户可一边查看资料,一边在“我的笔记”区域做相应的笔记,在查看完相应的学习资料后,还通过练习题来检测自己的学习成果;若有什么不懂的地方,还可在“交流讨论”区域求助其他用户,共同学习解决问题。

  将参考资料与“我的笔记”放在同一界面,这样的设计非常好,可在查看学习资料时,一边看参考资料,一边做笔记,对用户而言十分方便,而且笔记还可插入图片,还可进行预览,保存自己学习笔记后,可方便日后查看,这使得学习效率大大提高,也可点击中间上方菜单栏的“笔记”查看其他用户的笔记,提供了另一个学习途径。


  在练习题界面,题目大多是选择题,根据题目描述选择相应的答案即可,值得一提的是,选择题的选项都是随机的,在做完一题但并未回答正确时,选项的顺序会发生变化,这就使得用户在下次做这一题时会更加深入的思考,而不是一个一个去猜测答案。如下图所示,根据题目描述,选择相应的答案后,点击“提交”即可:


  在完成练习题的提交后,可实时查看结果,若还存在疑问,可点击“参与讨论”与其他用户一起讨论交流:


  • App端
      在手机CSDNAPP中使用CSDN技能树与网页端使用过程差异不大,主要使用差异总结如下所示:

    • 在网页端可边看资料边做笔记,对于用户而言更为方便,而在手机客户端CSDN技能树似乎没有这个功能,也无法查看其他用户的笔记。
    • 在手机客户端CSDN技能树中,选中知识点后,进入参考资料界面,罗列有多个参考资料(博客),用户可自主选择,但在网页端似乎没有这个选择功能,用户无法自主选择查看其他参考资料。
  • 汇总CSDN技能树所解决问题
    (1)CSDN可以用来学习,不仅能学习很多基础的东西,也能学习一些进阶性的知识,并且能在线答题来巩固自己所学的知识,提高自己的编写代码的能力。
    (2)CSDN对我们的职业发展也是有帮助的,它有人力资源的服务,能够在这里求职或者是寻找需要的人才,并且市场有高科技产业里面的猎头公司在这里发现人才,给我们提供了机会。
    (3)用它来学习和交流非常不错,这点是值得肯定的,但对于有些人来说就不一定好用,所以关键是看自己怎么用,以及需要用CSDN来做什么。
    (4)CSDN 技能树以博客的形式给用户提供了零基础快速学习新技术的机会。
    (5)用户可以通过讨论区进行交流,提出问题。在看完教程博客后,还有一些习题帮助巩固复习。与同类型的平台相比(如菜鸟教程),这样的练习题是十分重要的。

  • CSDN技能树所存在问题

    • 技能树界面目录显示存在问题:在网页端进入CSDN技能树界面时,若浏览器页面浏览大小设置不统一,就会出现如下图所示的界面显示问题,对用户而言,使用并没有问题,只是界面显示不太美观,可进行适当的调整。


    • 技能树练习题目过于单一:在多次测试使用CSDN技能树后,发现其参考资料个数较多,用户可供选择很多,但是在学习完相关知识点后,对知识点通过练习进行巩固时,只有几道题,并且都是通过选择题的形式,学习效率不高。

  • 优缺点
      首先,技能树在网页端十分难找。或许是由于它还相对处在一个内测的状态。但在手机客户端,技能树却非常好找。其次,当前技能树有不少的错误,反馈也得不到及时的回应。此外,练习题以选择题为主,质量并不高。对新手来说,尤其是一门语言的新手,编程题绝对是最重要的。希望能引进一部分优质的编程题,并提供评测,帮助用户提升。练习题只有选择题的形式,对于讲求实践的计算机科学来说有些乏力。其余优缺点具体描述如下所示:

数据量 界面 功能 准确度
优点 一般能都到自己想找的内容 界面干净、简单、整洁 (1)写博客的功能比较完善
(2)速成课程和实战类课程居多
(3)没有闪退等情况
准确度较高,搜索显示内容覆盖所需要的词汇
缺点 现有知识点覆盖不足,存在部分博客内容不行。有些bug求解找不到 首页推广有些内容不是最新研究方向。内容不够前沿。 (1)网页版广告较多,app里虽然没有硬广,但有软广
(2)app启动速度较慢
(3)太多付费功能
没能覆盖所有编程问题
  • 用户体验
      页面简洁,评论区功能也可以解决很多问题。点进页面以后,与我想象不同的是:CSDN技能树并不是一棵树,而是将与某个语言有关的领域分了个类,每个领域下有小知识点,每个小知识点中有若干博客用以学习。对于”技能树“这一概念挖掘的不够到位。我认为”技能树“代表着,每个技能是一个节点,节点内存储了这个技能的有关知识,并且用户可以清晰地看到我想要掌握的某一项技能的前置要求是什么,当发现自己还需要掌握某一项前置技能是,可以方便的点击进入前置结点进行学习。另外,我认为技能树的某一结点首先应该向用户展示这一技能的介绍以及学习框架,而不是直接啪啪啪把要掌握的东西一下子甩给用户 。

Bug

  1. 页面右边出现异常白边
  • 测试环境:Windows11,Chrome 99.0.4844.74

  • 复现性:必然发生

  • 复现步骤:

  进入某个技能树的主页面,例如https://bbs.csdn.net/skill/python。将浏览器宽度收窄,直到下方出现左右拖动条,将拖动条向右拖动,即出现此bug。
注:在https://bbs.csdn.net/skill/practice/python-3-27/56?typeId=17410&language=python这种题目页面中也存在同质bug。目前还没有在其他页面发现此bug
描述:假设收窄浏览器后,默认会显示原来页面的从左边开始30%的内容,那么当向右拖动,右边70%的主体内容都会被白色方块覆盖
如下图


  • 分析可能的成因:

  可以看出,这个白色方块的“层级”位于主题内容、导航栏下部标识线之上,但是位于导航栏内容之下,因此不是浏览器的问题,而是前端工程师手动设置的什么东西。
网站的逻辑是:当浏览器宽度较大时,页面内容采用相对位置排版,随浏览器宽度改变而改变。当浏览器宽度小于一个阈值后,采用绝对位置排版,不再改变内容的位置。
当切换为绝对位置排版时,该网站抛弃了浏览器自己的左右滑动,而在页面底部自己设置了一个左右滑动按钮,使用该按钮就可以让没有被白块遮挡的部分左右滑动。但只能当页面滑动到最底端是才可以。
  可能前端在实现上述功能的时候,由于不明原因抛弃了浏览器的所有滑动按钮,又在某个地方需要用到一个白色的从顶到底的色块,但是却没有做好相对位置排版到绝对位置排版的切换,从而出现了该bug。
2. 最新收录页面的帖子点不进去

  • 测试环境:Windows11,Chrome 99.0.4844.74

  • 复现性:必然发生

  • 复现步骤:

  进入某个技能树的某个模块内,如https://bbs.csdn.net/skill/gml/gml-e67e64c1c880432ab6bc1b0452124ec0?category=636,右侧出现“最新收录”模块,里面有许多帖子,点击某个帖子,网站毫无反应。

  • 描述:

  • 分析可能的成因:

  HTML开发者和JS开发者接口出现问题,导致点击后无法正确的执行页面跳转

推荐用户使用CSDN及采访记录

  • 介绍所推荐用户的背景和需求
    背景:理工科学生,编程小白,初步了解编程,对IT知识不熟悉
    需求:目前学习Python课程,需要采用Python完成课程作业
  • 上传用户使用CSDN技能树的照片


  • 概述用户使用CSDN的过程, 评判用户的问题是否解决
      用户下载CSDN并注册,在手机客户端使用CSDN中的Python技能树,了解了其参考资料练习题评论讨论功能,在查看Python面向对象编程思想学习资料后,做了相应练习题,还在讨论区参与了讨论;后又在CSDN网页端查看了Python技能树,发现了可一边查看资料,一边做笔记的功能,并在查看Python面向对象编程思想学习资料时,对其做了相应笔记。
    在用户的多次使用过程中,用户所要求解的问题基本解决。
  • 用户采访记录

点击查看更多




  • 用户所提出建议
      CSDN技能树题目过于单一简单,应该适当添加其他类型题目,对于编程类型的题目,应该适当的添加一些代码测试的题目,不应只是单一的选择题,评论区功能挺好,但是高质量评论过少,不利于学习,可适当发表一些高质量评论,或者对一些评论进行审核。

分析与建议

同类对比分析

国内技术社区 优缺点
博客园 优点:csdn页面更精致,页面跳转逻辑更清晰。
缺点:缺乏更多的自定义设计
菜鸟编程 优点:有更好的体验,可以随学随记笔记。增设讨论区,更具学习互动性
缺点:只是覆盖面没有菜鸟的广清晰。
牛客网 优点:只是讨论更广泛,氛围更活泼。
缺点:缺少代码测试部分,不能进行刷题。

  当今社会,计算机技术对各个领域都有着十分重要的作用。许多零基础的人,需要学习计算机技术,这个市场看似是非常大的。我们的技能树,正是给零基础学习计算机的人提供帮助的。
  到处,都能看到广告,零基础的人学个 Python,就能怎么怎么样。很多职场白领,可能此前从未接触过任何的计算机培训。但在工作中,掌握一些计算机技能,确实能实质性地提升他们的工作效率。这样的人群,绝不在少数。

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

记录完成《实验五 团队作业2:软件项目案例分析》各项任务实际花费的时间

任务内容 计划共完成的时间(min) 实际完成时间(min)
团队讨论协作阅读学习《现代软件工程—构建之法》第5章内容 60 70
团队讨论协作阅读学习《现代软件工程—构建之法》第6章内容 50 60
团队讨论协作阅读学习《现代软件工程—构建之法》第9章内容 65 70
团队成员测试使用CSDN软件 350 370
推荐朋友测试使用CSDN软件并记录相关体验感受 240 270
团队博客编写 300 350
本次作业反思及总结 35 40

本次作业的感受和体会

团队成员 本次作业的感受和体会
张圆圆 在此次团队作业中,以团队协作学习方式,学习了《现代软件工程—构建之法》第5、6、9章内容,理解并掌握了软件项目团队的特点和模式、学习并理解了瀑布模型及其变形、渐进交付流程、敏捷流程等典型软件过程模型特点,对TSP原则也有了更深入的理解和体会;了解了软件项目团队设置项目经理的缘由,对于项目经理的职责也有了清晰的认识;通过对CSDN技能树的初步测评使用,发现了其优点所在,涵盖多个技能知识点,对于初步想学习C,Java,Python等技能的用户提供了一个很好的平台,不仅可以学习相关知识点,在学习可边看边记笔记,还可通过每个知识点对应的习题来巩固所学过的内容,功能齐全,但经过多次使用测试,也发现了其待改进之处,对于用户来说仍存在一些问题,如界面使用不太流畅,题目过于单一等问题,这也使得我们要在以后的编程项目过程中,要更加深入地从用户的角度出发,考虑项目所要实现的功能效果,可使得软件项目更加完善。
姜婷 学习了《现代软件工程—构建之法》第5、6、9章内容。第九章主要讲了PM项目经理。项目经理大概是做除了写代码和测试外的所有。项目经理的作用:项目经理可以使团队协作中的交流成本降低,让负责开发的人员更专注于写代码。但是项目经理在整个项目团体中与大家地位平等,并不存在谁高谁低的上下级关系,而是和团队成员一起决议。并且项目经理管事不管人,他对项目是否完成负责。一个好的项目负责人所具备的能力还怪多的,要有观察理解能力,还要有分析管理能力,而且还得有点专业能力知道开发人员在开发什么等等等等。通过小组分工合作,分工完成各项目标。期待未来的合作,希望我们每个小组成员互相竞争合作实现学习目标,促进个人编程技术成长以及团队协作技巧。
孙得弘 学习了软件开发的团队合作模式,团队合作对于一个团队软件开发十分重要,只有选择合适的团队开发模式才能更加高效的进行团队的软件开发,这对于一个团队来说十分的重要
posted @ 2022-04-15 14:02  Typhoon-Team  阅读(106)  评论(0编辑  收藏  举报