事后诸葛亮分析
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们设计的软件是极简主义的博客平台，旨在解决计算机学院学子们的技术交流问题，营造一个分享项目经验、互助解惑的良性学习氛围。定义清楚，描述清晰，详情请看我们的博客 定义 描述
2. 我们达到目标了么?
达到第一阶段目标，完成第一阶段计划的所有功能，已按原计划交付之间交付
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?我们离目标更近了么?有什么经验教训? 如果历史重来一遍,我们会做什么改进?
目前只有内测版。距离我们的目标更近了，我们正在不断改善。教训：前后端交流不够充分及时，导致对接时消耗较多时间；后台开发前未做到统一规划，导致代码冗余；队员未能定期交付任务，导致进度延后；提交任务时没做好测试工作，导致测试花费较多时间。改进：前后端在开发的同时应该保持交流，及时解决问题；后台在开发前应做好统一规划与限制，并在开发时得严格遵守约定的约束；当队员接任务后未能定期交付时应及时重新分配该任务；规定在提前任务前必须做好充分的测试工作
二、计划
1.是否有充足的时间来做计划?
我们在计划阶段安排了足够的时间，并且有开会进行讨论交流，因此有充分的时间做计划
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段我们通过组内会议来讨论，出现分歧时，我们会对不同意见进行分析并权衡其中的利弊，
做到组内观点的统一
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划第一阶段的工作都已完成，关于第二阶段(进阶)未完成，后期课程任务占用大量的时间
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
无
5.是否每一项任务都有清楚定义和衡量的交付件?
是的。我们有用软件专门管理每一项任务
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
我们项目基本按照计划进行，未出现大意外。时间不够充足，未考虑后期实验与课设占用的时间
7.在计划中有没有留下缓冲区，缓冲区有作用么?
有，在第一阶段的计划中设置了一个星期的缓冲区，起作用了
8.我们学到了什么? 如果历史重来一遍,我们会做什么改进?
我们学到了一些前后端开发技术与团队开发的一些经验。做好更详细的计划，提高计划执行效率
三、资源
1.我们有足够的资源来完成各项任务么?
有，项目能正常部署与对接并正常运作
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
任务所需时间主要是根据任务量估计的，精确到天数
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试所需的时间和人力、软件硬件资源均足够，对于那些不需要编程的资源我们也给予重视，并无低估难度
4.你有没有感到你做的事情可以让别人来做（更有效率）?
显然把任务分配给对开发技术较为熟练的队员效率会更高，但由于个人时间有限，实际上并不可行，仍需要通过分工来分担压力
5.有什么经验教训? 如果历史重来一遍,我们会做什么改进?
做好项目方面的实时监督与加强项目资源的管理与部署
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
是，有变更信息我们会第一时间通知相关员工
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们通过功能分析四象限法来决定“推迟”和“必须实现”的功能
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义，我们第一阶段的计划对应的就是项目的出口条件
4.对于可能的变更是否能制定应急计划?
没有，第一阶段的计划相对较明确，因此无大变更，对于小变更我们会通过临时的交流解决问题
5.员工是否能够有效地处理意料之外的工作请求？
基本可以，对于意料之外的情况会通过队内的交流解决问题
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目初期完成，由前端代表与后台代表共同完成，时间和人选均合适
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，通过队内讨论交流与综合分析来决定
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们没使用单元测试，但有使用其它工具来完成测试工作，这些工具极大地提高了我们的测试效率
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
图片管理与博客管理，涉及的业务逻辑相对较复杂，项目目前还处于内测阶段，已修正发现的影响核心功能使用的重大bug，项目经验不足，考虑得不够全面
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
在提交代码时安排复审人进行代码复审，保证了基本的代码规范
6.如果历史重来一遍,我们会做什么改进?
加强代码复审力度，减少代码冗余量，以减少debug工作量
六、测试/发布
1.团队是否有一个测试计划？为什么没有？
我们团队有安排测试计划，以保证项目的健壮性
2.是否进行了正式的验收测试？
是的
3.团队是否有测试工具来帮助测试？
有，我们团队用了JMeter、IDEA、vscode以及项目管理工具等来帮助测试
4.团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
根据测试工具获得的响应时间与项目运转情况来测量并跟踪软件效能(包括压力测试)。从结果来看，有利于我们更好的了解项目性能。改进：通过上线发布来更客观地测试项目性能
6.在发布的过程中发现了哪些意外问题？
目前尚未发布，但项目已上线，上线过程并未发现意外问题
七、团队的角色，管理，合作
1.团队的每个角色是如何确定的，是不是人尽其才？
每个角色都是队员主动选择的，大家都尽到了自己的能力
2.团队成员之间有互相帮助么？
有，队员遇到困难时，会通过队内交流一起协助解决困难
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
通过队内交流讨论一起解决分歧问题
八、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到CMMI中的三级，定义级别
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合阶段
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
代码更加的规范统一，技术运用更加熟练，开发效率有所提升
4.你觉得目前最需要改进的一个方面是什么?
项目管理方面
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
在前后端分离开发的过程中，队内交流较频繁，能做到及时解决问题
我们团队内有前后端代表协助解决技术相关的问题
队员比较积极，大部分能按时完成自己认领的任务，在完成自己任务的前提下，会主动的分担队友的任务
6.代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
项目初期制定一套代码规范，并且开发人员必须严格遵守
测试工作做完后要复审人员要严格进行代码规范的复审
7.整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
开发者要有一套完善的架构体系(包括指定统一的框架等)，并对项目技术有充足的知识储备
在添加新功能时进行重构，在修改bug时进行重构，在代码复审时进行重构
软件的开发速度，整体bug量，软件代码可读性
8.其它软件工具的应用，应该如何提高？
尝试学习使用其它测试工具，提高项目开发效率
9.项目管理有哪些具体的提高？
通过站立式会议掌握项目动态与进展
通过任务分解简化开发任务并能实时debug，减少测试工作量
10.项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
通过日志系统来跟踪用户数据方面的信息
11.项目文档的质量如何提高？
选择合适的人员专门负责项目文档工作
12.对于人的领导和管理， 有什么具体可以改进的地方？
选择合适的人员专门负责pm工作
13.对于软件工程的理论，规律有什么心得体会或不同意见？
有合适的人员担任pm，做好项目的整体管理工作很重要
在代码方面要注意整体的统一性
在文档方面可以通过模板来辅助，文档撰写者要有一定的经验
九、会议照片及角色贡献
1.会议照片
2.角色贡献
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 胡晓煜 | 后台开发&PM&测试 | 21 | 后台博客管理+账户管理模块 协助博客撰写 所有后台接口的测试与debug工作 |
| 周赛星 | 后台开发 | 19.5 | 后台个人资料模块接口和图片管理模块接口 |
| 何科宪 | 后端开发 | 19.5 | 为开发配置环境，并将项目部署到服务器上 |
| 左梓仪 | 前端开发&博客攥写&测试 | 22 | 前端登录模块+博客管理模块+修改博客模块 团队博客 检测出登录界面验证码的bug、历史博客列表显示的bug、删除博客的bug，都修复了。 |
| 黄添榕 | 前端负责人 | 19 | 前端基础页面、博客广场 |
| 何悦 | 前端开发 | 19 | 个人资料页面以及注册页面 |
