【Alpha】事后分析
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件（网站）希望帮助同学们完成大二学年的物理实验，包括完成实验预习报告、实验数据处理及最终实验报告生成。
对于要解决的问题我们认为定义的比较清楚，对典型用户和典型场景也有清晰的描述。
详见 Alpha展示博客
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
理论上来说我们达到了目标，预期的功能及完成情况如下
| 功能 | 计划 | 实际 |
|---|---|---|
| 新实验 | 3 | 2.5 |
| 控制台 | 控制台新增实验/修改实验/运行测试/发布实验/删除实验/上传预习报告 | 完成 |
| 用户界面 | 用户信息展示/修改 | 完成 |
| 收藏夹 | 收藏夹修复/正常收藏/下载/删除 | 完成 |
| 其他功能修复 | 其他功能修复 | 完成 |
(新实验部分的第三个实验脚本未完成)
我们按照课上计划的时间(4月20号)进行了交付，计划用户量50人，Alpha展示前用户量达到了53人，达到了计划的用户量。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
Alpha阶段的软工质量提升较小，主要的提升包括：
- 完善部署文档和控制台使用说明
- 在新分支中去掉（gitignore）了应当被忽略的代码（如部分外部库的代码以及服务器配置敏感信息）
- 将python2升级至python3
除此之外我们在API接口文档、代码测试、issue管理等方面做的都和之前差不多，没有太大的改进。这也是我们接下来需要改进的部分。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量和预期是一致的。
对于控制台来说用户的接受程度低于我们的预期，或者说我们的预期可能过高了。实际上既会写脚本又了解物理实验还愿意贡献时间的同学很少，这一功能更多地是给开发者提供了遍历。不过这也让我们对如何降低实验脚本的门槛进行了思考。
总体来说我们在Alpha阶段重拾了以前的项目，向新的目标移动了一些。
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
一开始接手这一项目时我们对项目本身的了解不足导致前期耽误了太多时间。并且为了功能看起来有进步我们选择了受众较小的控制台作为出发点。但实际上这一功能目前来看仅仅是为将来的网站开发/维护者带来了些许便利。
如果我们能再来一边，我们在计划方面可能会更多地考虑新增几个新的实验，并且多花点时间在改善原有项目的工程质量上，如修缮并规范原有的接口、撰写单元测试等。
计划
是否有充足的时间来做计划?
如我们展示博客所说：计划的时间总是不够的
实际上我们从决定做物理实验网站开始便去了解这一项目，但由于对项目本身状态（即有多少坑）没有底，以及对本学期如何改善网站功能方面调研不足，导致我们在计划时花费了较多的时间。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
计划阶段我们通过线下会议的方式确定了接下来要完成的工作，并征求了大家的意见，对不同的意见进行讨论并得出结论。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作基本都做完了。唯一一点特殊的是现在看来Alpha阶段制定的一些长远计划可能会被抛弃。
有没有发现你做了一些事后看来没必要或没多大价值的事?
在本地尝试修复整个网站运行，花费了一段时间。事后发现很多问题均是因为没有部署到服务器上而导致的。
是否每一项任务都有清楚定义和衡量的交付件?
坦率来说不是每个任务的交付内容都足够清晰的，对于一些成果明显的内容有明确的交付件，如编写脚本任务对应着脚本，latex模板任务对应模板，用户界面任务对应最终的html界面。
但某些后端的任务没有定义可衡量的交付内容，基本都是通过：人工验证该接口/后端模块功能实现了，就算是交付了。
以及一部分学习任务一开始没有给出成果。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
总体来说项目是按照原计划进行的，虽然起初清明节放假进度较慢，但中间以后进度仍然追上了计划。
项目没有太多意外，许多困难实际上都是意料以内并有所处理的。
没有估计到的风险是脚本编写的难度大于我们的预期，这一点可能源于组内同学对python编程本身较为自信，却没有考虑到新接触jinja2模板引擎带来的诸多问题。
在计划中有没有留下缓冲区，缓冲区有作用么?
预留了两天的缓冲区。总体而言缓冲区那段时间我们主要完善了文档并进行了测试，对功能方面没有太大的影响。整体功能在缓冲区到来之前就完成了。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
之后的阶段我们的计划需要制定的更加详细，Alpha阶段由于对项目状态了解不足，起初的某些计划也较为“机动”，并且在过程中添加了很多任务来弥补起初计划量较少的问题。Beta阶段任务比较清晰，因此计划内容也将更加充分。除此之外对于那些无法确定的计划我们打算以先动手开始为主。
我们学到了什么? 如果历史重来一遍,我们会做什么改进？
虽说计划不是一成不变的，但提前做好计划有助于整个项目在进行过程中不至于没有方向。除此之外计划需要根据组内成员的状态进行一些调整。
如果再来一遍，我们会更早地开始计划，并且对于一些不确定的东西采取“先做再看”的方式，尽量减少空想的时间。
资源
我们有足够的资源来完成各项任务么?
项目资源来说：够。我们有两台服务器用于开发，也通过以前的学长要到了服务器备份资源。
时间/人力资源来说：不够。组内同学有很多忙于其他课程，并且团队整体开发实力一般。
各项任务所需的时间和其他资源是如何估计的，精度如何?
项目起初在估计所需时间时采取的方法是大家在一起对每一项任务的时间做出估计，并讨论自己做出此估计的原因。最终确定一个大概的任务时间。精度基本准确，个别任务估计时间大于实际完成时间。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间和人力均足够，组内半数同学参与了最后的验收测试。对于美工和文案而言由于我们的项目基于以往项目开发，有现成的样式文件，因此美工并未花费太长时间。
（唯一可能缺乏的是同学们在进行新框架以及web单元测试方面的技术能力）
你有没有感到你做的事情可以让别人来做（更有效率）?
在组内我们往往是遇到某同学比较忙或进度较慢时将任务分配给他人，除此之外大部分情况下自己做的事情效率足够。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
作为PM，在这方面的经验是相比于任务本身来说，将任务分配给合适的人更加重要，并且要实时调整任务的分配以满足进度要求。
如果重来一遍，我们可能会采取更激进的任务分配方式（即让每个人都尽量不闲着），但说实话难度较大。
变更管理
每个相关的员工都及时知道了变更的消息?
是的，对于开发同一个大任务的同学们来说由于交流很多，变动消息传递很及时。
. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
在Alpha阶段主要以预估功能完成度及完成时间为主，如果完成度较低或完成的时间很晚那么干脆就先推迟。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有定义：
网站整体功能能够正常运行，且可以通过网站控制台上传、修改及调试新实验。同时尽可能新增本学期实验内容。
员工是否能够有效地处理意料之外的工作请求？
能，尤其是能力较强的同学会主动帮助其他同学分担一部分任务。
我们学到了什么? 如果历史重来一遍，我们会做什么改进？
尽量减少任务本身的变动。如果再来一遍我们会更仔细地评估组员的能力及特长以分配任务。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计其实是在起初的计划阶段以及开发阶段初期完成的。由主要开发相应模块的人完成。人选合适，时间若能提前一点完成更好。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
因为设计分配到了开发模块的个人，因此设计方面基本没有模棱两可的情况，若此人也拿不准主意则团队内会进行讨论给出意见。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
测试方面，没有。
由于团队项目的进度比较赶，加之同学们对PHPUnit以及web后端的单元测试方法不熟悉，导致最终没有来得及进行单元测试工作。
UML也没有使用。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
目前来说Bug最多的部分仍在于原有代码中关于社区和实验端对接的部分。除此之外实验脚本中也存在一些bug。发布之后发现的主要问题是小工具的输入框疑似不符合实际输入要求。这一部分源于起初我们对小工具中逐差法的知识基本遗忘的差不多了，见上届测试报告中小工具正常从而没有考虑。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审主要由组内能力较强的同学进行，往往在复审的同时也会进行少量修改。
代码规范方面开发尽量按照原有代码规范进行，但由于工程经过了多年迭代，实际上代码的命名规范仍需要改进。
**我们学到了什么? 如果历史重来一遍， **我们会做什么改进？
单元测试很！重！要！
并且单元测试越早开始越好，对于新项目来说编写单元测试比一个复杂的老项目要简单的多。假如项目一开始就有详尽的单元测试，对于之后接手的同学也比较友好。本项目目前并没有找到往届的单元测试内容，并且很多接口由于改动较大可能测试也已失效。
如果再来一遍，我们会考虑在接手的时侯便开始学习单元测试的相关内容，并在开发过程中同时进行测试。
测试/发布
团队是否有一个测试计划？为什么没有？
团队的测试计划是在项目功能接近收尾时进行整体的验收测试、场景测试，在开发过程中开发者对于自己负责的模块进行自测。
是否进行了正式的验收测试？
进行了。包括所有功能的验收和复查。
团队是否有测试工具来帮助测试？
单元测试部分：没有，原因见设计与实现部分
性能测试：见下
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们尝试使用了Apache自带的ab进行了简单的压力测试，由于用户功能部分改动不大，因此整体软件的效能和去年相比并没有很大差距。
在发布的过程中发现了哪些意外问题？
发布过程中没有遇到什么以外，因为很多坑在第一次部署服务器的时候都踩过一遍了，也记录到了部署文档中。
我们学到了什么? 如果重来一遍，我们会做什么改进？
还是那句话：单 元 测 试
具体见 设计与实现 部分
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
我们团队中一开始由于大家也不甚了解，因此任务分配方面基本按照课业压力决定。好在大家对于角色分配都很满意，所以算是“人尽其才”了。
团队成员之间有互相帮助么？
有，主要是开发能力较强的同学对开发能力一般的同学进行辅助，或当组员课业较忙时其他成员会分担部分工作。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
合作方面的问题主要通过私下交流以及scrum meeting时的讨论解决。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为处于第二级（管理级）：在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对整个流程有监测与控制。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为处于磨合和规范阶段中间。实际上我们团队在Alpha阶段可以说“磨合”比较顺利，也没有什么争执，但又距离规范的软件开发团队仍有距离。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈：对于开发同一个模块/任务的同学，我们在线下开展了多次结对来完成任务。
- 经常地交付可工作的软件：开发服务器上运行的版本很少出现无法运行或崩溃的情况，每完成一个功能便会进行同步。
什么是在下个阶段要改进的地方？越具体越好。
软工方面我们希望的改进如下：
- 完善单元测试，在编写新功能的同时编写测试样例。
- 尽早开始计划，对于不确定的计划则尽早开始实践，在实践中进行调整。
- 对于不同的任务制定相应的交付成果，让issue关的更有理有据，代码任务需要commit，测试任务需要测试报告及测试代码，学习类任务需要学习成果。
- 当进度速度放缓时，团队内及时进行讨论并给出可行的追赶进度方案。
- 尽量优化原有工程的软件质量，包括重构接口（尝试遵循RPC或REST的风格）、重构命名规范、补全及修订文档等。
照片
（今天我们同时进行了新老组员的交接工作）