Alpha事后分析

Alpha事后分析

设想和目标

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

软件要解决的问题是是开发一个简易方便，为用户带来便捷且功能齐全的表情包管理小程序；

预期的典型用户是在日常网络聊天中喜欢使用表情的广大网友；

预期的功能包括商城搜索表情功能，本地表情收藏管理功能，表情上传功能，表情编辑功能等；

具体的描述可以查看功能规格说明书

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

alpha阶段我们的目标是实现一个最小可用版本，即基本满足了用户对于搜索相关表情，以及对表情进行编辑、分享的使用需求；
预期的用户数量包括身边的亲朋好友，同学，以及网友等，大概估计在150人左右。目前小程序的累计访问使用人数已经超过1200人，已经超出预期的使用人数了。

反思：可以看出用户大量的从我们的平台获取表情，但是上传的次数不足。我们也会根据这样的信息在下一个阶段调整我们的计划。

3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

无上一阶段。

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

目前小程序的累计访问使用人数已经超过1200人，已经超出预期的使用人数了。

可以看出用户大量的从我们的平台获取表情，但是上传的次数不足。我们也会根据这样的信息在下一个阶段调整我们的计划。

我们在以后的部分需要在功能方面作出更多的功能，这样我们的软件才能有更大的粘性。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

本阶段做的还算不错，我们需要制定更加详细的计划，然后提前设计UI，避免在之后的工作中反复修改。

设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在开展alpha阶段的工作之前的三次会议中进行的。大家在会议中都积极发表自己对于项目设计的意见，经过权衡商讨出最终的模型。

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

有。比如说之前对于数据库结构，各个小组之间没有具体的规范，每个小组都是按照自己的设计需求在设计，所以最终合并时遇到了较大的麻烦。为了解决这个问题，我们召开了紧急会议，讨论出了一个具体清晰的数据库结构，大家加班加点进行了统一。

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

由于微信开发没有自带的测试功能，所以我们对于项目的推进基本都是靠issue的发布以及每次迭代之后的小组之间的互相检查各自的工作。我们之后会借鉴其他微信开发小组对工作的管理方法。

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

应该是一些下小组之间所开发的方面有所交叉的功能，在合并之后会产生一些之前单独测试时没有发现的BUG。在设计/开发时我们每个小组所负责的功能都是比较独立的，没有预想到在之后的合并阶段会有很多的重叠部分。在测试阶段如果发现这类的BUG，我们会让两个小组的成员讨论BUG可能出现的原因，合作进行解决。

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

我们所做的代码审查基本上都是在会议上进行的，每位成员都展示自己在这次开发中所遇到的问题，大家一起来帮助他解决。因为是相对较独立的开发，所以对每个独立的部分我们没有具体的要求，但对于大家都会调用的云函数，我们的成员在编写每一个时都需要写一个相对的使用说明，便于其他成员的使用。

我们学到了什么？ 如果历史重来一遍， 我们会做什么改进？

• 在下手工作之前要尽量想到每个工作的细节，避免之后的返工。
• 在开展工作时应该更加注意代码规范，便于之后其他成员的理解。
• 增加小组之间的交流会让项目最终的合并更加方便。

计划

是否有充足的时间来做计划？

我们在每次开会的时候都会明确我们在下一阶段的任务，讨论明确并全体统一意见后再分配给各小组执行。得益于scrum meeting的高效性，我们在1-2个小时内会将计划确定。

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

因为我们小组是按照模块分工的，各部分相对比较独立，小组之间的不同意见比较少。当遇到不同意见时，我们会当场协商解决。实在有冲突的话，采用投票的方式来决定。

你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？

原计划的工作都已完成。我们一共进行了10次的scrum，每次制定的任务都在我们的掌握中。首先在github上创建issue，到下次会议时，我们的issue会全数关闭。

有没有发现你做了一些事后看来没必要或没多大价值的事？

在我负责的部分，第一次的规划有图片压缩和上传命名的任务，完成alpha项目发现这两个功能并未使用到。对于图片压缩，因为对图片编辑时我们会指定合适尺寸，没必要压缩。如果进行压缩反而会成为一个bug，这个没必要做。对于上传命名，这个需要负责云端和数据库的同学根据自己的规定完成，我当时设置的命名格式除了防止重复之外，并没有什么用处，是一个没有价值的任务。

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

是的，我们每次的任务都会写在issue里，在石墨文档中也会记载相应的必要程度。

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

我们在发布项目时出现了意外情况。合并各小组的工作并完善后，发布小程序时，微信官方打回了我们的项目，原因是我们的上传图片和编辑图片的文字没有使用微信的安全检测云函数进行检测。在上传图片和文字时，应注意一些不良图片和文字不应传播。一开始我们未意料到，打回之后才匆忙修复。因为我们对公众平台的审核规则不了解，导致了这次意外。

在计划中有没有留下缓冲区，缓冲区有作用么？

留下了缓冲区，最后一周我们没有进行功能的开发，主要用来对各个模块的功能进行测试和适应性调整。在该缓冲区，我们对一些比较“别扭“的操作进行了调整，并测试了许多未注意到的bug，完善了项目。

将来的计划会做什么修改？

• 我们会更加明确缓冲区的时间和所要做的任务；
• 尽量避免大段时间的留空，划分任务更精细一些，使任务交付更加及时。

我们学到了什么？如果历史重来一遍，我们会做什么改进？

• 前期我们会花费更多时间讨论规划，防止无价值的任务产生；
• 加强对微信公众平台发布规则的理解，防止发布时产生重大的意外。

资源

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

在人员配置上，我们一共有六名同学共同开发此次的软件开发设计，其中每两名同学组队负责一部分页面版块工作，一共有三组来完成不同的页面功能设计，从最后的完成进度来看，各组都能按时完成各自的任务；在开发过程中，我们可以借助微信开发者工具以及设计帮助文档来完成小程序的开发设计，在项目合并上，我们也借助github平台来分工合并代码，直到设计完成。

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

在准备设计开发工作之前，我们就决定将开发任务拆解来分配到各组完成，这样可以大大提高效率。在完成下一阶段开发工作之前，我们在每日例会上确定下一步各组需要完成的任务，提前制定issue，在下一次例会上我们就展示各组完成的进度。有的时候各组定的目标在实际完成中会有所偏差，可能遇到考虑范围之外的问题，但是大致上大家对任务的估计还算准确，可以按时完成。

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

在测试的方面，由于我们是小程序开发，在代码测试上稍有局限性。对此，我们花了两轮的bug检测时间，通过各组之间相互审阅代码，使用相应功能来提出问题，最后再落实到责任小组进行bug改进；在设计美观上，我们特意安排一组同学来进行界面优化，避免在之前的分工设计中，不同组负责的页面设计风格差异过大。在整体的设计风格上，我们的目标暂时是简约，让用户可以有良好的体验。

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

由于大家都是第一次进行小程序的开发，无论是项目经理，还是前后端，都尽职做到自己最好，按时完成自己的进度，整体来说没有出现有人拖后腿的情况。

有什么经验教训?如果历史重来一遍, 我们会做什么改进?

如果可以重新再来，我们希望在代码规范和代码风格上稍作约束，不然的话不同组之间的代码风格差异过大，导致双方有些工作汇总对接有一定难度。

变更管理

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

关于变更消息，我们主要在每日例会上提出讨论，共同商讨出遇到的问题和可行方案，最后决定出下一步的方针策略，所有在例会中组员都会参与到其中并收到关键消息内容；在各组内部，由于我们是两两一组，所以双方对于组内的设计调整可以私聊解决，如果组内有变更涉及到了其他组的开发任务，也会及时在群里提出。总的来说，大家对于变更消息的收获渠道还是比较靠谱稳定，没有出现消息滞后的情况。

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

对于必须实现的功能，我们首先要考虑的是我们的软件目标是什么，用户可以从我们的软件得到什么，基于我们软件存在的必要性和特殊性，我们先决定好软件如果投入使用必须有的功能。因为我们是表情包管理软件，所以首要完成表情的搜索，编辑和本地管理分享的基本功能。对于优化搜索，商城机制等进阶功能，我们可以稍作推迟进行开发设计。

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

我们项目的出口条件是能够提供表情包的基本功能：

表情的搜索，表情的编辑，本地表情库的查看管理，表情的分享功能。

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

可以，如果组员在开发过程中遇到一些问题影响到整体的进度或是在测试过程找到bug，大家都会当天例会上提出，通过讨论后，项目经理会安排特定的组员来解决问题，通常该组员负责和问题相关的任务进度。

员工是否能够有效地处理意料之外的工作请求？

我们的组员基本上都能接受意料之外的工作请求。在设计开发过程中，大家都是第一次合作开发小程序，难免遇到各种问题，由于PM分配的任务比较合理，大家也很积极完成各自的工作任务，对于意料之外的任务，PM也会合理分配给相关小组，后续有问题大家也可以提出共同解决。

我们学到了什么?如果历史重来一遍,我们会做什么改进？

在实际的软件开发中，也许我们会在开始工作前，做出各种计划打算，评估相应的任务，但是在执行的过程中我们难免会遇到各种麻烦。变更是设计开发中比较重要的一环，我们对于遇到的问题要及时发现提出，并做出相应变更来适应新的开发环境。

测试/发布

团队是否有一个测试计划？为什么没有？

我们团队的测试计划如下：

• 首先在分组开发期间，三个小组分别开发并测试不同的功能模块。功能模块是基于小程序页面的，在完成页面的每个功能后，开发者要进行三项测试：微信小程序IDE自带的预览调试、数据库交互测试、真机调试。预览调试用来测试页面逻辑是否正确，程序能否正常运行，是最初步的测试；数据库交互测试用来测试基于云开发环境的数据库存取能否正常进行，同步与异步关系是否正确处理；真机调试用来测试页面能否在手机端正确渲染。一个功能必须要通过这三项测试，才可以merge到公共的项目分支。

• 之后在项目合并阶段，我们将三个小组的功能模块进行整合，并进行互测环节。每个小组的两名成员分别测试另外两个小组的功能模块，以真机调试的方式进行测试。每人都要找出对方的至少5处功能bug或设计缺陷。各组根据反馈的bug进行修改和优化，之后再次进行模块整合。

• 在最后的验收阶段，将整合后的项目提交审核，根据微信审核的结果做进一步的微调、bug修复。此外，进行压力测试，团队成员反复使用搜索、上传、下载功能，模拟用户请求频繁时的程序运行情景。

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

通过微信小程序平台的审查，本身就需要严格的验收测试。我们的项目曾被微信审核打回，经过反复的测试与修改，最终正式发布。如上一个问题所答，我们在验收阶段的测试还是比较严密的。

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

我们的开发环境是微信小程序开发平台的IDE，虽然可用的插件并不多，但是它自身的功能还是比较完备的。在对功能模块进行测试时，我们利用了IDE中的预览调试、页面调试、真机调试功能，没有用到额外的辅助开发工具。

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

我们根据不同的功能模块，分别测试了响应时间（真机调试环境）。遍历标签集合对数据库进行表情检索，最大响应时间约为15s；上传图片至数据库（云端存储），最大响应时间约为2s；下载图片至本地，最大响应时间约为2s。这些测试工作真实地反映了用户在使用我们的小程序时的体验，只有对软件的性能心中有数，才能更好地找到我们今后工作的方向。

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

1.图片添加文字的内容没有审查机制，导致项目被微信审核打回。对此我们调用了专门的文本合法检测的接口，简单地对添加文字进行了审查。
2.由于微信小程序对于一些爬取到的网络图片的地址并不支持，用户有时会无法下载图片库中的图片。目前我们尚未找到合适的解决办法。

我们学到了什么？如果重来一遍，我们会做什么改进？

我们真切地体会到了团队开发的流程，学习了微信小程序的框架与云开发知识。如果重来一遍，我们会提前学习微信小程序的相关知识，并且对各项需求做进一步的细化、具体化，提高开发效率。

质量提高

代码管理的质量具体应该如何~提高？ 代码复审和代码规范的质量应该如何提高？

继续使用GitHub的代码管理功能，改变之前时的不足部分，将代码合并至主分支上。同时应该使用一些对于代码风格审查的软件来帮助我们开发。

整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

我们认为我们程序的整体构架基本没有问题，有些地方可以将其构造成云函数以提高复用性和简洁度。可以通过小组之间的互相阅读，看能否理解其他小组的工作来判断质量时否提高。

其它软件工具的应用，应该如何提高？

应为微信有自己的代码审核系统，所以我们应该去仔细阅读官方的规范文档，要与官方要求保持高度的一致性，设计应该尽量简单。

项目管理有哪些具体的提高？

首先要将项目放到Github的master分支下以便于管理。其次issue的分工应该更加细化，issue的添加应该及时。commit中的信息应该更加具体易懂。

项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

微信小程序开发平台IDE在用户数据的跟踪方面具有得天独厚的优势。我们在云开发管理平台上可以方便地查询每日的用户登录量、数据库访问次数、云存储中的图片下载与上传次数。所以我觉得在跟踪用户数据方面，我们并不需要做额外的工作。但是我们可以在用户数据的整理、统计方面做一些提高，比如对每日用户量、周活跃用户量、用户总量做一些统计工作，还可以通过问卷调查的形式统计用户的性别、年龄、职业等信息。

项目文档的质量如何提高？

更科学地利用github管理文档：建立另一个专门的分支、按照文档的类别分类组织；文档的格式更加规范：按照统一的规格撰写，并采用更易懂的词句。

对于人的领导和管理，有什么具体可以改进的地方？

PM与小组的联系可以改进，比如指派小组长与PM定时联系、向PM汇报工作进展，PM向小组长指定任务、小组长细分任务并在组内分工；或者PM联系所有小组成员（成员数目也不是很多），直接将任务细分到个人，所有成员定时与PM联系、汇报工作进展、获取指定任务。

对于软件工程的理论，规律有什么心得体会或不同意见？

一定要善于沟通。软件工程不只是与机器打交道，有时候更多地是与人打交道。我们计算机专业的学生有很多不善言辞，不能清晰地阐述自己的想法、表明自己的观点，独立开发的水平很高，与人交流的水平不足。编程和交流都是艺术，而业内大牛往往两种艺术造诣都很高。

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

在团队开发的初期，我们按照前后端两大板块进行人员工作划分，三名同学进行前端开发工作，三名同学进行后端开发工作。在完成一定进度后，大家讨论发现在微信小程序开发上，前后端的工作与其他软件开发有一定不同，后端的任务相对来说较为简化。因此，我们决定重新分组，两两组队分为三组，每一组负责不同的页面版块，这样提高了开发效率。在团队的分工上，由PM制定总的计划方针，给每一小组制定相应的任务，之后在小组内部组员自己协商讨论完成进度，最后各组的工作汇总对接。

在分工协作上，除了要根据不同成员的能力来分配任务，还要考虑实际开发中的细枝末节，遇到困难和不足要及时提出，共同商讨策略。

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

有

姓名(博客园)	感谢信
黄JH	感谢黄继辉同学为团队辛勤付出，开发之外还要肝博客、开例会，作为PM有能力、有担当、有胆识；感谢hjh同学，他组织了许多工作的进行，并且时时提醒了我的工作，让我们的项目能够顺利、及时地进展。
姚BW	感谢姚博文同学作为小组搭档不抛弃不放弃，合作愉快; 感谢第三组的gzh和ybw同学。后期他们负责ui部分，对我所负责部分进行了适当的修改。gzh同学同时帮我测试了许多bug，我得以继续完善负责部分的功能，减少bug。
潘Y斌	感谢潘永彬同学帮我改前端，为我解答云开发问题；感谢第二组的pyb和zl同学。在我和第二组对接的时候，他们组织了上传页面和编辑跳入功能，为我们的成功对接提供了基础。
张L	感谢张擂同学提供云函数接口，为我解答云开发问题；感谢第二组的pyb和zl同学。在我和第二组对接的时候，他们组织了上传页面和编辑跳入功能，为我们的成功对接提供了基础。
刘QX	感谢庆新，作为一个小组的搭档，我们配合的很融洽，你也帮助了我很多。感谢刘庆新同学担起核心任务，图片编辑功能做的十分高端，属实企业级；
郭ZH	感谢豪哥，我知道你其实在搜索算法和UI优化上做了很多繁琐的工作，但是你每次都很优雅的完成了这些工作。感谢第三组的gzh和ybw同学。后期他们负责ui部分，对我所负责部分进行了适当的修改。gzh同学同时帮我测试了许多bug，我得以继续完善负责部分的功能，减少bug。

讨论截图

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

我认为我们的团队目前处于第二级，在当前的项目开发过程中，我们的团队可以按照基本的规程来进行开发，管理工作也负责到位，每一个项目的细节可以具体到个人来负责。

你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

我认为我们团队当前处于规范阶段。组员之间在例会上会相互讨论项目开发成果，项目经理可以合理地安排任务给不同的组员，大家也很积极地去完成任务；在项目的开发过程中，除了组内成员的相互配合，组与组之间也会在一些问题对接上相互讨论达成一定的见解，成员之间相互支持工作、理解。总的来说，团队目前都会为了共同的目标而共同努力，相互之间的氛围也较融洽。

你觉得团队在这个里程碑相比前一个里程碑有什么改进?

由于团队是第一次进行软件工程的开发，组内的成员大多也不熟悉，所有相对来说大家在相处过程中会有所局限。但是在项目的完成过程中，组员们都很负责地去完成分配给自己的任务，彼此在相互合作之中也有较多交流，增加默契。

你觉得目前最需要改进的一个方面是什么?

我们在小程序初次开发时，对于小程序开发的整体框架结构不太熟悉，导致在开发过程中有一些基本的设计没有到位，其次是在代码规范上还需要继续改进。