秃顶顶少年团—事后诸葛亮
| 软件工程 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1 |
|---|---|
| 作业要求 | https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10863 |
| 团队名称 | 秃顶顶少年团 |
| 作业目标 | 组织事后诸葛亮会议并发布随笔 |
| 作业正文 | https://www.cnblogs.com/Tudingdingshaoniantuan/p/13253724.html |
| 参考文献 | 百度,知乎，csdn，项目管理之事后诸葛亮会议 |
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：我们的软件主要是一个可以定位(附近）的商城系统，里面售卖各种日常生活所要用到的商品，可以搜索附近商家售卖的商品还可以给自己定位。对社区用户和定位有比较清晰的描述。
-
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
答：我们目前还只达到目标的五分之二。前端页面大部分实现，但是由于后端代码(卖家)出现一些问题，这导致很大一部分功能没有实现比如说查询店家，购买支付等。所以用户数也没有达到。
-
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
答：和上一个阶段相比，我觉得我们还是有很大的进步的。在做项目的过程中我们之间的合作越来越默契，从一开始自己干自己的到后来的互相帮助，常常沟通交流让我感受到了一个团队的力量。
-
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：因为我们的项目目前还未研发成功，所以跟我们预想的不太一致。从一开始而言，进步是无疑的，所以我们肯定是离目标越来越近。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
所得到的经验就是当一个人摸索不出答案时，要勇于询问，因为团队的力量要比一个人的力量大的多。如果重来一遍，我们会先分析好所有需求，准确快速的查询搜索资料，咨询老师，同学们，早些把项目做出来，一定每天都迁入github代码绝对不会忘记！
计划
-
是否有充足的时间来做计划?
答：计划阶段一开始没花上太多时间，所以在项目后期功能模块方面除了跟多问题，这也是我们团队考虑不周的问题.
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：大家一起投票，然后选择做什么，之后大部分意见不同的时候都采取投票的方式，力争解决问题.
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：原计划的工作只做了一半吧，目前功能方面也就实现了登录注册，一是对于PHP开发小程序语言的欠缺，二是学校放假时间安排得过早，每个课程都忙着课程设计，答辩，时间来不及.
-
有没有发现你做了一些事后看来没必要或没多大价值的事?
答：在数据库的选择反面做了很多没有意义的表，配置MYSQL数据库和实现程序与数据库的连接花了大量的时间，后面发现微信开发平台有提供数据库的功能.
-
是否每一项任务都有清楚定义和衡量的交付件?
答：不是每一个任务都有很清楚的定义，我们是先阐述功能，再分功能和模块去实现，实现之后再规范整体风格.
-
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
答：整体上是按照计划进行的，中途确实也出了很多小意外，对PHP的不熟悉，数据库选择方面纠结了很久，接口的选择问题也一直在讨论.
-
在计划中有没有留下缓冲区，缓冲区有作用么?
答：有留缓冲区，而且缓冲区内设置组长和副组长起到了很好的简单作用，及时有效的完成了各种分配下来的任务
-
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：将来的计划是争取把所以的该实现的功能 全部实现，争取在下半学年开学前完成.
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
学到了一个道理：一个人的力量是有限的，一个好的项目需要大家齐心协力，精诚合作才能完成。虽然我们项目最后的结果不尽人意，如果历史能够重来，我们会在数据库的选择方面还有代码编辑语言方面进行选择，
这样能更有效率完成我们剩下该完成的模块，同时也谢谢大家一直以来的同心协力.
资源
-
我们有有足够的资源来完成各项任务么？
答： 有，与其他团队相比，我们团队10个人里面，具有个人编写程序能力的成员只有三个，我们团队中大部分的成员编程能力不强，所擅长的的技术也不尽相同，所以导致我们团队大部分项目开发都需要团队的集体协作.
-
各项任务所需的时间和其他资源是如何估计的，精度如何？
答： 按照任务的复杂度、自身能力来评估；精度模糊，只能估计大概时间。各项任务所需的时间一般是按照任务的难易进行时间估计按期的，分配到个人，会看他的个人综合处理任务的能力来进行合理分配，比如 UI界面设计比较简单，分配的时间也就相对较短，小程序各个功能模块的实现和整合的时间花费较长，就需要多给于测试人员和代码编写人员相对多的时间，精度准确到小时为单位.
-
测试的时间，人力和软件/硬件资源是否足够》对于那些不需要编辑的资源（美工设计/文案）是否低估难度？
答：测试的时间基本是不够的，因为临近考试，大部分的课程都需要做课程设计，还忙着复习，加上各个功能模块实现的功能不一样，需要调用接口，选择好的接口也占用了一定量的时间，加之代码方面是用的PHP，这个是是我们按照B站上面一个教学视频，边做项目的同时，边学习一些基本的编程，然后学以致用，所以花了很多时间，美工设计和文案放给几个编程能力相对较弱的成员，大家合理分工，力所能及.
-
你有没有感到你做的事情可以让别人来做（更有效率）？
答：有，由于每个人擅长的方面不同，所以应该各显神通，最终完成一个好的项目，确定开始画用例图和进行用例描述的时候确实人手不够，自己也得简单某些用例存在的必要和每个用例之间的关系，所以有的事确实别人可以代替，所谓当局者迷旁观者清,自己也有遇到死胡同的时候，后面也是问了别的项目组的成员，后面解决了.
有什么 经验教训？如果历史重来一遍，我们会做什么改进？
基础不牢的条件下做什么事情都很困难;首先把基础打牢，再把任务完成之后一步步优化。最后的结果不尽人意，如果历史能够重来，我们会在数据库的选择方面还有代码编辑语言方面进行选择，
这样能更有效率完成我们剩下该完成的模块，同时也谢谢大家一直以来的同心协力.
变更管理
-
每个相关的员工都及时知道了变更的消息?
答：我们组在项目开始的初期就建好了工作交流群，包括QQ群和微信群，对于变更的消息会通知到每个人，所以团队成员都能及时了解。
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：我们组通过“人物角色”的建立，来决定“推迟”和“必须实现”的功能。使得我们组的开发人员能够更专注于产品的用户群。
满足首要人物全部要求，满足次要人物部分需求。 -
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：我们的需求规格说明书里有明确的验收标准，可以根据验收标准来查看项目的出口条件。
-
对于可能的变更是否能制定应急计划?
答：没有制定应急计划，对于可能的变更会通知专门负责这部分的成员及时跟进，采取相应措施。
-
员工是否能够有效地处理意料之外的工作请求？
答：团队成员都很团结，能够有效地处理意料之外的工作请求，除了因某些特殊情况暂时不能参与，其他都能配合要求。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们在做项目的时候要有随机应变的能力，学会解决突发的情况， 如果历史重来一遍, 我们要对细节更加注意，制定详细合理的应急计划，另外也要拥有顽强的心态。
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
答：我们每次的设计工作（编码前的所有阶段）都是通过组长先定初始人选，然后组员内部讨论最终决定的，每次任务的人员分工都在每个阶段的博客中详细体现，也能够较好的完成工作
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：遇到此种情况时我们都是通过投票表决少数服从多数解决的
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
答：单元测试：十分有效，能很直观表现出开发最终成果是否正确，并且定义起来也比较方便
UML部分：由于在开发过程中有一些比较难实现的，或者有冲突的功能模块部分，所以需求时不断在变化的，我们的UML文档相比最初也有一定的变化，但并没有非常多
- 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：发布后我们发现小组功能模块有部分功能是没有成功执行数据交互的，在开发时由于并没有很好的预留时间导致没能很好的为隐藏的问题提前预留出解决的方案
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：代码复审是由前后端两个部分分别制定一个负责人进行复审的，代码规范部分基本上就是结合各自模块开发人员的习惯编写的，所以执行的比较好
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计与实现都是开发过程中十分重要的环节，要整个小组一起不断学习，共同探讨存在问题才能更好的完成任务，对于一些不合理的设计，如果重来一遍我们会在冲刺过程中留出一定的时间进行重新讨论与设计
测试/发布
-
团队是否有一个测试计划？为什么没有？
答：有， 我们小组前后端分离开发，所以测试计划是肯定不可少的，通过自下而上的最基本测试方法进行软件开发过程中的所有必要测试
-
是否进行了正式的验收测试？
答：是的，由于时间的原因，我们的验收测试只是进行了项目整体的简单使用，并且体感评判测试等级
-
团队是否有测试工具来帮助测试？
答：我们通过安卓手机登录微信小程序进行黑盒测试，全部采用的手工测试，目前自动化测试还不会没办法进行测试计划改进
-
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：软件没有正式发布，还有很多缺陷没有完善，所以没考虑到性能问题，以及运行环境问题，所以没有进行性能测试以及压力测试。如果从运行结果来看
测试还是很有用的，找到了许多软件缺陷，帮助团队进行了软件优化。改进的话，手动效率低下，以后学会了自动化测试就利用自动化测试和测试工具
来进行测试，提高测试效率，其次感觉测试覆盖面略低，单元测试应该做到100%覆盖，但是基于个人能力问题并没有做到该指标。 -
在发布的过程中发现了哪些意外问题？
答：在发布过程中，软件并没有彻底完成，许多功能没有实现，在部署服务器的过程中由于每个人本地配置不一，照着统一教程进行配置服务器却没办法正确完成，
换了几个人进行才最终能够配置本地服务器，云服务器不了了之。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
学到了软件的制作不是一个简单的过程，需要多人协助配合，一旦其中一个环节出现了问题很容易影响到其他工序。测试部分是软件开发必不可少的一环，并且测试并不是出现问题就一定是坏事
如果重来，我们应该会给测试环节多1-2天的时间，对整个项目需要测试的地方再次进行评估并且进行相应的测试，如果从来一遍，我们会先制定严格的
人物分工，以及工作时间，每天的工作量必须完成，不耽误后续工作，这次软件的制作失败，主要原因酒水出现在这里，分工配合的失败，在规定时间内没有
完成相应的内容制作，当然冲刺时间于期末考试复习时间重叠也是没有完成任务的一个影响因素。
团队的角色，管理，合作
- 团队的每个角色是如何确定的，是不是人尽其才？
答： 根据大家讨论的结果，每个人负责擅长的角色。
- 团队成员之间有互相帮助么？
答：是的，出现问题时，大家会一起讨论解决。
- 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
答：当出现项目管理、合作方面的问题时，团队成员会进行协商，讨论出解决方案。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了团队合作的益处，当有问题或者出现矛盾时，大家会一起解决，方便快速。如果历史重来一遍, 我们会更加相信自己的队友，一起进步，团结和谐。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
陈萍杰：我感谢邹雪花对我的帮助，每次我任务做不完，他都会来替我承担一部分任务，我感谢雷情对我的帮助，每次我分工不明确，没及时组织任务，他都会来帮我分配任务，
唐清磊：我感谢陈萍杰和雷情给我的帮助。因为在UI界面设计中，一开始什么都不懂，他们教了我很多，其他例如前段的编写，框架的选择设计也是一直在帮助我。
严雄峰：首先我要感谢我的组员这段时间的陪伴， 比较之前的团队项目，这次的冲刺更为正式也更让人紧张，无论是代码上还是文档的编写上都较之前上升了一个台阶。因为微信小程序是自学没多久，所以熟练度基本是没有的。而且由于自己个人的时间安排问题，
遇到的问题比较的多，期间在笔记模块上后端陈萍杰帮助良多十分感谢！此外我还要感谢雷倩，她不仅要完成自己的任务外还热情的帮助其他组员。协助组长萍杰共同管理组员之间的任务，在后期组员分工上衔接的很顺利，为项目尽早提交提供了很大的帮助。
陈柱全：我感谢雷情督促我们完成工作，在工作上完成度不够的时候，会帮忙指出来，ui界面设计的时候还会帮你修改
邹雪花：在项目进行过程中，遇到了很多的问题，自己百度还是没能解决，在崩溃到想放弃的时候，是老师和队友的帮助，让我克服了一系列问题。
感谢老师，感谢队友对我的帮助，自己在项目过程中有提升自己处理问题能力以及抗压能力，并且学会了项目开发的过程和方法
雷情：我感谢秃顶顶少年团员的每一位组员，还有老师对我们的帮助，团队的人在我很忙的时候会替我分担，老师在我们项目进行中也给了很多建议，会悉心为我们答疑解忧。
刘敏：我感谢雷情对我的帮助，老师说用例图的那节课我什么都没听懂，以至于分配任务时什么都不会做，雷情浪费自己的休息时间认真给我讲解每个细节，
一步一步教我画。不止这，还有很多次当我遇到困难或者感觉到迷茫时，她总是给我帮助和鼓励。所以我非常感谢雷情对我的帮助(=^▽^=)
邹婷：我感谢秃顶顶少年团每个成员，因为一开始如果不是你们的接受，我也许就不会成为秃顶顶少年团的一员，感谢你们对我工作的包容与支持。
郭航：我感谢陈柱全对我的帮助，因为某个具体的事情:项目测试时对我的指导。
胡楠：感谢陈萍杰在我不是很懂微信开发工具的时候的耐心讲解，及相关开发文档的解释提供的帮助，也感谢各位组员的团结协作。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：CMMI二级，管理级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：从磨合到规范
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：任务分配，技术能力上都得到了较大的提高
你觉得目前最需要改进的一个方面是什么?
答：技术得到提升
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
答：时时总结如何提高团队效率并付诸行动。（在每次作业之后都会进行反思）
简明为本——它是极力简化不必要的工作量的技艺。（我们只实现了必须的功能）
无论团队内外，面对面的交流始终是最有效的沟通方式。（几乎每次开会都会QQ电话或者做一起写作业）
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
答：拥有一个比较适合自己的源代码管理工具，例如GitHub,当项目有进展就进行嵌入。在编写代码时就注意代码规范，如果到后期再进行代码规范加大工作量。代码进行复审，密切注意项目交互情况。 -
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
答：重构使用微服务架构，解耦系统，分成多个服务，降低系统的耦合度，提高系统的容量； -
其它软件工具的应用，应该如何提高？
答：多使用idea、eclipse、等工具进行编码，多查阅工具的使用教程。 -
项目管理有哪些具体的提高？
答：任务量化，细化，具体到可以立刻实现；需要有验收和整合的步骤；分工上、工作量预估上。 -
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
答：还未上线，暂时没有这个考量；可以实现对应的接口和管理界面来呈现每日/周活跃用户等数据； -
项目文档的质量如何提高？
答：
a.规范表达，使用专业词汇，减少口语化。
b.有效的记录、指导、督促，将文档编写好。 -
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
答：
a.重视团队成员，多开展团建交流，营造良好的团队气氛；
b.一定要把各个任务可以量化到，大家才能很好的完成，这点在项目工作中，真的是必须的。 -
对于软件工程的理论，规律有什么心得体会或不同意见？
答：学习理论知识要应用于实际，理论实际要结合起来，将项目运行。
占比
| 序号 | 组员 | 工作量比例 |
|---|---|---|
| 1 | 邹婷 | 9.1% |
| 2 | 雷情 | 12% |
| 3 | 邹雪花 | 9.5% |
| 4 | 刘敏 | 9.3% |
| 5 | 严雄峰 | 9.3% |
| 6 | 唐清磊 | 9.1% |
| 7 | 郭航 | 9.1% |
| 8 | 胡楠 | 10.5% |
| 9 | 陈萍杰 | 13% |
| 10 | 陈柱全 | 9.1% |
照片
