发际线与你们作队 实验二：软件研发团队组建(团队作业)

项目	内容
课程班级博客链接	2020卓越工程师班
这个作业要求链接	实验二 软件研发团队组建
团队名称	发际线与你们作队
我的课程学习目标	1.组建软件工程开发团队 2.分配团队分工，了解核心成员技能 3.完成实验内容，加强团队交流
这个作业在哪些方面帮助我实现学习目标	1.确定开发团队创建博客，成员之间相互交流技术，共同进步 2.阅读《现代软件工程—构建之法》,完成相关任务
团队博客链接	发际线与你们作队

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

1.团队名称： 发际线与你们作队

2.团队成员组成

成员学号	成员姓名	个人博客地址	备注
202031607232	张玉国	张玉国的博客地址	PM
202031607231	马全财	马全财的博客地址
202031607204	潘成荣	潘成荣的博客地址
202031607224	邓思超	邓思超的博客地址

3.成员风采

成员	代码风格	擅长技术	编程兴趣	软工角色	宣言
张玉国	逻辑结构清晰	Java后端开发、数据库设计	软件工程	PM	我是掌门人
马全财	命名规范、有良好的注释习惯	网页布局、移动Web	人工智能	测试	不要伤害我家哥哥
潘成荣	代码整齐统一，精简易懂	python编程开发	后端开发	文档	坚持就是胜利
邓思超	代码精简、耦合度低	c++编程开发	计算机算法理论	开发	少些代码多些头发

4.团队企业微信群

5.团队特色描述：

团队成员擅长技术领域各不相同，可在实践中相互学习。

任务二 申请开通团队博客

已顺利完成团队博客申请，博客地址为：发际线与你们作队

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

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

个人见解:
1. 团队软件过程的目标:
TSP(Team Software Process)是针对团队开发过程的管理。它提供一个可操作的流程以帮助团队以提高产品质量、加快产进度为目标
2. 团队软件过程的定位:
TSP应用于软件开发，他要求团队开发，每位成员有着共同的目标；每个团队成员扮演着不同的角色，在小组分工中有不同的分工，完成整体项目中的每一项任务都需要其他成员的支持。
3. 团队软件过程的效果:
大大提高了软件开发的整体速度，管理难度，在保证了工程质量的同时，让团队中的每一个人都参与到工程中，这指导了团队开发的目标。
4. 团队软件过程的特点:

1. TSP的早期实践侧重于帮助开发团队改善其质量和生产率，规模大小不一，以使其更好的满足成本及进度的目标。
2. TSP团队在广泛领域里可能运用XP, RUP或其它方法。TSP使具备PSP的工程人员组成的团队能够学习并取得成功。

2. 理解TSP原则

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

3. 敏捷开发的原则

1. 我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
2. 即使在项目开发的后期，仍然欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 在项目过程中，业务人员要和开发人员每天在一起;
5. 要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
6. 团队内部和各个团队之间，最有效的方法是面对面的沟通。
7. 可工作的软件是衡量进度的首要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发方人员和用户应该能够保持恒久、稳定的进展速度。
9. 对技术卓越和好的设计的持续关注有助于增强敏捷性。
10. 尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自自组织团队。
12. 团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。

4.Scrum敏捷流程

1. 需求规划

PO会将利益相关者们的需求以及自身想法转化为具体的用户故事，接着进行需求规划：与利益相关者了解需求价值，放弃伪需求和无价值需求，将价值需求放入Product Backlog（需求池）；和敏捷团队沟通需求规模（实现难度与时长），以需求的价值和规模做为判断依据，对需求池内容进行优先级排序；必要时，还会将需求拆解为多个子需求，单个子需求具备能在一次sprint迭代中实现的可能性。

通常项目早期，或者并非卓越超群的团队，对于需求的判断多是不准确的；更多的是在需求池内相对的比较选择，快速产出投入市场，在反馈中得到验证与矫正，并在此过程中提升团队能力，这也正是敏捷的价值所在。

2. Sprint计划会议（Sprint Planning Meeting）

每次迭代一般都是从计划会议开始，为确保开发质量与效率，我们通常会根据团队的开发速度，将需求池内容制定到迭代计划中，一次迭代大概解决4~6个需求（视具体情况而定）；计划会议针对本次迭代范围，进行需求评审，并将一个需求拆解为多个任务，明确每个任务的目标和验收标准，以及任务估算排期，产出一份Sprint Backlog（任务列表）。

这里值得一提的是需求规划和需求评审的区别，前者由PO主导，涉及商业、市场、运营，更像是范围层“我们做什么，不做什么”；后者由PM主导，涉及业务逻辑、产品架构、产品设计、功能实现、用户体验设计，更像是结构层“如何构建，如何连接”。

比如PO提出一个用户故事，孩子的多个家长都可以实时收到孩子的学习情况，需求规划会对该需求价值、规模进行评判：其投资回报率及产品当前阶段，我们现在是否要实现这个需求。

PM根据这个需求细化，是通过Push通知、短信通知、弹窗通知还是信息提示？包含学习时长、测试成绩、能力分析模型、老师评价等哪些功能?需求评审会对这些实现需求基于用户体验、技术层面进行评判：其实现方式、可行性、疑难点、潜在风险，我们如何去落地实现这些需求或者部分需求。

3. 每日站会（Daily Scrum Meeting）

项目进入开发阶段，设计、开发、测试按照计划展开工作。

每天早上展开一个15分钟的站会来跟进项目进度，每个人都说说自己昨天的任务及完成度、今天的待办任务，确保迭代计划的正常进行；遇到了什么问题及背后原因，是否会影响其他关联任务或其他成员，以及是否需要帮助，确保及时规避风险。

每日 Scrum 站会增进团队间的交流沟通、发现开发过程中需要移除的障碍、促进快速决策、提高团队的认知程度，这是一个进行检视与适应的关键会议。

4. 需求变更

需求变更是在所难免的，我们要“响应变化高于遵循计划”；若发生紧急变更，我们从开发成本进行考量，是在本次完成还是将部分任务延后到下一次迭代，以确保本次迭代能如期交付；若发生重大变更，我们需要进行团队会议讨论解决方案。

随着时间变化，问题发现、需求新解、任务完成，我们会对Sprint Backlog进行不断地调整修改。

5. 测试验收

对已完成开发的功能进行可用性、易用性、体验度、还原度等一系列测试验收，发布通过测试的部分、修复未通过部分；注意敏捷开发中的测试并非完成本次迭代所有开发任务才测试，而是完成一个测试一个，及时地发现问题解决问题。

6. Sprint评审会议（Sprint Review Meeting）

在迭代快结束时举行Sprint评审会议 ，敏捷团队演示这次迭代完成的工作（Demo演示），讨论当前Sprint Backlog情况、做的好的地方、遇到什么问题及如何解决的，并解答相关问题；然后PO、利益相关者、敏捷团队一起探讨接下来可能要做的事情，评审市场变化或竞品新动向将会对我们造成什么影响；这并不是一个单纯进度汇报会议，目的是为了获取反馈并促进及时调整。

7.Sprint回顾会议（Sprint Retrospective Meeting）

每次迭代结束后需要进行一次回顾会议，复盘所遇问题、成本偏差、协作过程，提炼做得好的和需要改进的地方，并制定改进计划；这个时候PO还会根据收集到的用户反馈、上线数据，大家一起探讨优化方案，大致规划下一个Sprint，以便成员们提前准备。

我们个人需要做的是将本次迭代经验总结，积极地向成员们分享你所学到的知识及方法技巧，沉淀为团队知识库、方法论，复用到日后的迭代中去。

5. 团队项目经理（Product Manager，PM)的职责

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

任务四 完成《实验二：软件研发团队组建（团队作业）》博文作业

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

• 完成各项任务花费的时间

任务内容	预计花费时间	实际花费时间
确定团队	10	10
创建企业微信群	2	2
创建博客园团队博客	10	20
完成任务三	120	150
博客撰写	90	100
反思和总结	30	20

团队各位成员谈谈完成本次作业的感受和体会。

邓思超：
本次实验的实验内容正好包含了团队软件过程的知识点，因此本次的团队创建更像是一种对知识点的实践，通过初步建立软件开发小组，互相协商完成本次作业我们也对为什么有团队软件过程有了更深一步的理解，希望在接下来的学习中能够进一步加强团队合作，再接再厉。
张玉国：
本次实验是第一次创建团队之后的实验，我们团队在和谐、合理的前提下完成各自的分工，也是对于之后的团队开发项目的起到了铺垫的做用，总体来说，本次实验的收获还是很大。
马全财：
本次实验体会了第一次团队合作，加强了组员之间的交流，为之后进行项目开发打下了坚实的基础。其次，在学习构建之法的过程中学会了项目开发的基本流程， 了解了团队开发的要求，加深了对软件工程的理解。
潘成荣：
本次实验完成了团队的组建和团队成员的分红，在本次作业中，通过查看构建之法教材，对于团队软件过程有了初步的了解，以及对于敏捷过程有了再次的认识等。团队组建为后续实验项目的完成奠定基础，收获颇多。