| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | 班级博客链接 |
| 这个作业要求链接 | 作业要求链接 |
| 团队名称 | upower队 |
| 团队的课程学习目标 | 1.建设团队，开通团队博客 2.通过团队学习，一起研发项目，完成项目 3.在项目研发过程中，团队成员一起协作，互相学习，一起提高，共同发展，共同进步 4.团队成员中互相了解，能够进行扬长避短，能够了解项目开发的各个过程 |
| 这个作业在哪些方面帮助团队实现学习目标 | 掌握了一些知识的概念，提高了团队协作能力 |
| 团队博客链接 | 团队博客链接 |
一、实验目的与要求
（1）实验三作业互评。
（2）组建软件项目研发团队。
二、实验内容与步骤
任务1：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：
（1）对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
（2）克隆任务3项目源码到本地机器，阅读并运行代码，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
（3）阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片；
B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
C. 从职业、学历、年龄、专业、爱好、收入等方面概括实验三任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
（4）经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
（5）结合（1）—（3）的评论体会，迭代改进本小组实验三的任务3。
（1）所选取进行评价的小组：
| 项目 | 内容 |
|---|---|
| 被评论作业的博客链接 | 作业链接 |
| 被评论作业的Github项目仓库链接 | 仓库链接 |
所评价小组的任务3项目源码：
（2）对所评价小组的任务3项目源码的代码复审核查表：
| 项目 | 内容 |
|---|---|
| 概要部分 | 代码符合需求、符合规格说明；代码设计考虑周全；代码可读性较好 |
| 设计规范部分 | 规定了代码规范说明书，软件设计说明书；给出了框架、接口、界面说明 |
| 代码规范部分 | 遵守给出了的代码规范说明书 |
| 具体代码部分 | 有对错误进行修改处理；参数传递没有错误；未出现死循环 |
| 效能 | 效能良好，达到了基本的任务要求 |
| 可读性 | 可读性较好；有足够的注释 |
| 可测试性 | 暂时不需要创建新的测试单元 |
（3）总结：
软件运行的界面：
任务3的具体要求功能基本实现，页面设计也很好；但从数据量来看还是比较多的。
任务3所研发软件产品的典型用户群特征：在校老师、学生。他们表面需求：能够求解折扣背包问题以及遗传算法。潜在需求：能够利用遗传算法求解折扣背包问题并实现编码开发软件。
（4）结论：好，不错。
| 操作 | 效果 |
|---|---|
| fork | 分叉、克隆 出一个（仓库的）新拷贝 |
| Clone | 使用git来进行版本控制时，为了得一个项目的拷贝(copy),需要知道这个项目仓库的地址 |
| Push | 将本地版本库的分支推送到远程服务器上对应的分支，一般形式为 git push <远程主机名> <本地分支名> <远程分支名> |
| Pull request | 参考 |
任务2：团队组建
1、队名：upower队
2、团队成员：
| 成员学号末五位 | 成员*名 | 个人博客地址 |
|---|---|---|
| 10123 | **丽（队长） | 个人博客 |
| 10115 | *北 | 个人博客 |
| 10117 | **钰 | 个人博客 |
| 10112 | **珍 | 个人博客 |
3、阅读《现代软件工程—构建之法》第7章、第17章，理解MSF的9点基本原则和团队成员绩效：
1.推动信息共享与沟通( Foster open communications )
理解：所有信息都保留并公开，讨论要保留所有要涉及的角色，决定要公开并告知所有人，宁可过分沟通也不要不沟通。
2.为共同的远景而工作( Work toward a shared vision)
理解：共同的远景是指产品的远景，即团队的领导人要让全体成员都同意并为之奋斗的项目的远景，要明确项目目标，没有二义性，必须通过努力才能达到，而且这个目标能对项目成员每天的工作都有指导作用。
3.充分授权和信任( Empower team members )
理解：成员、团队之间平等协作，所有成员或团队都应该得到充分的授权，他们有权在职权范围内按照自己的承若完成任务，同时，他们也充分信任其他同事能实现各自的承若，团队的顾客也信任团队能兑现承若，并进行相应的规划。
4.各司其职，对项目共同负责( Establish clear accountability and shared responsibility )
理解：团队中的每个角色都有自己的职责，并明确自己的职责，如果出了问题，这个角色就要负责任。与此同时，因为每个角色在其职责范围内的失败都会导致整个项目的失败，而且各个角色的工作都是互相渗透，互相依赖的，所以团队的各个角色得合起来，对整个项目最终的成功负责。在项目进展中，对于每一项任务，每个人都要明确4个W：（1）who：对谁负责；（2）做什么，具体的执行方案，什么叫做“做好了”；（3）when:什么时候开始，什么时候结束；（4）why:为什么是这样安排（和项目的远景是否吻合），在什么情况下可以变更？
5.交付增量的价值( Deliver incremental value )
理解：重视商业价值，提供渐进的价值。项目团队也是一个商业实体，我们的项目都应该出于商业目的，而商业目的需要重视市场和用户。项目实施前需要搞清楚我们的产品解决了什么问题，为谁解决问题，为什么我们的产品会解决这些问题，以及怎样才能拿到客户的报酬。
6.保持敏捷，预期和适应变化( Stay agile, expect and adapt change )
理解：软件工程，唯一不变的是变化。除开外部原因，团队内部也在变化，对技术的掌握每天都在提高，原来认为不可能的事变得容易等，所有事情都有可能在变化，这些都要求我们团队保持敏捷的身段。
7.投资质量( Invest in quality )
理解：对质量的重视，引发对质量的投资，引发人、过程和工具的投资。但投资要讲效率和时机。
8.学习所有的经验( Learn from all experiences ) 4
理解：把从自己或别人的成果和失败的例子中学到的经验总结出来，并分享经验，帮助新项目重复以往成功的做法，以及培育总结的习惯和“批评与自我批评”的文化。
9.与顾客合作( Partner with internal and external customers）
理解：产品团队要及时和顾客交流与合作，把“我觉得用户会”的东西要及早和用户交流，毕竟“我觉得”和“用户觉得”是两码事。
第17章团队成员绩效：
绩效管理的做法：
划分等级和公开刺激的做法
闷声发财的做法
好的绩效管理办法是一个团队非常重要的，在制定绩效评估办法时要考虑周全，从多个角度出发，不能光看工作时间或是完成效率。要针对我们的团队的特色制定适合我们团队的绩效评估办法。
4、阅读《现代软件工程—构建之法》第5章内容
软件团队的模式：
1.窝蜂模式：一群人直接写代码，并且希望能借此写出好软件（大型项目不现实）；
2.主治医师模式：主要核心在于首席程序员，其他成员从各种角度支持他的工作（IBM System 360项目）
3.明星模式：主治医师模式运用到极点，需要考虑团队利益最大化问题。
4.社区模式：需要严格的代码复审和签入的质量控制。
5.业余剧团模式：不同人承担不同角色。
6.秘密团队：团队内部有极大的自由，较高热情，没有外界干扰。
7.特工团队：软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而又紧迫性的问题。
8.交响乐团模式：适合某个软件领域处于稳定成长阶段的时候。
9.爵士乐模式：于交响乐团模式对立，比较强调个性化的表述。
10.功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。（很多软件公司的团队最后都成为的模式）
11.官僚模式：组织上有领导和被领导的关系
开发流程：
1.写了再改模式：
与蜂窝模式大相径庭，大家上来就写代码，写不出就直接改。
2.瀑布模型：
由别的成熟行业借用的模型转化而成软件行业的设计模型，适合于：定义非常稳定的产品，技术成熟，不能频繁交流的团队。
（1）生鱼片模型
解决了各个步骤之间分离的缺点，但仍存在不知道上一个阶段何时会结束的问题。
（2）大瀑布带着小瀑布
解决不同子系统之间进度不一的问题，用户只有等到最后才能看到结果。
3.统一流程：
重计划，重事先设计，重文档表达。
具体规程有：业务建模、需求、分析和设计、实现、测试、部署、配置和变更管理、项目管理、环境、初始阶段、细化阶段、构造阶段、交付阶段。
4.老板驱动的流程：
开发流程由公司老板驱动，适合于：软件订单靠个人关系，老板比一般技术人员更懂市场和竞争，团队尚未成熟。
存在的问题：领导技术上是外行，领导不懂得管理软件项目，精力有限。
5.渐进交付的流程
很接近迭代式开发流程，当系统的主要需求和架构明确之后，软件团队进入了一个不断演进的evolution循环中：开发→发布→听取反馈→根据反馈做改进
MVP：
由于团队在软件开发流程中要到最后才能给客户一个软件反馈，所以可先将最小可行产品开发出，来得到用户的反馈，比如先做一个IOS软件，而不是同时开发Android软件。
MBP：
适合极高水平的产品团队，把产品最全最美的形态展现出来，征服用户，比如IPHONE
任务3：团队博客作业
详情见团队博客链接
PSP流程：
| 任务内容 | 计划共完成需要的时间(min) | 实际完成需要的时间(min) |
|---|---|---|
| 计划 | 20 | 20 |
| 组建团队 | 5 | 5 |
| 创建团队博客 | 15 | 15 |
| 个人博客撰写 | 40 | 50 |
| 阅读《构建之法》 | 70 | 90 |
| 团队博客撰写 | 40 | 50 |
| 任务3项目的评价审核 | 30 | 40 |
| 总合 | 220 | 270 |
谈谈完成本次作业的感受和体会：
本次的作业首先是对别的小组完成的任务3项目进行复审项目，通过在GitHub上下载源码到本地运行测试，但要注意的是使用的运行测试环境是否符合，还需要细心的复审查找出bug。通过阅读《构建之法》对我们这次的任务完成具有辅助作用，通过阅读对团队模式、团队流程、MSF的9点基本原则、绩效管理有了了解，增长了相关知识。很值得我们去阅读的一本书。通过这次组建了upower队，希望接下去的日子里能一起协作，共同学习，体会团队组建的乐趣。