| 项目 | 内容 |
|---|---|
| 课程班级博客链接 | https://edu.cnblogs.com/campus/xbsf/2018CST/ |
| 这个作业要求链接 | https://www.cnblogs.com/-8tjj/p/14679516.html |
| 团队名称 | 这是个小队 |
| 团队的课程学习目标 | （1）学习团队软件项目流程（TSP）； （2）团队成员协作要求 |
| 这个作业在哪些方面帮助我实现学习目标 | （1）博文编写方面； （2）团队合作方面 （3）代码阅读及运行方面； |
| 团队博客连接 | https://home.cnblogs.com/u/2366082 |
任务1：浏览班级博客园中提交《实验三 软件工程结对项目》作业，任选一个你认为完成质量较高的小组项目成果，继续以实验三结对学习方式完成以下任务，具体要求如下：
（1）对博文作业进行阅读，并结合评分要求进行评论，评论要点包括：博文结构、博文内容、博文结构与PSP中“任务内容”列的关系、PSP中“计划共完成需要的时间”与“实际完成需要的时间”两列数据的差异化分析与原因探究，给出这个结对小组在进度计划方面可以提高的具体建议。将以上评论内容发布到博客评论区。
被评论作业的连接：https://www.cnblogs.com/budinge/p/14630602.html
被评论作业的Github项目仓库链接：https://github.com/budinge/Exercise-homework1
要求的博客评论：
本小组任务3的Github项目仓库链接、项目迭代改进要点说明、项目仓库的Fork、Clone、Push、Pull request、Merge pull request数据变化情况
| 操作 | 数据情况 |
|---|---|
| Fork | 分叉、克隆 出一个（仓库的）新拷贝 |
| Clone | 使用git来进行版本控制时，为了得一个项目的拷贝(copy),需要知道这个项目仓库的地址 |
| Push | 将本地版本库的分支推送到远程服务器上对应的分支，一般形式为 git push <远程主机名> <本地分支名> <远程分支名> |
（2）克隆任务3项目源码到本地机器，阅读并运行代码，找出项目代码的5个以上bug，参照《现代软件工程—构建之法》4.4.3节核查表复审项目代码并记录。
核查表复审项目代码：
| 1. 概要部分 | 代码能符合需求和规格说明么？ |
|---|---|
| 代码设计是否有周全的考虑？ | 基本周全 |
| 代码可读性如何？ | 可读性好 |
| 代码容易维护么？ | 比较容易维护 |
| 代码的每一行都执行并检查过了吗 | 检查 |
| 2．设计规范部分 | 设计是否遵从已知的设计模式或项目中常用的模式？ |
| 有没有硬编码或字符串/数字等存在？ | 没有 |
| 代码有没有依赖于某一平台，是否会影响将来的移植？ | 代码在pycharm上运行，但不依赖平台 |
| 开发者新写的代码能否用已有的Library/SDK/Framework中的功能实现？在本项目中是否存在类似的功能可以调用而不用全部重新实现？ | 存在类似功能可以调用 |
| 有没有无用的代码可以清除？ | 没有 |
| 3．代码规范部分 | 修改的部分符合代码标准和风格么? |
| 4．具体代码部分 | 有没有对错误进行处理？对于调用的外部函数，是否检查了返回值或处理了异常？ |
| 参数传递有无错误，字符串的长度是字节的长度还是字符（可能是单/双字节）的长度，是以0开始计数还是以1开始计数？ | 无 |
| 边界条件是如何处理的？Switch语句的Default是如何处理的？循环有没有可能出现死循环？ | 未发现死循环 |
| 有没有使用断言（Assert）来保证我们认为不变的条件真的满足？ | 没有 |
| 对资源的利用，是在哪里申请，在哪里释放的？有没有可能导致资源泄露？有没有可能优化？ | 没有资源泄露 |
| 数据结构中是否有无用的元素？ | 没有 |
| 5．效能 | 代码的效能（Performance）如何？最坏的情况是怎样的？ |
| 代码中，特别是循环中是否有明显可优化的部分？ | 没有 |
| 对于系统和网络调用是否会超时？如何处理? | 不会超时 |
| 6．可读性 | 代码可读性如何？ |
| 有没有足够的注释？ | 足够注释 |
| 7．可测试性 | 可测试 |
（3）阅读《现代软件工程—构建之法》第12章内容，完成以下分析任务：
第十二章：用户体验
A. 体验任务3实现软件功能，简要描述软件的使用过程，上传使用软件的照片
- 克隆源码：
B. 总结任务3要求的功能软件解决了吗？软件在数据量/界面/功能上各有什么优缺点？对该软件产品功能有什么改进意见？
- 任务三要求的功能软件基本解决。数据量和界面比较完善，遗传部分未完成。希望后面可以完成遗传那块的功能。
C. 从职业、学历、年龄、专业、爱好、收入等方面概括任务3所研发软件产品的典型用户群特征，他们表面需求，潜在需求是什么？
（4）经过（1）—（3）的工作，你们一定有充分的理由给评价作业选择一个结论: a) 非常不推荐 b) 不推荐 c) 一般 d) 好，不错 e) 非常推荐
- d) 好，不错
- 首先博文的内容完整，图文并茂，排版合理美观，基本完成实现的全部内容。从分析问题的流程图，查阅资料形成的知识储备，需求分析，软件设计说明，代码实现、核心功能代码展示，算法，测评等等步骤，都完成的很好。所以我觉得很不错，值得我们学习。
（5）结合（1）—（3）的评论体会，迭代改进本小组实验三任务3。
任务2：团队组建
阅读《现代软件工程—构建之法》第5章内容
团队和流程
- 团队共有的特点
（1）团队有一致的集体目标，团队要一起完成这目标。一个团队的成员不一定要同时工作；
（2）团队成员有一定的分工，互相依赖合作，共同完成任务。 - 软件团队的模式
（1）主治医师模式：首席程序员负责主要模块的设计与编码，其他成员从不同角度提供支持；
（2）明星模式：主治医师模式运用的极点，团队“明星”的能力掩盖了团队所有人的缺陷与优点；
（3）社区模式：成员分布不受时间空间的限制，所有人根据喜好选择项目进行开发，一般不要求报酬；
（4）业余剧团模式：没有固定的团队，且成员在不同的项目中没有固定的工作分配，所有成员由“中央指挥”指示；
（5）秘密团队：秘密状态下进行，无外界干扰，团队肩负独特使命，内部成员自由度与热情较高；
（6）特工团队：团队由专业人士组成，负责一些紧急问题的解决；
（7）交响乐团模式：较多大型软件公司采用，成员与领导者能力较强且有相似的项目开发经验，所有成员各司其职但统一受领导者指挥；
（8）爵士乐模式：与交响乐团模式对立，较为松散，领导者完成框架，其他成员在此基础上创作，最后再由领导者收尾；
（9）功能团队模式：没有固定的团队，由不同能力的成员进行组合，协作完成某一项目，项目完成后成员重新组织进行其它不同项目；
（10）官僚模式：脱胎于大机构的组织架构，几人向小头目报告，小头目向大头目报告。容易形成恶性竞争。
- 瀑布模型以及各种变形
- 特点：重计划、重事先设计、重文档表达。
- 统一流程工作流
- 业务建模——需求——分析和设计——实现——测试——部署——配置和变更管理——项目管理——环境——初始阶段——细化阶段——构造阶段——交付阶段
- TSP原则
- 使用妥善定义的流程，流程中的每一步都是可以重复、可以衡量结果的；
- 团队的各个成员对团队的目标、角色、产品都有统一的理解；
- 尽量使用成熟的技术和做法；
- 尽量多地收集数据（也包括对团队不利的数据），并用数据来帮助团队做出理性的决定；
- 制定切合实际的计划和承诺，团队计划要由负责具体执行的角色来制定；
- 增加团队的自我管理能力；
- 专注于提高质量，争取在软件生命周期的早期发现问题。最有效提高质量的办法是做全面而细致的设计工作。
1.队名：这是个小队
2.团队成员组成，按以下列表形式给出，个人博客地址需加超链接，在备注中标记团队组长（PM）
| 成员学号后五位 | 成员姓名 | 成员个人博客 | 备注 |
|---|---|---|---|
| 10116 | 祁英红 | https://www.cnblogs.com/qyhq/ | PM |
| 10119 | 帖佼佼 | https://www.cnblogs.com/-8tjj/ | -- |
| 10110 | 李华 | https://www.cnblogs.com/LH-18110/ | -- |
| 10108 | 高文利 | https://www.cnblogs.com/gwlg/ | -- |
- 成员风采：介绍每位队员的风格、擅长技术、编程兴趣、希望的承担的软工角色(文档、开发、测试、PM等)、一句话宣言等；
| 成员姓名 | 成员风格 | 擅长技术 | 编程兴趣 | 承担角色 |
|---|---|---|---|---|
| 祁英红 | 行事有计划，动手能力强 | web前端 | python | PM |
| 帖佼佼 | 擅长文字撰写工作，文采好 | c++ | python | -- |
| 李华 | 仔细认真，擅长测试检查 | C语言 | Java | -- |
| 高文利 | 编程能力好，逻辑思维能力较强 | python | Java | -- |
阅读《现代软件工程—构建之法》第7章、第17章，理解MSF的9点基本原则和团队成员绩效
MSF基本原则：
1、推动信息共享与沟通
此原则要求是将所有信息都保留并公开，讨论要包括所有涉及的角色，决定要公开并告知所有人。在此过程中可能会有技术机密的问题，要注意保护。信息共享和沟通是其他原则实行的基础，无论是被修改了的错误，还是发生了任何变化的过程，团队中的每个人都应该对此了解。宁可过分沟通，也不能使团队合作中的一个部分不透明公开。这会影响之后的学习。
2、为共同的愿景而工作
“共同的远景”是指产品的远景，此原则要求指定产品的最终目标，要求所有的工作人员朝着这个目标努力。如果没有搞清楚项目的目标，或者朝着与目标不同的方向努力时被认为是在做无用功。这是一个项目的关键，是项目第一阶段要达到的主要目标。无论做什么类型的软件都要明确我们项目的目标是什么。
3、充分授权和信任
此原则要求所有成员都应该能得到充分的授权和信任，他们有权在职权范围内按照自己的承诺完成任务，同时他们也充分信任其他同事的承诺。成员之间、团队之间是平等协作的关系，形成网状团队结构。这样做的好处：1.被授权的人会承担自己对项目的责任，同时也期望同事们也同样对项目负责；2.MSF提倡自下而上的计划，每个人有充分的权利估计自己的任务需要多长时间，每个人按照自己的估计去完成任务。人人支持项目计划和时间表。
4、各司其职，对项目共同负责
团队中的每个角色都有自己的职责，每个工作人员尽职尽责，各司其职，并且当要做一件事情，周围人有不少意见时，对此事负责任的角色要自己拿主意。团队的各个角色合起来，对整个项目的最终成功负责任。任何角色的失败都会导致项目的失败，各个角色的工作都是相互渗透、相互依赖的。
5、交付增量的价值
虽然我们都是搞技术的，但是同时我们也是一个商业实体，我们的项目都应该出于商业目的。商业项目需要重视市场和用户。技术处于第三位。“用户体验”，“产品管理”，这两个角色我们都要尊重。要重视商业价值，将目标和商业价值联系起来。此过程并不是功利的，任何产品，都应该注重商业价值。
6、保持敏捷，预期和适应变化
要求注意预期变化，而不是期望变化，意思是适应需求的变化、技术的变化、人事的变动。软件工程，唯一不变的是变化。所以客户的需求不会在第一时间很明确，然后保持不会变。除开客户的外部原因，团队内部也在不断的变化，这就要求团队保持敏捷的身段。
7、投资质量
要求用适量的时间去提升产品质量，但是没有说质量第一，应该把解决用户的问题第一，提高用户的满意度放在第一。团队成员应该有共识:防止缺陷的发生成为团队质量控制的首要任务，所有的角色都应该对质量保障负责，及时发布能够解决用户问题的软件，并能够及时修改软件中的问题。
8、学习所有的经验
强调做到经验总结和分享经验两个方面。MFS在每一个里程碑结束时都要做一个里程碑回顾，而不必等到项目结束后，因为大家对最近的成败都记忆犹新，能提供比较准确和全面的反馈。也是为了让团队成员从别人的成果和失败的例子中学到东西。如果发现了错误，可以马上研究解决办法，在下一个里程碑中通过实践来验证。
9、与顾客合作
MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同就开始闭门造车。项目的商业价值要由用户说了算，及早和用户沟通，通过讨论将模糊的需求共同变得具体，当用户不清楚自己的需求时，先和用户一起做出需求分析，项目是由项目团队人员做出来和用户喜欢的先决条件下的产品。
团队成员绩效
队友评估：
- 技术等级/技术能力
- 生产劳动力/结果
- 对团队的贡献（做一些工具让大家的工作更容易，帮助招人）
- 对产品的贡献（除本职工作外，对产品有帮助的活动，比如找bug，测试用户的反馈、产品推广等）
- 完成任务维度
- 团队贡献维度
- 二维评价体系（业绩/价值观）
- 划分等级和公开刺激的做法
- 闷声发财的做法
- 组建团队企业微信群，给出群成员截图
- 团队特色描述，言简意赅的描述团队特点或核心竞争力
- 有清晰的目标、相互的信任、相关的技能以及良好的沟通和恰当的领导。
任务3：完成《实验四 团队作业1：软件研发团队组建》博文作业
完成《实验四 团队作业1：软件研发团队组建》各项任务实际花费的时间
| 任务 | 所需时间（小时） |
|---|---|
| 任务一 | 4 |
| 任务二 | 2 |
| 任务三 | 0.25 |
谈谈完成本次作业的感受和体会。
通过对完成度很高的结对小组的实验项目三进行阅读评论，对团队项目开发的基本流程和团队成员之间的分工协作形式等有了更加深刻的了解，并且学会了如何撰写更规范的文档。此次实验，通过对他们的博文进行阅读，以及对代码进行运行分析，对我有一定的影响，对我们以后的团队开发提供了许多经验，同时我们也从中了解到了一些错误与不足。