Alpha阶段过后分析

Alpha阶段过后分析

1. 设想和目标

1.1 咱们的软件要解决什么问题？是否认义得很清楚？是否对典型用户和典型场景有清晰的描述？

咱们要实现一个课程资源共享平台，为同窗们获取资源、分享资源提供便利。对于要解决的问题咱们小组定义得比较明确，对典型用户和典型场景也有较为详细的描述。

1.2 咱们达到目标了么（原计划的功能作到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

原计划实现的资源上传/下载功能都已经在Alpha阶段实现了，只是一些比较细致的功能，如资源收藏、评价等，尚未实现。咱们的原计划是发布一周内用户量达到300， 实际结果为230左右。

1.3 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?

目前只是实现了资源上传和下载的功能，目前接到的反馈有打开资源界面的时候太慢，这一点实际上咱们已经在发布前注意到了，只是没有时间去修复了。在发布以后咱们经过资源的分页显示优化了资源显示过慢的问题，目前使用体验较好。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

感受没有抓住用户的痛点，下载资源的步骤感受仍是繁琐了点，应该在Alpha阶段实现一个“搜索资源”的功能会好一点，这部分咱们在Beta阶段实现。

---

2. 计划

2.1 是否有充足的时间来作计划?

Alpha阶段共四周，其中第一周的时间主要都用于作计划上了，时间感受比较充足。咱们在第一周大体设计了网站的原型，并对数据库结构和一些接口进行了定义，但尽管作了不少计划，依然还有不少没有考虑周全的地方，好比数据库和接口在实际开发中作了不少修改。

2.2 团队在计划阶段是如何解决同事们对于计划的不一样意见的？

好像在实际开发中出现意见对立的状况不是不少……通常采起的作法是PM将全部不一样的意见汇总，综合利弊得出结论。

2.3 你原计划的工做是否最后都作完了? 若是有没作完的，为何?

本来计划是把资源收藏等小功能也给实现了，但资源上传下载这部分比想象中难很多，尤为是如何下载用户上传的文件是个问题，在这一部分花费的时间超出了预期。

2.4 有没有发现你作了一些过后看来不必或没多大价值的事?

我的中心在Alpha阶段彻底没用上，不过这也是为资源收藏等功能作铺垫，并且也没有耗费太多时间。

2.5 是否每一项任务都有清楚定义和衡量的交付件?

感受并无，PM只是说要实现一个什么样的功能，却没有说这个功能实现以后要达到一个怎样的标准，一个模棱两可的功能实现，最终也能够被交付。

2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?

并非，好比在爬取课程信息的时候一开始没有获取到课程类别和开课院系等信息，这样子就没办法筛选课程了，只能先把Beta阶段的课程搜索功能先实现了。还有一个意外就是以前提到的，咱们的资源分为两种，一种是爬取的资源，其实就是引用一个课程中心的连接；另一种是用户上传的，和课程中心上的是彻底不一样的原理，下载用户上传的资源咱们费了很多时间。

2.7 在计划中有没有留下缓冲区，缓冲区有做用么?

计划中没有缓冲区，都是从issue堆里直接分配的（逃

2.8 未来的计划会作什么修改？（例如：缓冲区的定义，加班）

工做重心转移到后端，比起赶着实现博文功能，不如先把资源功能尽量完善，把较少的功能作到极致。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

开发感受缺少计划性，尽管最终目标很明确，可是实际开发时是走一步算一步。我感受计划方面要向NewTeam团队学习，他们在Alpha阶段代码编写以前就已经将任务细化到每人、天天上，这一点比咱们强太多……

---

3. 资源

3.1 咱们有足够的资源来完成各项任务么?

咱们是一人测试，四人开发，两人前端，两人后端，资源算是很充足了，并且组员们能力都很优秀，遇到的不少坑在你们的努力下都一一踩实了。

3.2 各项任务所需的时间和其余资源是如何估计的，精度如何?

以小时为单位记录任务时间，估计的时候首先对任务进行一个大体了解，而后经过商议、查找资料等途径判断其难度。

3.3 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?

咱们有一名成员专门负责测试，资源还算充足，只是在进行压力测试的时候机器要一直开几天，感受有些吃不消……咱们团队没有美工设计和文案，只有码代码的程序员。

3.4 你有没有感到你作的事情可让别人来作（更有效率）?

有时候网站功能出现问题了会帮忙debug，但须要本身先熟悉一下代码，这样效率感受就有点低了（其实仍是本身比较菜）。

有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

仍是感受分工出现问题，每一个人只负责职责内的工做是最好的。要是能重来，我做为一个PM首先要保证文档是随着代码进度不断更新的，这样可以提升成员交流的效率，其实能节省下来很多时间。在实际开发过程当中，不少bug也是由于没有定义清楚接口和功能致使的，感受浪费了很多时间……

---

4. 变动管理

4.1 每一个相关的员工都及时知道了变动的消息?

感受并无，有些私下决定的事并没能及时通知你们，这一点PM须要反省。

4.2 咱们采用了什么办法决定“推迟”和“必须实现”的功能?

核心的功能必须实现（如资源的下载和上传），围绕着核心功能的小功能能够先放放（如资源的收藏和评论）。

4.3 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?

并无，差很少能跑了就算出口了……

4.4 对于可能的变动是否能制定应急计划?

感受并无针对变动制定应急计划，这一点在计划中已经反省了，遇到变动的时候只有应急，没有计划。

4.5 员工是否可以有效地处理意料以外的工做请求？

中途有临时给一些成员添加过任务，他们都接受了而且完成得很漂亮，可是我以为意料以外的工做请求仍是应当越少越好。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

因为计划性不是很强，因此对于变动也没有概念，这实际上是个很危险的事情。另外若是出现了变动，PM要明肯定义出“什么东西变了，什么东西没变”，这样成员们大概也有个底。

---

5. 设计/实现

5.1 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

设计是在Alpha阶段第一周由PM完成的，软工团队项目是和结对项目无缝衔接的，所以时间还算合适。

5.2 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

有，好比课程id这一部分，到底是一个递增的整数，仍是教务上的课程码，这一点并没能达成一致。后来id是按照整数算的，可是又加了一个code字段，用以和爬取的资源信息进行衔接。

5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其余工具来帮助设计和实现？这些工具备效么？ 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

并无用到这些工具，测试驱动的话感受时间不是很够，UML感受用处也不是很大，不过单元测试在beta阶段应当尝试一下。

5.4 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?

资源的上传，由于这里须要将文件从本地转移至服务器上，在发布以后出现的bug有“没法下载上传的文件”、“超过1M的文件上传失败”等bug。因为时间较紧，咱们只进行了简单的测试，没有想到“上传的文件也能够下载”这个问题；咱们文件的上传大小限制为10M，咱们前后尝试了上传1M如下和10M以上的文件，前者成功后者失败，觉得功能没有bug，却没有考虑到1M~10M中间可能出现的问题。

5.5 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

团队没有统一进行代码复审，只是PM在Alpha阶段结束以后浏览了一遍核心的view.py和interface.py两个文件。其中view.py中发现了未被调用的函数，这些有的是提早开发的Beta阶段的功能，有的是Alpha阶段废掉的函数。
代码规范较严格地遵照了，python部分大部分函数都在开头用注释标注了requires，modifies和effects，前端部分也遵照了npm的代码规范（不然编译都过不了……），只是没有规定变量的命名方式，这一点没有作到统一。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

设计阶段是软件开发的地基，值得重视。要是能重来，除了增强代码规范外，还要对设计进行充分的考虑，尽量完善接口和数据库说明文档。

---

6. 测试/发布

6.1 团队是否有一个测试计划？为何没有？

PM并无制定测试计划，由于当时PM认为测试是要依赖于开发的，因此更多留意了开发部分而忽视了测试部分。

6.2 是否进行了正式的验收测试？

在验收的时候，除了运行测试样例外，还进行了负载&压力测试，测试同窗还提供了一些优化建议。

6.3 团队是否有测试工具来帮助测试？

功能测试使用java版本的selenium，负载测试采用jmeter和badboy实现。

6.4 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？

咱们使用jmeter测试网站的性能，在alpha阶段后期进行了一次耗时两天的压力测试，模拟100个用户连续访问，请求响应的错误率为0，经过此次压力测试，咱们了解了网站的承受能力，固然此次测试也有须要改进的地方：

1. 运行压力测试时要封闭其余用户登陆，开放环境下压力测试获得的最大用户量比网站是实际能承受的用户量略小。

2. 只在alpha阶段快结束时进行了一次压力测试，测试的次数太少，鉴于两天的时间比较长，测试期间网站不能更新版本，从此打算每次测一两个小时，每周测一次，以追踪网站效能。beta阶段后期再进行一次较长时间的压力测试。

6.5 在发布的过程当中发现了哪些意外问题？

nginx默认的文件上传限制为1M，后来经过修改配置文件解决了这个问题。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

除了要制定开发的计划，也要制定测试的计划，并且要增长压力测试的次数。

---

7. 团队的角色，管理，合做

7.1 团队的每一个角色是如何肯定的，是否是人尽其才？

调查了一下各个同窗的意愿，最终状况是，前端是有过开发经验的两名同窗，测试是一名很细心、能力很强的同窗，然后端是对后端开发抱有极大兴趣的两名同窗。

7.2 团队成员之间有互相帮助么？

互相帮助是常常的，好比前端的两名同窗会常常讨论一些技术问题，出了bug以后你们也会很积极地寻找缘由。以前Ajax出现问题的时候你们也都积极地思考解决方法，并在群里告知你们。

7.3 当出现项目管理、合做方面的问题时，团队成员如何解决问题？

组里关系很融洽，至今没吵过架（捂脸）。有时候代码衔接出现问题或是任务分配不当的时候，成员们都就事论事，没有争吵，而是共同寻找解决的办法，这是令我很欣慰的。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

要了解每一名成员，包括但不限于长处、短处、性格以及时间安排等等，分配给每一名同窗最适合它的工做是坠吼的，可是作到这一点很难很难……

---

8. 总结

8.1 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?

我以为处于第一档次，由于没有一个较为完整的计划，管理经验不足，实际开发变动较多。

8.2 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?

我认为处于创造阶段，团队中全部人的努力都是为了最终产品的质量，总体氛围很和谐，为了更好地达到预期的效果，小组成员会主动学一些技术，出现问题的时候群里也会有交流。

8.3 你以为目前最须要改进的一个方面是什么?

任务分配，Alpha阶段任务分配太模糊了，组员不知道该作什么，应当作成什么样，这是PM的责任。若是能处理好这一点，规划好要实现什么，交付的标准是什么，明确了方向组员才能投入更多的精力在开发上，而不是在揣测“咱们要作什么”上。

8.4 对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。

• 不管团队内外，面对面的交流始终是最有效的沟通方式：每晚召开的Scrum Meeting上，除了汇报进度外，还会对开发中遇到的问题进行讨论，寻找解决方法。因为全部成员都住在三公寓7楼，有时候遇到问题也会直接一块儿商量，很方便。
• 可用的软件是衡量项目进展的主要指标：在先后端衔接的时候，关闭issue的条件是对应功能可使用

---

9. 全组讨论的照片