赤兔程序员——alpha阶段问题总结随笔

[赤兔程序员]

这个作业属于哪个课程	软件工程-23 年春季学期软件工程
这个作业要求在哪里	团队作业—bate 冲刺+事后诸葛亮
这个作业的目标	Alpha 阶段问题总结
其他参考文献	现代软件工程讲义 11 项目管理 - 事后诸葛亮会议

目录

目录

• 目录
• 一、设想和目标
• 二、计划
• 三、变更管理
• 四、团队的角色、管理、合作
• 五、设计/实现
• 六、测试/发布

一、设想和目标

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

喵普喵谱致力于为福大猫协提供一个可以集中查看管理福大校园内流浪猫的信息、对于猫协信息集中发布管理的小程序。

• 对于猫协，我们需要解决猫协需求将福大流浪猫可以便利地为人知晓且方便管理地问题，以及猫协需求便利地将内部财务公示、发布救助任务及公告，及其管理等问题。
• 对于用户，我们需要解决用户对于“云养猫”的需求，需要提供一个猫协对福大学子及共同有爱猫之心的用户的一个统一的信息发布的平台。

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

• 原计划功能除了论坛部分全部完成，由于国家对于相关平台的资质的审查力度，我们被迫删减了用户论坛部分，减少了猫协对于用户消息的统一管理，用户对于信息的传播，改为一个单纯的消息发布平台
• alpha版本 按照原计划交付时间交付
• 原计划达到的用户数量能够达到

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

• 和上一个阶段相比，团队软件工程的质量提高了;

• 在分工合作方面以及项目管理方面，提高了10%；

• 后端部分提前完成，前端部分及时完成，整体氛围兴兴向荣。

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

基本一致。我们对于用户需求尽心尽力、尽善尽美地实现，用户对于小程序的美观还有一定需求，这一点，我们会在beta版本继续加强，争取给用户带来更棒的体验，为猫协提供更好的产品。总的来说，我们离目标是越来越近的，我们赤兔程序员一直在前行，一直致力于为用户提供更好的更棒的体验。

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

1.如果能够重来的话，我们会选择一开始就放弃设计给用户发言、发文章、评论的功能，由于不可抗力的削减，导致团队工作白费，给用户带来了一句 “白话” ，我们完全可以将这些时间用来设计一些用户需求的其它一些功能，或者美化界面。

2.如果能够重来的话，我们应该在人员分工上再多下些功夫，更加合理的分配工作量。

二、计划

1. 是否有充足的时间来做计划?

经过上轮的实战训练，我们意识到提前做计划的重要性，有放出一定的时间来进行计划与设计，但是由于人员比较多，不好进行管理，大家的课程时间冲突，项目管理经验有限等原因，项目还是进行的比较仓促。

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

团队对于计划基本上在会议中都会进行讨论，在会议上大家各抒己见，思维碰撞，经常会碰撞出更加美丽的火花，大家的意见建议都是宝贵而珍贵的，我们会在会议上讨论合理性和实用性，在组员的大致讨论以及最后将由组长进行总结以及盖棺定论。

我们认为这是效率比较高的做法，而且也有利于接受组员的意见，集齐全组的智慧。

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

计划内容全部完成，不过项目界面有待优化，一个更加美观的界面，一定会是吸引用户、增加用户粘性的利器。

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

暂时没发现。

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

大体上是有的，但是细节上还不够清晰，前后端交流也不够多和详细，所以导致前后端对接问题比较多。

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

• 项目最大的意外来自于微信公众平台的背刺，平台对于言论的把控是比较严格的，导致我们不得不删减用户发言的部分功能；
• 原因：由于项目开展前对于微信小程序开发不够了解，不知道发布的小程序涉及到用户自由发布言论，必须要有严格的资质审核，需要有企业级的资质。而且我们的产品必须发布，因为是为猫协作的产品，便绕不开审核，只得放弃。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

是有留下缓冲区的。在组长的催促下，五一期间，并没有完全荒废，进行了一定的加班，最后留下的缓冲区起到了一定的作用，我们最后在缓冲区内完美解决了组员们课程时间冲突的问题。

8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）

继续预留缓冲区；继续加班，狠狠地加班！！！为社会主义建设贡献出你们的力量啊 >_<

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

学到了很多，如计划的重要性、分工和预留缓冲区的重要性等。

我们会继续预留缓冲区，更加合理的分工......

三、变更管理

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

我们的组员能够及时的知道变更的消息，我们会及时地通知变更消息，及时回复；未回复的会通过私信、电话或者当面联系，务必确保了每个人都能收到通知。

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

我们会进行线下的会议讨论，根据用户的需求，共同讨论功能的优先级，最后由组长盖棺定论。

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

能够完成预先的功能设计、符合原型设计

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

能；我们对于变更一般采取，小事通知后自己解决；大事讨论后，定下解决方案后再具体解决。

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

合理安排项目开发进度，即使处理逻辑不畅和错误之处，以免对接下来的开发造成障碍。

合理应对需求，需求并不一定都能实现，必要时还要进行修改。

四、团队的角色、管理、合作

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

首先是根据每个成员所擅长的领域不同以及个人意愿来分配角色的；

其次是根据任务具体数量来合理分配，算是人尽其才了。

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

• 有的，因为有代码规范，所以成员间编写的时候也会互相讨论要怎么编写好，遇到不会的也会互相帮忙解决。
• 在遇到关于需求的具体实现时，大家也会为了更好的符合需求，追求合理性、体验性来经行合作讨论。
• 在使用不熟悉的技术时，也会由熟练的组员来帮助。

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

一般组员间互相讨论就能讨论出结果，实在无法讨论决定的话，由组长盖棺定论。

五、设计/实现

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

• 在alpha阶段开始之前，由团队所有成员共同设计。
• 由于需求分析、系统设计与概要设计都有一周时间，时间相对充裕，所以是在合适的时间。
• 设计工作，由所有组员讨论后决定，是合适的人。

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

有的，大家就需求进行讨论，我们追求满足用户的需求，合理性以及实用性。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 使用了Axure进行原型设计；
• startUML来绘制系统分析图、数据库关系图；
• Xmind来绘制需求图等等；
• 这些工具都很有作用，帮助我们更加清晰明确地进行设计。

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

在编写时前后端均发现了一定的错误，并修改了。在发布之后就没有发现重要的bug了。

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

由各方向的开发人员自行审查，以及交叉审查；

因为前期就规定了代码规范，所以编写的时候也是根据代码规范编写的。

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

我们学到了很多关于项目开展的重要经验；

再来一次，我们会对测试、审查等非代码编写阶段再多下些功夫。

六、测试/发布

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

有测试计划。不过总体测试效果一般，组员大多进行了单元测试、系统测试，测试密度可能不够，并没有发现特别重大的问题。

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

是的，前端是功能逻辑的测试，后端主要是对于接口和模块的测试。

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

postman、junit以及robotframework等工具

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

由于开发时间比较紧迫，这一点几乎没有考虑到，在后续阶段中会考虑加入。

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

目前还没有发现太大问题，小问题是图片上传会有一定概率出现问题，后续会进行改进。

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

• 学到了非常多，由于我们是第一次开展项目的开发活动，总体来说，收获是非常多的，经验也收获了不少。
• 再来一次，我们会加强非代码开发部分的权重，争取开发出一个更加完善的项目。