踏马逐尘 实验二：软件研发团队组建（团队作业）

任务1：组建软件项目研发团队

1. 团队名称

• 踏马逐尘

2. 团队成员组成

3.成员风采

4.组建团队企业微信群

5.团队特色描述

• 合作紧密： 我们在很多其他课程也在同一个小组，彼此之间合作紧密，互相协作，共同完成任务。
• 相互信任： 我们之间非常熟悉，建立了相互信任的关系，可以自由地表达自己的观点和想法，共同讨论问题。
• 技能互补： 我们具备不同的技能和知识，能够互相学习和补充，使得团队更加完整和强大。
• 善于沟通： 我们善于沟通，能够清晰地表达自己的意见和想法，也能够认真倾听他人的意见和想法。
• 精益求精： 我们追求卓越，不断改进自己的工作并互相帮助，精益求精，追求更好的成绩。

任务2：申请开通团队博客

• 已开通团队博客,并加入了班级博客。

任务3：阅读《现代软件工程—构建之法》第5、6、9章内容，总结以下概念与问题：

1. 团队软件过程（Team Software Process,TSP）

 团队软件过程是为开发软件产品的开发团队提供指导,TSP的早期实践侧重于帮助开发团队改善其质量和生产率，以使其更好的满足成本及进度的目标。TSP被设计为满足2~20人规模的开发团队，大型的多团队过程的TSP被设计为大约最多为150人左右的规模。团队软件过程(TSP)加上PSP帮助高绩效的工程师在一个团队中工作，来开发有质量保证的软件产生产安全的软件产品，改进组织中的过程管理。通过TSP，一个组织能够建立起自我管理的团队来计划追踪他们的工作、建立目标，并拥有自己的过程和计划。这些团队可以是纯粹的软件开发团队，也可以是集成产品的团队，规模可以从3到20个工程师不等。TSP团队在广泛领域里可能运用XP,RUP或其它方法。TSP使具备PSP的工程人员组成的团队能够学习并取得成功。如果你的组织运用TSP它会帮助您的组织建立一套成熟规范的工程实践，确保安全可靠的软件。

2.理解TSP原则

在软件开发(或维护)过程中，首先需要按照群组软件过程框架定义一个过程。在设计TSP过程时，需要按照以下7条原则:

• 循序渐进的原则,首先在PSP的基础上提出一个简单的过程框架，然后逐步完善：
• 迭代开发的原则,选用增量式迭代开发方法，通过几个循环开发一个产品；
• 质量优先的原则，对按TSP开发的软件产品,建立质量和性能的度量标准;
• 目标明确的原则，对实施TSP的群组及其成员的工作效果提供准确的度量;
• 定期评审的原则, 在TSP的实施过程中，对角色和群组进行定期的评价；
• 过程规范的原则，对每一个项目的TSP规定明确的过程规范；
• 指令明确的原则，对实施TSP中可能遇到的问题提供解决问题的指南。

3.敏捷开发的原则
敏捷开发的原则是一种快速、灵活、高效的软件开发方法,它强调团队合作、快速反馈和不断改进。在敏捷开发中，开发团队通过选代、增量的方式来开发软件,每个迭代都会产生可用的软件产品,这样可以让客户更快地看到软件的效果，同时也可以让开发团队更快地发现和解决问题。
 敏捷开发的原则包括以下几点:

• 个体和交互胜过流程和工具
  在敏捷开发中，个体和交互比流程和工具更重要。这意味着开发团队应该注重人与人之间的沟通和协作，而不是过度依赖流程和工具。
• 可以工作的软件胜过详尽的文档
  在敏捷开发中，可以工作的软件比详尽的文档更重要。这意味着开发团队应该注重软件的实际效果，而不是过度依赖文档。
• 客户合作胜过合同谈判
  在敏捷开发中，客户合作比合同谈判更重要。这意味着开发团队应该与客户密切合作，了解客户的需求和期望，而不是过度依赖合同。
• 响应变化胜过遵循计划
  在敏捷开发中，响应变化比遵循计划更重要。这意味着开发团队应该能够快速适应变化，不断调整开发计划，而不是过度依赖计划。
  敏捷开发的原则可以帮助开发团队更快地开发出高质量的软件产品,同时也可以让客户更快地看到软件的效果。在实际开发中，开发团队应该注重团队合作、快速反馈和不断改进，不断优化开发流程,提高软件开发效率和质量。

4.scrum敏捷流程
Scrum是敏捷里最具代表性的方法论！这个方法论里由三种角色和四种会议组成：

三种角色：

• Product Owner：产品负责人；主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
• Scrum Master：类似于项目负责人；保护团队，兼顾产品经理的需求，确保项目的按时交付。
• The Team：开发测试团队。
   敏捷团队的总人数要控制住7–11人之间，不能过多。

四种会议：

• Sprint Planning Meeting：冲刺计划会议；整个小组按优先级将用户故事从Product Backlog中移入到Sprint Backlog，表示整个小组承诺本迭代要做完的任务。做完的标准是测试通过，除非此任务不可测试。
• Daily Scrum Meeting：每日站会；冲刺阶段，小组成员每天都要在站会上讲一下自己昨天做了什么，今天准备作什么，大概什么时候完成，以及遇到了什么问题。
• Sprint Review Meeting：冲刺评审会；一个冲刺完成后，小组需要演示阶段性成果，并评审该成果是通过还是不通过。
• Sprint Retrospective Meeting：冲刺复盘会；小组成员轮流发言，复盘所遇问题、成本偏差、协作过程，提炼做得好的和需要改进的地方，并制定改进计划；这个时候PO还会根据收集到的用户反馈、上线数据，大家一起探讨优化方案，大致规划下一个Sprint，以便成员们提前准备。
  步骤一：找出完成产品需要做的事情——Product Backlog（积压的工作，待解决的问题）。对Backlog中的条目进行分析、细化、理清相互关系、估计工作量等工作。每一项工作的时间估计单位为“天”。
  步骤二：决定当前的冲刺（Sprint）需要解决的事情——Sprint Backlog。整个产品的实现被划分为几个互相联系的冲刺，Product Backlog上的任务被进一步细化了，被分解为以小时为单位。
  步骤三：冲刺。冲刺阶段，外部人士不能直接打扰团队成员，一切交流只能通过Scrum Master来完成，这以措施较好地平衡了“交流”和“集中注意力”的矛盾。任何需求的改变都留待冲刺结束后再讨论。 冲刺期间，团队成员通过“每日立会”进行面对面交流，依次报告：我昨天做了啥；我今天要做啥；我碰到了哪些问题；
  燃尽图（Burn Down Chart）：逐渐把一堆Backlog烧光，呈现向下趋势线条；
  看板图（Kanban）：把一堆任务从最初“待定”推动到“工作中”等各个状态直至“完成”。任务状态一目了然。
  步骤四：得到软件的一个增量版本，发布给用户。然后在此基础上又进一步计划增量的新功能和改进。

5. 团队项目经理（Product Manager，PM)的职责。
 Product Manager：产品经理——正确地做产品。产品经理对一个或多个产品或产品线负责，而互联网产品设计到这些方方面面：产品定位、市场发展、需求分析、运营、营销、市场推广、商务合作。产品经理横跨这些部门，寻找资源，持续推进产品。随着产品的发展，不同公司，对PM要求会不一样。核心要求是，根据市场和用户需求，协调各部门资源，正确地把握产品定位和方向，解决用户的痛点，持续优化产品。
能力要求：
 1.观察、理解和快速学习能力
 2.分析管理能力
 3.一定的专业能力
 4.自省的能力
任务：
 1.带领团队形成团队的目标/远景，把抽象的目标转化为可执行的、具体的、优美的设计；
 2.管理软件的具体功能的生命周期。
 3.创建并维护软件的规格说明书，让它成为开发/测试人员及时准确的指导，而不是障碍；
 4.代表客户和用户的利益，主动收集用户反馈，预期用户新的需求。协调并决定各种需求的优先级；
 5.分析并带领其他成员对缺陷/变更需求形成一致意见，并确保实施；
 6.带领其他成员确保项目保持功能/时间/资源的合理平衡，跟踪项目进展，确保团队发布令客户满意的软件。
 7.收集团队项目管理和软件工程的各种数据，客观分析项目实施过程中的优缺点，推动项目成员持续改进，从而提振士气。

完成实验二各项任务实际花费的时间

团队成员的感受体会

本栏目推荐文章
• 多项式定积分计算软件2025 64位WIN版下载Polynomial definite integral calculation software 2025 64 bit WIN version download
• Mac上运行windows软件-GPTK
• 软件构造大作业 综合信息管理系统
• 成绩管理系统软件体系结构设计说明书
• 【GUI软件】抖音搜索结果批量采集，支持多个关键词、排序方式、发布时间筛选等！
• 软件架构实践 V2：第二章
• 软件测试
• Parallels Desktop 19：强大与便捷并存的虚拟机软件
• 软件测试报告模板
• 软件测试/测试开发全日制|Pytest中yield的用法详解