beta事后分析
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
软件要解决的问题是是开发一个简易方便，为用户带来便捷且功能齐全的表情包管理小程序；
预期的典型用户是在日常网络聊天中喜欢使用表情的广大网友；
预期的功能包括商城搜索表情功能，表情评论功能，表情标签管理功能，表情推荐功能，回收站恢复表情功能，关注用户功能，本地表情收藏管理功能，表情上传功能，表情编辑功能等；
具体的描述可以查看功能规格说明书，Beta版本发布计划
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
在Beta阶段我们的目标是在alpha阶段的基础上进行统一的UI设计调整和一些新功能的增加，注重提升用户的使用体验和乐趣，因此我们设计增加了许多个性化的功能，例如表情评论、表情推荐等，除了少数实现难度较高的功能之外，我们基本完成了原计划的功能实现，并且做到了在交付时间内完成交付。
预期的用户数量包括身边的亲朋好友，同学，以及网友等，大概估计在150人左右。目前小程序的累计使用人数已经超过了3000人，远远超出了开始目标，较之alpha版本也有了较大的提高。大量的用户从我们的平台获取表情，下载图片，虽然上传次数仍然比不上下载次数，但是较之alpha版本也有了进步。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上一个版本相比，我们团队的工程质量有了显著提升。
首先是代码管理部分，上一个阶段我们虽然使用了github，但是基本只是使用了部分的功能，全部人对一个仓库创建分支进行操作，这样子并不是很规范。在beta阶段我们每位成员在自己的github上fork下来代码仓库，使用pull request来更新代码，组长审核代码之后再合并进入总仓库。
其次是关于任务的分配，我们在每次会议布置好下一次会议前需要完成的issue，并由组长分配给组员，小组成员需要在两次会议间隔内完成功能，然后再下一次会议上由小组成员共同审核，通过则关闭issue。
然后是UI设计部分，我们在这个阶段构建了一个统一的UI组件库，涵盖有我们需要使用的所有组件，需要时直接调用组件库即可，这样既方便高效，也使团队开发风格统一。
最后是测试部分，我们在每一次会议都会对每一个issue的完成情况进行审核和测试，测试出来的bug及时反映到issue的评论中，直到所有bug确认被解决才能够审核通过关闭issue。这些操作极大提高了我们测试的效率，保证了测试的及时反映和解决，提高了我们的工程质量。
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量目前已经超过了3000，大大超出了我们预期的用户数量
大量的用户从我们平台下载表情和图片，说明对我们平台是有一定的认可的。可以看出虽然上传次数比起下载次数差距仍然很大，但是与alpha版本相比已经有了较大进步，说明我们在beta阶段增加的新功能和UI的改进促进了用户对图片的编辑上传和分享，增强了用户的黏性，总体上我们离目标更进了一步。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
虽然本阶段比起上一阶段无论是代码质量上还是开发流程上都有了长足的进步，但是在过程中我们仍有一些不足和错误需要改进和改正。例如我们对issue的划分其实并不足够精确，会出现有划分的issue任务量太大而导致多次会议难以关闭这个issue，issue量的不均衡也对我们的贡献统计和任务分配有一定阻碍。我们需要的是缩小issue的尺度，并且尽量保证issue之间差距不过于悬殊。
计划
**1.是否有充足的时间来做计划? **
时间很充足，在alpha阶段发布之后，我们就投入到了beta阶段的讨论中了。在这之间大约有一周的时间给我们商讨beta阶段的工作，在这期间，我们通过两次会议和微信讨论的形式确定了beta阶段的方向和工作。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
在商讨阶段常常会出现对未来工作意见不合的现象，这是因为我们小组之间会进行相互提意见的阶段，由于不了解对方的工作量，常常会有一些超过我们能力的建议。这是我们会将问题统一起来，通过会议咨询每一个小组对于自己所负责任务的分配是否合理，是否能够接受，在商讨中获取最后确定下来。
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划的工作基本完成了，一开始的计划就比较充足，所以计划量也是每个人能够接受的，最终都能够按时完成。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
基本上没有，倒是在制作中不断的丰富新功能。
5.是否每一项任务都有清楚定义和衡量的交付件?
有，在计划之初我们就做好了最终交付的预期，在每次会议之前我们都会整合已经实现的功能，并相互检查对方工作是否达到了我们的预期要求。对于已经符合要求的功能，我们会将它所对应的issue关闭。如果没有到达预期的要求，我们将会在issue下方写下意见，在下次会议时再次做出检查。
**6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到? **
基本上都按照我们的计划完成了。可能有一些计划因为难度和不可预知BUG的出现，让它在很多次会议之后都没有解决，这就会导致工作量的不断叠加。如果出现了这种情况，我们会削减一部分不必要的计划，保证我们主要的计划没有受到影响。
7.在计划中有没有留下缓冲区，缓冲区有作用么?
有缓冲区，在计划时我们将任务划分了重要性的高中低。首要完成的当然是重要性为高的任务，当有高重要性的任务受到搁置时，我们会按照情况删减低级重要性的任务。保留缓冲区的好处时我们可以为我们的最终任务提供一定的时间保障，让我们能够保证高重要性任务的完成质量。
8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来会按照计划继续完成剩下的工作，不会用很大的变动了。
我们学到了什么?如果历史重来一遍, 我们会做什么改进?
我们学到了计划的重要性，计划对于一个团队可以说是方向指导书，有了计划之后我们可以随时评估自己工作的进度和剩余的工作量，从而来对之后的计划进行改进。而想要制定一个合理的计划表，需要花一定的时间进行讨论修改，但这付出都是值得的。如果能够重新再来一遍的话，我们将会更加细致的划分任务，将我们的工作任务细致划分可以帮助我们计划的更加合理有效，在完成实现时也会更清晰。
资源
1.我们有足够的资源来完成各项任务么?
有。计划阶段完成的比较好，所以无论是在时间还是技术上都能够在最终发布前较高质量的完成了任务。也许有些任务难度会超出我们的预计，但通过其他低重要性任务的削减可以有效的提高任务的质量。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
在有了alpha阶段的开发之后，我们有了一定的评估能力，由于微信小程序的开发方式，基本能够估算出任务的难度。在有不确定的任务时可以与其他的组员进行交流。最终任务都如期的完成了，说明我们的准确性还是比较高的。
**3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度? **
由于任务的独立性和整合的简易性，我们的测试阶段分配在了beta阶段的每次会议之前，以及最终的集体总测。测试的时间，人力和软件/硬件资源开销都不是很大，完成度较高。美工设计和文案所需的资源也是比较大的，有了alpha阶段的铺垫之后，我们对于这类资源的开销估计还是比较准确的，没有低估他们的难度。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
一开始在交叉功能移植时我们采用的时负责页面的小组将其他小组开发的功能移植到自己的页面中，但是这样的效率并不高，还时常会出现自己无法解决的BUG。所以之后我们决定将移植功能的任务交给开发这个功能的小组来完成，果然效率比之前提高了不少。
有什么经验教训?如果历史重来一遍,我们会做什么改进？
主要需要分配的资源还是时间，时间的管理离不开计划，所以归根结底还是要在一开始有一个合理且完整的计划，让我们在开发中能够合理的安排各项资源。
变更管理
- 每个相关的员工都及时知道了变更的消息?
我们重要的变更消息会在每日例会上提出，大家一般都会按时参加，所以对于做出的变更消息和决策内容都会有所了解，同时PM还会将每日例会的重要内容发布在github上以及微信群里面，大家都会及时收到消息；
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们主要根据功能的重要性和难度来决定是否“推迟”或者“必须实现”，在设计开发中涉及到开发目标最基本的使用功能，这些是必须实现的，比如我们小程序中表情的各种编辑功能，本地表情管理的回收站等基本功能，这些是宣传我们小程序不可或缺的功能；而有一些技术难度较大，不太影响基本使用的功能我们会进行推迟，比如数据库中有些表情无法访问显示，部分页面加载较慢等；
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们每一个功能实现的出口条件都要满足预期issue中的使用功能完备，同时在每一次迭代测试中提出的bug全部解决后才算做好了；
- 对于可能的变更是否能制定应急计划?
我们的分工都比较具体，每一个小组负责的页面和版块都划分地很清楚，如果对于某一项功能需要作出变更修改，我们可以找到具体负责的组员来解决，这样效率会更高；
- 员工是否能够有效地处理意料之外的工作请求？
对于开发设计中没有意料到的问题Bug，组员之间都会相互讨论好解决办法，最后落实到负责该页面的同学上，大家都会尽力去解决出现的bug，最后的效果也比较好；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在beta阶段的变更管理上，我们并没有做出过多的计划，导致我们在遇到一些突发问题时会浪费更多的时间来调整计划，在以后的开发中我们需要制定一些解决突发问题的预留方案和时间；
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们在每日例会上PM会针对各组负责页面版块的特点，制定相应的功能设计任务，每一个功能页面都有具体的小组负责；因为beta阶段新增的功能都是在alpha开发设计的基础上完成，所有beta阶段的功能分配都是合适的小组来完成；
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在工作中会遇到一些功能设计和UI设计的意见不同，但是大家都会在例会上提出自己的见解和方案，最后再确定最终解决方案来执行；
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们主要使用的微信开发者工具来完成项目开发，并未用到以上工具；
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
每个小组负责的部分都有相应地bug，比如在本地表情收藏出现的管理功能失效，表情编辑页面对表情图案处理的不当，商店页面的推荐表情不完善等，但未出现bug特别多的功能；
发布后主要发现在商店页面中部分表情无法显示的bug，因为在开发过程中的技术受限，所以没有能够处理掉这个bug；
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们主要通过每日例会上对之前页面功能的互审来提出bug，每一个小组都负责检查测试另一指定小组开发功能的bug，然后与其交流修改；在代码规范上，我们都采用一个设计模板来进行开发设计；
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果开发设计可以重来，我们需要更多考虑设计过程中功能之间的联系，而不是想到什么可以做什么就去设计什么，我们需要考虑这些功能的协作成一个功能体系来更好的满足用户需求；
测试/发布
- 团队是否有一个测试计划？为什么没有？
团队有一个测试计划：每次开会之前，小组成员对新增的及以前的功能进行测试，采用的测试方法是小组互测，在功能开发完成后，小组安排了一个专门的时间进行测试。
- 是否进行了正式的验收测试？
Beta阶段进行了非正式的验收测试，未遵循的特定测试用例，测试内容由各测试员决定，不象正式验收测试那样组织有序，而是更为主观。
- 团队是否有测试工具来帮助测试？
团队没有测试工具来帮助测试，采用的是手动测试；改进计划：可采用微信小程序自动化测试，小程序自动化 SDK 为开发者提供了一套通过外部脚本操控小程序的方案。
- 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
团队通过手动测试（虚拟机测试及真机测试）的方法测量并跟踪软件的效能；压力测试通过上传成百上千张表情包、在网络状况较差的环境下来测试；从软件实际运行的结果来看，这些测试工作有用，改进：压缩表情包大小，更新页面时只更新变化了的部分，其余部分维持以前显示，而不是每次都重新加载整个页面。
- 在发布的过程中发现了哪些意外问题？
发布过程中，出现了用户帐号登录规范调整和优化建议、UGC类小程序运营等问题。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
以前我们小组成员大多没深入了解前端，因此，在测试阶段，我们学到了UI方面的重要性，用户体验问题也需要重视；
在发布阶段，我们学会了如何成功发布小程序，了解到了小程序相关审核方面；
改进：测试需要改进，成员之间加强交流。
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
我们的角色分工沿袭alpha阶段的规定，每个人报名参与不同分工。我们的分工虽然不能完全做到人尽其才，但是也在很大程度上尊重了每个成员的个人意愿。
- 团队成员之间有互相帮助么？
在项目的许多方面，团队成员之间互相协作、互帮互助。比如g同学曾经在微信小程序的云函数方面遇到一些困难，得到了队友的帮助。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们的团队采用分组的形式来开发不同的模块，不同小组的任务分配服从PM的管理。小组之间有时存在一些任务交叉，对此不同小组的成员通过每日例会或私下交流进行协商、协作。具体到一个小组内的任务分配，小组成员往往可以通过自行协商，实现高效、合理地分工。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。
**总结: **
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得我们团队的状态属于CMM的已定义级。因为我们团队已经在一定程度上实现了软件过程文档化与标准化，每个开发环节都有对应的文档、每个单元模块都有具体的规格。并且，我们采用了评审方法，在互测、审核方面比较严格。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
已经达到规范阶段。正如上个问题的回答所述，我们已经在一定程度上实现了软件过程的标准化。从分工、编码到测试，我们的开发流程已经形成了规范。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队成员的协作能力相比上一个阶段而言，都有很大的进步。不同小组之间的协作更加高效，很多比较复杂的任务能够通过协商与交流，在短时间内细分并具体分配。同时，小组内的成员由于经过了alpha阶段的磨合，合作更加愉快、更加高效。
你觉得目前最需要改进的一个方面是什么?
在团队的编码规范方面不够完善，并没有像之前面向对象课程一样，有一个比较细致的规定。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
1.我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
我们的开发过程节奏很快，每次例会分配的任务要在下次例会之前完成，也就是说，我们每1-2天就会有一个新的迭代，并及时地提交微信官方审核。用户们能够持续不断地使用新版本的小程序。
2.团队定期地反思如何能提高成效，并依此调整自身的举止表现。
我们每次例会都要进行反思与总结，团队成员要反思自己在上次例会之后的开发过程是否存在缺陷，例会上每个小组都要提出自己在开发过程中遇到的最新问题，并积极探索、讨论解决方案。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
结合github的pull/request功能，代码的每次签入都要指派给专人负责审核。指定明确、细致的编码规范，通过人工审核或IDE工具审查代码，实现代码规格化。
- 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
充分利用小程序云开发的优势，将页面逻辑层的部分功能移植到云函数中，由微信云端进行计算而非小程序端计算，提高性能。将逻辑层的函数移植到云端后，重新测试功能模块的时间开销，将移植前后的时间开销进行对比，量化质量上的提高。
- 其它软件工具的应用，应该如何提高？
由于项目的特殊性，我们的开发工具以微信小程序官方IDE为主，基本上没有使用额外的软件工具以及插件。我们要了解更多官方IDE的功能细节，熟练掌握页面调试、灵活运用IDE的github管理功能。
- 项目管理有哪些具体的提高？
(1)对于github的使用更加熟练、高效。我们在beta阶段使用pull/request管理项目，团队成员的开发成果可以实时地整合到项目中，项目的迭代过程一目了然。
(2)互测互评环节更加完善。在例会之前每个小组要对其他小组新实现的功能模块进行测试，找出bug与设计缺陷，并在issues中进行评论。这些bug与设计缺陷将在例会后由对应的小组进行修复，直到所有的问题完全解决，该issue才可以被关闭。
- 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
得益于微信小程序官方IDE提供的用户数据追踪功能，我们可以实时地获取一些用户数据，比如日活跃用户、周活跃用户、月活跃用户、用户注册小程序时间与微信昵称等数据。我们要提高的方面主要是对用户个人信息的采集，比如用户的年龄、性别、职业等，这些信息或许可以通过调查问卷来进行采集。
- 项目文档的质量如何提高？
目前我们的项目文档是由PM撰写。如果每名成员根据分工撰写对应的项目文档，在每日例会上由其他成员进行评审，或许会由于任务量均摊而更加高效、高质量。
- 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
在绩效考核方面，对于任务量的评定需要改进。目前任务量的评定主要考虑issues的大小、博客数量等因素，而最关键的issues大小的评定还是比较主观，没有量化标准。
- 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
"计算机科学!=软件工程"，理科与工科存在很大的差别。但是计算机系的学生也应该具有一定的工程能力，具体体现在编程与设计上。对于一个项目，开发者的灵感不仅来源于大量的经验积累，也来源于数理基础与逻辑性思维提供的“理性的直觉”。
