事后诸葛亮分析

下面是关于事后诸葛亮分析博客，该博客涵盖了项目回顾、团队成员合照和团队分工三个部分。

1、项目管理之事后诸葛亮会议项目回顾 Q & A

根据《构建之法》的内容，我们团队按照顺序从六个方面队本次的团队合作项目流程进行了事后诸葛亮分析。

1 设想和目标

Q1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
A1. 我们的软件希望能解决小众用户在购物平台上的需求。根据问卷调查的结果，由于搜索功能不够精准，用户往往需要花费大量时间浏览和筛选商品，难以快速找到自己需要的商品。因此我们希望从搜索栏入手，构建一个能高效满足用户购物需求的购物平台。
Q2. 是否有充足的时间来做计划？
A2. 在项目初期，我们有两周的时间来完成我的需求规格说明书，同时又有另外一周的时间完善需求说明书和进行需求改进，从整个项目的流程来看，制作计划的时候是绰绰有余的，但是我们团队由于大部分人第一次进行项目的制作，并不知道如何利用这个时间来制作计划，制作的计划与后续实际安排又有较多出入。在我们团队经讨论后，认为在计划的部分，不能单纯地纸上谈兵，要边计划边开始着手完成计划，既要在项目之初，结合自身能力制定一个符合团队能力、有缓存地区的计划，同时在项目进行的时候，也要随着项目进度的变化，不断调整项目计划表，一步步确定项目完成日期。
Q3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？用户量、用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？有什么经验教训？如果历史重来一遍，我们会做什么改进？
A3. 在面对不同意见的时候，如果线上无法进行一个良性、有效地沟通，团队队长会进行群投票，选择一个合适的时间，开一个线下会议，团队成员对会议内容提前了解，在会议讨论时，大家都表达自己的想法，我们团队尊重不同队员的个人思想，但是始终保持“求同存异”的方针，只要维持保证项目的整体大方向不改变，在其余功能实现部分，团队成员发挥自己的能力。
用户量与我们事先的预想是一致，每天的访客量有30个活跃用户，每小时访问次数在100次以内。
每一次讨论不一定都是为了推进项目，比如在敏捷计划的第一次站立会议中，我们团队原本已经打算根据数据搭建的数据库表，上传数据，但是针对数据库表的设计，我们团队产生了分歧，有的队员认为，按照我们找到的商品数据构造数据库表就好，有的成员认为，类似的表的设计参考现有的购物平台的信息照猫画虎就好，而有的队员又认为，要剔除不合理的地方，自己设计一个更符合用户需求的数据库表。在这次的讨论中，我们的只是解决了一些历史遗留问题，并没有离目标更近，但是在这方面的深刻讨论却为自己的项目打下了更加牢固的基础，这样在后续项目搭建过程中，不会出现其他有关数据库方面的问题。
如果历史重来，我会利用前面的时间制作计划更好的计划，同时在计划部署的时候，着手对项目的初步搭建，在计划中一步步进行项目，在完成项目中又对当前的计划进行修改整合，这样对整个项目的推动帮助最大。

2 计划

Q1. 你原计划的工作是否最后都做完了？如果有没做完的，为什么？
A1. 针对“购物推送商品没有吸引力”这个需求，我们曾尝试推出购物平台首页分页功能，来解决用户需求，但是这项工作我们最后并没有实现，因为在站立会议讨论时，我们发现这个需求对用户来说不是很重要，而且对于购物平台的构建来说也可有可无。
Q2. 有没有发现你做了一些事后看来没必要或没多大价值的事？
A2. 有很多时候确实有这种情况。在项目开始之初，团队在讨论是否需要统一Pycharm的版本和Python的版本，但是在项目开始之后，发现相差0.几的版本也毫无影响。最后在团队总结的时候，大家也都同意很多时候应该把讨论的东西先落地，即使有很多个不同的方向，但是当我们拿着实物进行对比的时候，会比空谈更有价值。
Q3. 是否每一项任务都有清楚定义和衡量的交付件？
A3. 大部分都没有，我们在讨论的时候都只说明了自己负责的功能，对于未实现的东西，一般很少去讨论其细节，只看团队成员最终实现的结果。
Q4. 是否项目的整个过程都按照计划进行？
A4.在项目初期是的。但是在敏捷七天计划开始的前几天遇到的困难比较多，1-3 天的计划明显落后于原定计划，但是后面随着项目的深入推进，团队也适应了敏捷计划，我们团队最终跟原定计划比超过了一天。
Q5. 在计划中有没有留下缓冲区，缓冲区有作用么？
A5. 没有缓冲区，原来认为没有必要，由于大家没有完成项目的经验，所以一开始都有蜜汁自信，没有设置相关的缓冲区，后来发现还是有用的。主要是各人进度不一，有些模块不断地有一些小问题，花了很长时间才能做好。
Q6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班。）我们学到了什么？如果历史重来一遍，我们会做什么改进？
A6. 应该明确缓冲区的长度，这样有利于团队完成预期计划。如果从来一遍，利用前面的时间制作计划更好的计划，同时在计划部署的时候，着手对项目的初步搭建，在计划中一步步进行项目，在完成项目中又对当前的计划进行修改整合，这样对整个项目的推动帮助最大。

3 资源

Q1. 我们有足够的资源来完成各项任务么？
A1. 从人员配置上和设备配置上是是否充足的，但是从技术层面角度，不同成员都需要付出一定的努力，才能完成自己的任务。
Q2. 各项任务所需的时间和其他资源是如何估计的，精度如何？
A2. 由于我们团队项目经验不足，在项目开始精度很粗略，许多任务的完成时间和计划都比较模糊。后来随着项目任务的加重，大家只顾得上干活，没有在计划调整中花其余的时间，也没时间考虑任务精度问题。
Q3. 团队中有没有感到你做的事情可以让别人来做（更有效率）？有什么经验教训？如果历史重来一遍，我们会做什么改进？
A3. 在团队编写博客的部分，是由团队制定一人来完成。因此在很多功能描述部分，写博客的人可能要花更多的时间去了解整个项目不同功能的部分，如果把这部分内容分发给不同功能实现的团队成员来完成，会提高写博客的效率，同时也会博客的内容也会与实际实现的功能更加贴切。如果重来一遍，会加强在写博客上的分工。

4 设计/实现

Q1. 设计工作在什么时候，由谁来完成？是合适的时间，合适的人么？
A1. 项目的系统设计是在第三周完成的
Q2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
A2. 很多时候都会遇到模棱两可的情况。在对项目进行分工之后，由于分工存在着不合理性，我们把功能完成就全权交给相关负责人，就看具体执行的人是如何解决的。我们团队奉行结果主义，具体的细节团队不会过于关注，只会看最终完成的结果，只要最终完成的好就是好的。
Q3. 团队是否运用单元测试（Unit Test）、测试驱动的开发（TDD）、UML或者其他工具来帮助设计和实现？这些工具有效么？
A3. 团队运用单元测试。首先，在一个模块内的队员进行组内测试，如都在购物车模块的两位同学，对对方实现的函数和功能进行运行测试，然后，不同模块的同学进行组与组之间的互测。模块1和模块2的同学进行功能互测，模块和模块4的同学进行功能互测。还未用到测试驱动的开发（TDD）、UML或者其他工具来帮助设计和实现，只借助了主流的浏览器进行测试。
Q4. 什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发时没有想到这些情况？
A4. 在用户部分产生的 Bug 最多。其原因是因为用户部分包含的功能最多且最广，而且用户是使用我所建立的购物平台，所以这方面的 Bug 会更加容易被发现。具体的 Bug 有登陆后应该将未登陆前的购物车信息加入到当前用户，但是只有用户之前的购物车信息、登录的图片验证码无法加载、验证码无法点击刷新的三个 Bug。在发布 Alpha 版本后，由于使用用户数量有限，目前暂时未发现其他重要的 Bug。
Q5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？我们学到了什么？如果历史重来一遍，我们会做什么改进？
A5. 在项目的初期，都会对代码进行严格的复审，全部代码经过Code Quality Analysis并消除警告。但是后来随着项目任务的加重，大家只顾得上干活，忽略了对代码进行严格的复审，奉行只要代码能跑就行的原则。如果历史重来一遍，我们会在计划中加入对代码复审的部分，同时预留一定的缓冲区，以防止时间不够而忽略了代码复审的步骤。

5 测试/发布

Q1. 团队有没有测试计划？为什么没有？
A1. 我们团队有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇一样胡乱测试，我们对模块1和模块2的同学进行功能互测，模块和模块4的同学进行功能互测。
Q2. 有没有做过正式的验收测试？
A2. 在不同浏览器，对不同功能进行了测试，我们团队项目基本满足PC端的使用。
Q3. 团队是否有测试工具来帮助测试？
A3. 有，我们借助了不同主流浏览器。
Q4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
A4. 团队成员首先对不同浏览器购物平台的界面的图片显示和导航栏位置进行了对比，购物平台中商品的信息和位置最能影响用户的体验感，如果出现了错位或者图片无法生效，会极大影响用户的体验。再进行完这些测试后，我们对购物平台不同界面的切换进行了时间测试，测试时延，切身感受了用户的体验。我们如果采用更加专业的工具会对测试结果有更好的呈现，更容易发现软件的问题。
Q5. 在发布的过程中发现了哪些意外问题？我们学到了什么？如果历史重来一遍，我们会做什么改进？
A5. 我们在使用360 浏览器打开购物平台的时候，出现了商品详情页面介绍中的导航栏可能出现问题，但是其余的主流浏览器没有出现这类问题，因此我们忽略了这个问题。如果历史重来，我们会采用更加专业的工具会对软件进行更加专业的测试。

6 总结

Q1. 团队觉得团队目前的状态属于CMMI中的哪个级别？
A1. 我们团队认为我们到达了CMMI二级，管理级。在管理级水平上，我们在项目实施上能基本遵守既定的计划和流程，有资源准备，相关的功能实现都分配到位了，对整个流程有监测与控制，对每位队员完成情况都有所掌握，对于进度慢的队员进行积极地督促，同时通过站立会议讨论其遇到的问题和难点。对于进度快的队员，让其介绍为何能如此顺利推进任务，同时让“先富带动后富”，让学有余力、提前完成的队员去帮助坎南比较大的队员，以保证项目进度按照既定计划逐步推进，并联合团队队长对项目与流程进行审查。我们团队通过了一定的管理手段排除了完成任务质量的随机性，保证了团队的项目功能实现都会得到成功。
Q2. 你们团队觉得目前最需要改进的一个方面是什么？
A3. 提升整个团队对于项目推进的把控能力。如果能很好地掌握一个项目所需的全部要点，可以在项目计划和设计的过程中，减少不必要的对没必要或没多大价值的事进行讨论；提高项目的把控能力，还能避免模棱两可的情况，提高对各项任务所需的时间和其他资源估计的精度，能让项目按照既定计划完美推进，减少团队完成项目的压力。

2、团队成员合照

3、团队成员在Alpha阶段的角色和具体贡献

姓名	角色	可验证的贡献
韩业浩	Dev, test	参与项目部署、参与购物车的测试、管理github团队仓库
黄翼山	Dev	完成商品模块部分功能、参与团队评审
李金强	Dev	完成商品模块部分功能
李钰平	Dev	完成购物车模块部分功能
李奇龙	Dev, test	管理github团队仓库、完成用户模块部分功能、参与商品模块的测试、参与项目部署
彭学智	Dev,test	管理github团队仓库、完成商品模块部分功能、参与用户模块的测试、参与项目部署
许铭益（小队长）	PM, Dev	管理github团队仓库、完成购物车模块功能、参与订单模块的测试、参与项目部署、编写团队项目所有博客、保证项目正常推进、和团队项目展示