Alpha阶段事后分析博客
作业要求：Alpha阶段事后分析
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件要解决的问题是：现阶段各类组队招募、实习招募信息常常被埋没在大量微信聊天消息中，翻阅十分困难，且申请流程差异巨大，招募、申请的效率极低。
解决方法：通过微信小程序为同学们提供一个统一的，功能全面的招募信息发布平台，让同学们可以方便快捷的完成组队的招募、申请。
我们团队对于要解决的问题定义非常清楚，对于目标用户群体的划分也非常准确，具体，就是各个大学中的，希望组织或加入别人项目的同学们。
对于典型用户及场景的定义见alpha阶段测试报告
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划功能的实现：对于原定的完成完整的账户管理、招募发布、招募申请功能，我们全部完成了。
交付时间：比原定交付时间晚了一天。但我们预先留出了一天的缓冲期，因此没有影响其他工作。
用户数量：截止目前使用人数达到122人，达到了预期目标。
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
由于是自选项目，因此没有上一阶段。在下一阶段争取在代码规范、文档完整性上进一步提升。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户对功能的接受程度较高，反馈主要问题在于没有使用微信快捷登录的不方便，与网络异常时的缺乏提示。
这一阶段我们完成了招募，申请相关的主要功能，打下了一个坚实的基础，是迈向目标的重要的一步。
-
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
在刚开始的计划阶段，我们对于时间资源、人力资源的估计大于实际情况，最初计划实现招募发布、资源分享、跳蚤市场功能。因此最初在招募发布及申请的界面设计部分完成的不够精细。
随着进度推进，我们发现完整、精良的实现这么多功能是不现实的，因此决定投入剪掉资源分享，跳蚤市场功能，将招募部分做到最好。
如果重来一遍，我们会对每个人能投入的经历做更细致的统计，在开始阶段就对产品的最终形态有一个更准确的描述。
计划
-
**是否有充足的时间来做计划? **
是的，因为每阶段前都有半周时间作为计划与设计的时间，因此计划时间充足。
我们的计划流程是：
- 在开发阶段前，经过讨论，由PM决定这一阶段的总体目标，并以周为单位分解总体目标
- 每周前由PM规划本周的工作流程，将本周工作分解至不超过2天时间的具体工作。
这样的计划流程，保证了在每日任务不会过于臃肿的情况下，对项目整体进展有精准的掌握，确保主要任务的顺利完成。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
对于不同意见，我们会给成员充足的时间，通过语言、手稿等方式展示自己的想法，阐述这么做的原因，最后达成共识，或少数服从多数。
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作绝大部分都完成了。
对于少部分没有做完的工作，原因如下：
- 这部分功能的实现难度大于预期，可能会影响其他更重要的部分，因此将其延后
- 负责这部分工作的组员因实习加班没有时间实现
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
与微信账号不关联的，独立的账号注册功能。尽管这样方便与学号绑定，统一管理，但是用户体验差，相比微信快捷登录要麻烦很多。
-
是否每一项任务都有清楚定义和衡量的交付件?
任务定义：
- 前端：具体页面的原型图，其中按钮的功能
- 后端：数据库的详细设计规格，接口的详细设计规格
交付件：
- 前端：可体验的前端页面
- 后端：可供前端直接调用的后端接口
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
整个过程比较顺利。
意外及风险：最大的意外在于好看的前端的设计难度，大于我们的预期。小意外是第一次小程序的发布审核没有通过。这一点会在发布版块进行详细阐述。
没有估计到得原因：没有估计到的原因是，团队所有成员都没有相关的设计经验，因此对设计相关工作的预估有较大偏差。
-
在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区：在计划中我们在开发、测试发布阶段都留出了一天的缓冲区。
作用：计划与实际难免有偏差，考虑到修改时间、再次发布需要的审核时间，一天的缓冲区是十分必要且有用的。
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将前端页面的具体设计、后端新增数据库及接口的规格设计提前，在提出功能需求时就先将设计具体化。
这样能对新功能的实现难度有更准确的了解，让我们的计划更加合理。
-
我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们的经验合理的计划，尤其是合理的任务顺序，有助于提高主要功能的完成质量，也有助于成员们对新知识的学习。
若重来一遍，我们会将计划的工作提前，并将学习相关的任务开始任务提前，持续时间缩短，为开发留出更多时间。
资源
-
我们有足够的资源来完成各项任务么?
基本足够。最紧缺的是时间资源，因为有团队成员忙于实（jia）习（ban）、考研加分相关的比赛等。
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
在计划阶段，经过讨论后主要由前后端负责人估计。除页面设计外，其他工作估计精度准确。
-
**测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? **
测试阶段的各类资源足够。因为留出了足够的时间进行测试。
对于美工设计，我们确实低估了难度。在下一阶段我们会留出足够的时间去提高这部分工作的质量。
-
你有没有感到你做的事情可以让别人来做（更有效率）?
有时会有这样的感觉。毕竟每个人不可能分配到处处都最适合自己的工作。但是我们相信每个人专注于某一项工作，效率比频繁切换任务、挑选合适自己的任务更高。
-
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
美工设计这一工作，对于没有任何基础的人来说真的非常困难。
如果重来一遍：我们会在计划阶段寻找大量的app、小程序设计模板，通过模仿来提高设计的效率及质量。
变更管理
-
每个相关的员工都及时知道了变更的消息?
是的。因为每日的讨论及交流非常频繁，团队成员往往也一起吃饭、上课，因此消息的同步速度很快。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们认为一个功能的重要程度，取决于这个功能的缺失对产品的功能完整性及用户体验的影响程度。
-
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?**
出口条件：
有完整的账户管理、招募发布及招募申请功能。
其中招募发布及申请的功能的完整定义为：能够发布、申请招募、接受他人申请、能查看自己的发布、申请的状态。
-
对于可能的变更是否能制定应急计划?
能。若每日总结时发现有任务未能完成，会对本周接下来的任务、项目总体计划进行及时的更改。
-
员工是否能够有效地处理意料之外的工作请求？
能。比如临时新添接口的设计、展示用各界面的屏幕捕捉gif等，这类临时工作我们会优先分配给平时完成任务较少的同学，即保证了公平，也给他们赚取更高贡献分的机会。
-
我们学到了什么? 如果历史重来一遍,我们会做什么改进?
我们的经验：在一开始就明确一个阶段目标，并尽量不对其进行更改，能提高任务的完成质量。
如果重来一遍：我们会在分配每日任务时，及时的将任务细分到人，明确每个人的责任。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
时间：设计工作在设计与发布阶段完成。
人：整体产品的设计由所有人讨论后，PM汇总。
前后端具体设计由前后端负责人进行。
-
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在重要部分的设计上都经过了统一，没有这种情况。
在一些小问题上，比如侧边栏上按钮的顺序，交给具体实现的人负责决定。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
使用的工具：使用了单元测试。使用的工具是
Django Coverage。除此之外还使用了git bash管理代码，issues管理任务，process on进行原型图的设计。这些工具还是能提高相应任务的完成效率及质量。
没有使用UML文档，但是有前后端相应的详细设计文档。
-
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
产生bug最多，也是我们发布后发现的是与后端的连接，通信问题。常常出现校园网较快但4G较慢的问题。这一点的问题我们仍在排查。
在开发过程中没有发现是因为微信开发工具在电脑端，因此预览时都使用校园网，没有遇到过这一问题。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审：代码复审主要由前后端的负责人进行。
对于代码规范的执行程度仍需要提高。尤其是前端。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们的经验：设计的越详细，设计阶段付出的经历越多，往往开发阶段能省下更多的精力，少走弯路。
如果重来一遍：我们会更加详细的实现我们的设计原型图。这样有助于更加精确的设计我们所需的功能与相应的前后端需求，减少后面修改的次数，提高开发效率。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有。在开发阶段结束后分别对前后端进行测试。详细测试请见alpha阶段测试报告
-
是否进行了正式的验收测试？
是的。在申请发布小程序前，我们对所有页面及功能都进行了一边复查。
-
团队是否有测试工具来帮助测试？
使用了
Django coverage来跟踪我们的单元测试的代码覆盖率。 -
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
主要通过在前端测试时记录小程序的效能。
在下阶段我们会更加全面的进行压力测试，测试并改进我们的服务器。
-
在发布的过程中发现了哪些意外问题？
在第一次发布时，由于涉及信息发布功能，属于个人版小程序禁止的功能，因此未能通过审核。
经过说明并提供了教务处学生信息截图等信息后，终于通过了审核。
-
我们学到了什么? 如果重来一遍， 我们会做什么改进?
我们的经验：安卓与ios端必然会存在不同，尽管微信小程序的开发对两种操作系统相同，但仍然要考虑系统差异可能带来的问题。
如果重来一遍：我们会进行压力测试，并根据压力测试寻找服务器不稳定的原因，改善服务器的表现。
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
确定依据：根据每个角色的性格，实践经历及个人能力确定。
在各个阶段，团队成员遇到困难时都会收到在相关问题上经验较为丰富的人的帮助。我们认为这也是一种“人尽其才”的表现。
-
团队成员之间有互相帮助么？
有。主要是实习经验丰富的同学对于一些工程经验的传授、以及技术能力强的同学对于后端方向、做法的指引。
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
出现问题时，首先通过QQ、微信通知对方，能在线解决的小问题争取在线解决。若问题比较复杂或者麻烦，就到某一方的寝室详细讨论，当面解决。
总结
-
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我认为我们目前处于
已定义级与管理级之间。我们对于技术及管理工作，已经实现了标准化，文档化，也对各自的岗位与职责有统一的，清楚的认识，但是，对于下一级管理级所提到的生产率、质量的量化、过程数据库等，我认为任务issues管理、每日例会以及燃尽图的管理，已经具有了这些要求的雏形，但我认为这些与真正的“量化”还有差距。仍然不够细致，达不到完全量化的要求。 -
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我认为我们的团队目前达到了
磨合阶段。对于第一阶段，即
规范阶段，我认为我们在以下方面还需改进：- 我们的工作积极性有待提高
- 领导职责较为集中，还未能建立起人人都能承担一部分领导职责的环境。
-
你觉得目前最需要改进的一个方面是什么?
增加团队的工作积极性及代码的规范性。
-
对比敏捷的原则，你觉得你们小组做得最好的是什么？
我认为我们小组做的最好的是：
-
1、尽早并持续地交付有价值的软件以满足顾客需求
我们的第一阶段的任务明确，即完成一个可用的，功能完整的产品。
在过程中，我们的具体实现过程如下：账户管理->招募发布->招募申请->我的招募->我的申请
每一过程中都保证了现阶段的功能可用性与完整性，履行了敏捷开发原则的第一条。
-
6、无论团队内外，面对面的交流始终是最有效的沟通方式
我们团队的成员面对面沟通的时间远大于在线交流时间，尤其是前、后端主要开发人员，在开发时基本是当面一起编程，保证了交流的效率。
-
7、可用的软件是衡量项目进展的主要指标
在计划时，每阶段任务基本以可使用的，功能完整的页面作为任务目标，因为这一目标涵盖了具体的前端页面以及配套的后端数据库。
在实际开发过程中，每日总结时也以具体页面的完成情况、页面中功能的完整度作为衡量的主要指标。
-
-
在下一阶段中我们要改进的地方
- 日任务的具体分配，提前至任务开始3天左右：这样让团队成员清楚自己接下来几天的任务，方便成员自己协调时间，这样即使某一成员在某天无法开发，也可以通过自己协调时间，将那一天的任务分散到其他时间完成。
- 细化、美化前端的设计原型图：在下一阶段，我们会将页面的设计原型图细化，并参考优秀的设计模板，提高原型图的质量，提升前端整体的审美体验。尤其是增加图片、图标，避免页面显得十分单调。
- 进行压力测试：在下一阶段开发结束后，除了延续现阶段完整的前端测试、后端单元测试外，我们还将对服务器性能进行更加详细的测试，同时进行压力测试，为改善服务器表现作出更大的努力。
- 提高成员工作积极性、自主性：根据分配的具体任务，成员们自主、积极的完成各自工作，并希望能对完成的任务进行力所能及的优化，而不仅仅局限于满足完成任务的最低要求。
讨论照片
