• 设想与目标
• 计划
• 资源
• 变更管理
• 设计/实现
• 测试与发布
• 总结
• 团队成员角色与贡献

设想与目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   此项目是基于商户和仓库两个部门之间联系，记录，管理多功能于一体的管理应用，大部分内容会以表格的方式呈现给使用者，同时拥有查看，自查，管理和存储等功能于操作者使用，界面简
   单， 易上手。详情见规格说明书。
2. 是否有充足的时间来做计划?
   时间整体上来说比较充足，不过团队成员都是第一次参加团队任务，在面对突发情况时准备会有所不足。
3. 团队在计划阶段是如何解决成员对于计划的不同意见的？
   我们会听取团队成员的意见，然后在聚在一起讨论这个意见的可行性，尽最大的可能让每个人的想法都能得到一定的回应，在有较大的意见不合时，我们也会一起讨论，并且会由组长给出自己的看法。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   我们的项目上线了，但是用户量没有达到开始的设想，所以我们打算整理宣传思路、不断完善项目的功能，以后我们将加大宣传力度，努力向市面上的商家推销自己的产品，争取早日达到预想的用户量，并且会不断对重要功能进行优化。
   5.经验教训
   教训
   团队成员的知识储备还是不够充足，在实现某些功能时会比较吃力。团队之间的配合还是不够协调。项目开始时的计划不够完善，导致后面的工作有点找不到方向
   改进
   努力学习专业知识，增加知识储备。增加团队交流次数，培养团队默契。完善项目计划。

计划

1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
   基本完成了我们初定的任务，但是有些小的功能没有完善。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
   大家的每一步操作基本上都是为了完成要求而进行的，这种情况暂时没有遇到过。
3. 是否每一项任务都有清楚定义和衡量的交付件?
   基本都有，有些困难的任务没有。
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
   项目整体都在按计划进行，有时候个别成员会请假，不过事后都能补上进度，其他有空闲时间的成员也会帮忙协助其赶上进度。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
   留下了足够的缓冲区，缓冲区让我们按时按量完成项目。

资源

1. 我们有足够的资源来完成各项任务么?
   资源不够充足，有些组员技术方向重合，而有些模块没有特别擅长的组员，组员普遍缺乏开发经验
   2.各项任务所需的时间和其他资源是如何估计的，精度如何?
   粗略计算估计，要很高精度的话，在这里又要花很多时间。所以先慢慢着手开始，事后讨论每项任务所需大概时间。
2. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
   ①事前安排任务，任务合理的分配和有序进行。有时某个组员的任务安排过重可能会更加降低工作效率
   ②保证小组会议的进行，尽量挑选组员都有空时间，线下不齐也可以开线上会议，随时了解组员任务的完成进度和完成效果。

变更管理

1. 每个相关的员工都及时知道了变更的消息?
   是，我们会在微信的群来通知大家项目的进展及变动，每天上课前也会进行2到3分钟的讨论。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
   如果依赖这一功能的模块比较多，则必须实现，否则可以推迟，另外如果这个功能是业务的核心则必须实现。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
   ①具有安全性：能够尽可能保证用户信息的安全性，不泄露用户隐私。
   ②具有正确性：能够正确统计库存信息。
   ③具有易用性：能够让没有仓库管理经验的人也能快速上手。
4. 对于可能的变更是否能制定应急计划?
   能，但由于我们时间比较充裕，队员都尽可能快速完成自身任务，所以基本不需要制订应急计划。
5. 员工是否能够有效地处理意料之外的工作请求？
   是的。由于团队成员时间都比较充裕，可以对不熟悉的技术进行学习，然后处理技术上的问题。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
   一开始，团队产品经理选定一个应用场景，然后进行小组讨论，分析大概要实现的功能以及所需时间，小组大部分成员觉得可行后，产品经理去分析每一个要去实现的细节功能，并且尽可能提出可能要实现的功能，接下来召开团队集体会议，每个队员以分析可行性为主，对项目的难度进行评估，去掉部分实现困难对业务影响较轻的功能，补充一些实现简单但又方便用户的功能，最后由团队产品经理整理出需求文档。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
   有，我们会先分析改设计是否会影响到其他模块的设计，如果会则尽快召开会议决定最终方案。否则尽可能放到项目后期再去实现。
3. 团队是否有测试工具来帮助测试？
   有，但是没有足够深入的使用。主要的测试工具都在后台方面应用，前端较少使用测试工具，不过前端bug也比较少。
   4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
   用户权限不足时跳转页面产生的bug比较多，主要是负责这一功能的开发人员不熟悉安全框架的使用。
   发布之后发现HTTPS证书没有授权，需要用户手动信任，开发时由于大家都信任一次证书后，浏览器没有提示，所以忽略了这个问题。
   5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
   我们使用了VSCode Remote功能，大家都可以查看甚至修改远程服务器上的同一份代码，发现代码中的问题。我们的绝大部分代码严格执行了代码规范。

测试与发布

1. 团队在整个设计编码过程是否有对各个模块进行不时检测？
   有，并且在整个设计过程由于讨论效果尚可以及有相应同学进行二次排查和测试，使整体代码在多次排查都没有出现错误。
2. 团队是否有使用多环境，多设备进行其代码容错性？
   有，分别在团队成员的设备上用不同的浏览器进行了测试，只有IE浏览器存在严重使用问题。
3. 团队是否有比对预期设计计划？
   我们在各个时期有和当初进行的预期计划进行较合理的比对，在不同时期都相应解决了可能出现的问题，所以和预期计划出入不大。
4. 在发布团队成果和进展的时候是否有因为分工产生分歧？
   没有，本组成员都是期待借助这样的机会来考察自己在整个设计践行过程的学习成果。
5. 在本次团队软件工程项目的最大收获是什么？
   很好地去明白软件工程思想在真切实行的效果以及将其应用于实际项目的功能性。

总结

1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
   二级，可重复级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
   磨合阶段，团队内部沟通也是尽量让每个人能有事情去做，每个任务能够努力完成
3. 你觉得目前最需要改进的一个方面是什么?
   组员的开发技术水平，能力参差不齐，组员水平不过关会整体推后整组的开发进度。

团队成员角色与贡献