Alpha 过后诸葛亮

Part 1 前言

组长连接

做业连接

Part 2 总结思考

- 设想和目标

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

解决微信端上的轻便办公，方便微信端上的办公群体，例如共享编辑针对须要反复审阅修改的办公情形，以及其余环境下面向组内的通知、投票等一系列办公需求。

1. 咱们达到目标了么（原计划的功能作到了几个？

原计划的功能中基本完成投票功能、对象分组，接近完成共享编辑功能，半完成通知、想法功能，未完成签到功能。

1. 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
   用户量, 用户对重要功能的接受程度和咱们事先的预想一致么?咱们离目标更近了么?

距离目标咱们还有必定的差距，此次的alpha未可以达到咱们原定的计划，如上述所表述的，进度并非使人满意，目前所完成的效果也与前期设定的原型不管是风格上仍是功能上相左，须要完善的地方有许多。

1. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：前踩工做须要作好，了解总体项目所须要的技术、软硬件支持，才能是后续的项目进度有条不紊。

- 计划

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

由于种种缘由(考试、党课、我的等等)，每次计划的都不是很完美，也没有很及时的时间去补正，后续会注意。

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

经过了激烈的讨论，获得一个可行的方案并往这方面走。

1. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?

杨礼亮：美工工做完成，辅助翔宇的工做还未完成，由于效率不高，能力不够

丁水源：通知后端的工做完成，可是完成的速度比较慢

柯奇豪：共享编辑后期遇到许多以前没有估计到的修改，例如存储形式、功能增长等，因此致使没有及时的作好，只完成了简单的列表显示功能。

黄毓明：投票、分组功能完成。

黄志铭：原来计划在12月份前把全部的前端界面作完，并和后端一块儿完成交互，而后好好准备期末考。过程一直都觉得先后端交互应该就是一两天的时间………结果出来当面交互的时候，就发现了问题好多呀……根本不是一两天能够完成的。

蒋熊：没有都作完，待得不断开发，所发现的问题也愈来愈多，原型UI设计不完整，页面需求随着开发的深刻不断上涨 有不少原型设计里没有的页面须要新增。一开始定的实现逻辑随着开发的深刻也发现后端一些算法是没法完成的，所以前端页面须要跟进后端算法作出调整。再而对js不熟悉，与后端对接上来不及作完，且页面过来，也来不及对接，工做量太大。

林翔宇：没有。临近考试，再加上转专业课也不少，时间难以平衡。

1. 有没有发现你作了一些过后看来不必或没多大价值的事?

柯奇豪：有，花了大把的时间在ssm框架上，结果不太会用，转用springboot+mybatis，但庆幸是能用了。

丁水源：过程当中学到的东西都挺有价值的，时间花的挺值得

杨礼亮：学了不少可是都遗忘了

黄毓明：一开始写的投票没能融入框架，只能使用里面的部分函数，大部分未使用

黄志铭：确实作了不少好像根本就没有帮助的事，好比自动跳转图片的界面风格以及代码以前几乎都是本身写，彻底能够和网上照着改一下，再完善，延长了进度

蒋熊：以为比较没有必要的事情就是开发前期过多的投入于逻辑设计和各自分工，浪费了不少时间你们各作各的，到最后一对接才发现对不上。

林翔宇：学些java基本语法花了不少时间，才开始写要作的小程序。其实彻底能够边学习语法边写的。

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

全部人：很遗憾，没有，许多东西都是在后续工做中不断发现须要修修补补的地方，许多地方没考虑到。对于你们每一个人任务的总和要达到什么结果很模糊。

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

全部人：项目初期是在按预期走，可是中后期已经偏离轨道了，出现的大问题有几个，一个是研发小组队员退出，不是简单的n-1问题，再一个就是先后端对接。直到如今，后端仍有三个项目未开发成功，先后端能算比较完整对接的只有投票一块。我以为出现这样的问题主要是你们沟通交流不够吧，否则也不会再最后一周才想起来要出来一块儿作。没有有效的资源共享，致使每一个人进度不一。

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

全部人：有过留取一段时间进行先后交互，是为了防止先后端交互后出现重大bug，或是界面逻辑有问题等，可是每一个人并无在这段时间前很好的将本身的任务及时完成，致使后续进展不顺，因此后来的缓冲区做用不大。

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

柯奇豪：留出一段时间出来进行一个项目的整合，目前在过渡期内，我计划分红两部分人群分别负责部分功能的先后端一块儿完善，最后在缓冲区的时间段内总体的一个汇总，每两天找个固定的时间段来一块儿编程。

黄志铭：接下去计划在一周以内，尽可能能与分小组同窗一块儿出来当面作一下，完善一下项目，在作前端界面的同时，也了解一下后端的具体操做，更好地实现交互。

蒋熊：其余小组项目都差很少完成了，接下来咱们也得加快了，明白了问题所在，就不应再继续下去了，加班生活正式开始。

林翔宇：分配时间的时候必定要考虑仔细，不要再由于时间分配不合理，致使计划没法完成。

1. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：学到的就是须要在项目开展以前即搜集足够多的资料来对总体的项目各部分有一个明确的方向，这样在后续的进度中就不会由于卡壳而不停的调整，初步了解各部分细分下来所须要的技术支持。

黄志铭：这个能够早点出来当面作一下，讨论一下具体的分工以及项目愿景，让你们更熟悉本身对应的部分，提升团队总体效率。

蒋熊：若是可以重来，第一周咱们就会抱着这样的态度，二话不说，直接加班，撸袖子就是干。

林翔宇：作计划的时候必定要合理，时间很紧凑的时候要尽可能提升效率。

- 资源

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

时间资源不足，基础能力储备不足。

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

原先是按照每次博客的提交时间为周期进行编程，后续可能会更加细化，由于还有许多工做须要完善。

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

柯奇豪：测试阶段基本上部署服务器，暂时还在前期筹措阶段，待后续反馈。

1. 你有没有感到你作的事情可让别人来作（更有效率）?

柯奇豪：在项目的规划上以及对任务的布置上本身仍是有缺失的，我的不怎么善于言辞，因此在过程当中表述上经常没办法解释清楚，致使组员出现一头雾水的状况，在语言沟通上可能存在障碍。若是换一个表述更清晰一点的人或许在前期能够解决目标不明确的问题。

蒋熊：我以为换一我的作个人事情不必定会更有效率。我以为其余人也同样，每一个人都适合本身的工做，问题始终不在我的上，而是团队上。

林翔宇：咱们组人比较少，你们任务都很重，因此本身的部分仍是本身努力作好吧。

1. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?

技术资源共享不够，若是重来或许能够借鉴其余组的思路，编程过程里也整理问题及解决办法，整合一份技术指南来便于小组开发。要注意队内的沟通交流，必定要留好十分足够的缓冲时间。

- 变动管理

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

会有消息延迟的状况，部分时候会耽误进度，后续可能采用固定时间段来集体完成并汇总提交。

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

按照博客提交的进度进行，可是发现不能很好的既定目标相符，须要调整一个合理的办法，可能会增长组内的进度deadline。

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

暂时没有考虑到这个问题，后续以真机测试为准。

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

目前没有

1. 员工是否可以有效地处理意料以外的工做请求？

基于每一个人的水平，部分红员没办法作到

1. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：deadline与验收标准的肯定须要完善，缺乏压力的团队每每就会致使项目的短时间搁浅，本身也须要学会对队员有更高的要求与督促。

黄毓明：学到了不少东西，Java的springboot+mybatis框架使用，微信小程序前端开发，以及一些web服务的相关，若是能够重来的话，不该将时间都浪费在一个框架上，提早作好任务分配也许会更好

丁水源：若是历史重来一次，我将会尽早的作规划，尽可能早地完成任务。

蒋熊：若是历史重来，必定会先集中力量开发核心功能 先完成项目主模块。

林翔宇：当进度跟不上原先计划时，要赶忙调整，反思缘由。

- 设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？

在项目的初期由组内共同讨论完成，是的。

1. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？

原先在部分的功能上有歧义，基本经过各自表述本身的见解而后你们共同决定经过。

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

主要使用processon、leangoo来对项目细则有必定的说明。

1. 比较项目开始的 UML 文档和如今的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

存在比较大的差别，是原先组内没考虑到的，主要缘由在于项目开发经验不足，没有细化到许多具体的地方，后续有时间会对以前的UML文档进行修正。

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

框架的使用上遇到较多的bug，由于原先并无考虑到会用框架，也是第一次尝试使用。

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

暂时没有代码的复审，后续作完会对代码的命名规范、注释、项目具体的布局作必定的修改。

1. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：规划上虽然没办法一开始就作到尽善尽美，但在后续的进程中，仍是须要安排适当足够的时间去作好这块内容

- 测试/发布

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

暂时没有，由于基础性的开发并无及时完成，可是在后续会有一个测试版本阶段。

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

目前尚未

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

没有具体的规划，后续会去请教一下其余组给出方案。

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

暂未进行，设定的目标是想在周围人群中进行一次推广调查，而后收集意见酌情修改完善。

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

产品暂未发布，还未遇到问题。

1. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：有一个合理够用的测试能够简化项目后续的工做，减小bug的出现，尽量考虑状况解决缺漏

- 团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？

按本身的意愿进行职能的分配，基本上算是人尽其才，但仍是存在部分红员存在空窗期的状况，例如在原型设计阶段部分先后端不知所措，以及后续先后开发过程当中美工人员的不知所措等。

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

柯奇豪：团队成员在了解框架、具体编程等的过程当中，基本上都是采起互帮互助的形式进行学习，相互指教的。

丁水源：有相互帮助，好比我就会去请教同伴黄毓明不懂的问题。

1. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？
   每一个成员明确公开地表示对成员帮助的感谢 （而且写在各自的博客里）：

柯奇豪：在此感谢一下 ++毓明++ ， 由于 ++本身自己不太善于言辞，仅仅只是本身会使用、编程，但常常给其余人解释不清，毓明则能很好的帮我与其他的人沟通，指导他们框架搭建，这是我未能作到的++。

黄毓明：在alpha版本中交流较少，基本上都是各作各的，出现问题也基本上是本身埋着头解决

丁水源：我感谢黄毓明对个人帮助，由于当我在理解Spring Boot框架时遇到一些问题，询问他，他能十分耐心地给我讲解。

蒋熊：我感谢全组的人对个人帮助，由于某个具体的事情：其实不管是前期工做分配的不合理，仍是你们后来学习程度不够，问题已经发生了 如今你们都愿意投身其中，咱们之间互帮互助，其实就很值得感恩。

林翔宇：我感谢黄毓明对个人帮助， 由于某个具体的事情: 耐心的帮我配置好开发环境，并教我怎么使用spring boot框架。

1. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?

柯奇豪：一个团队最不能缺乏的，就是团结一致为共同目标而共同奉献自个人决心，少一点借口，多作一点实事才是。带领队员一同进步的工做并无想象中的简单，须要负责的地方有太多太多，对pm的责任多了一份敬重。还有就是努力改善本身的表述方式吧。若是重来，以上都是我会改进的地方。

黄毓明：硬要说学到了什么，只能说独立解决问题的能力变强了吧。若是历史重来，或许更多的交流会是比埋头苦干更好的选择

丁水源：若是历史重来一遍，我会提早学习好项目所需的框架，以及更早地学习java语言，更早的了解一个产品的研发过程。

蒋熊：若是历史重来，学会感恩吧，每一个人都不推卸责任，互帮互助。

林翔宇：在团队合做中，只有你们都尽责，才能一块儿完成好任务。单靠一两我的是不够的

- 总结:

1. 你以为团队目前的状态属于 CMM/CMMI 中的哪一个档次?

柯奇豪：我以为目前团队还处于可重复级阶段。

蒋熊：我以为目前团队处于可重复级向已定义级过渡的阶段吧

1. 你以为团队目前处于 萌芽/磨合/规范/创造 阶段的哪个阶段?

柯奇豪：我以为团队暂时处于磨合阶段，信息与进度的不一样步是目前遇到的最大问题。

丁水源：我以为团队目前处于“规范”的阶段。

蒋熊：应该是磨合阶段，原先比较松散，直至这一次问题出现，促进了咱们的磨合

1. 你以为团队在这个里程碑相比前一个里程碑有什么改进?

柯奇豪：更加的了解了软解开发流程，逐渐提升了编程能力，学习的语言与技能都有很大程度的提高，整个团队的合做观念渐长。

黄毓明：任务分工更加明确，目标更清晰，协做能力正在增强

丁水源：我以为团队相比于前一个里程碑而言，队友们更加团结，更加明确了项目的方向，更有项目经验了。

蒋熊：改进就是学会去发现问题和解决问题了，而不是顺其天然

林翔宇：你们都比较熟悉了，沟通起来也愈来愈顺畅

1. 你以为目前最须要改进的一个方面是什么?

柯奇豪：目前最须要改进的方面就是组内的责任意识，也但愿后续你们可以共同努力，齐心合力共同开发出能让咱们本身满意的小程序来。

黄毓明：代码规范

丁水源：我以为团队目前最须要改进的地方时“deadline拖延症”，不要把全部事情都拖到后期才完成。

蒋熊：最须要改进的就是分工合做，在原来的基础上从新分工，创新合做。

林翔宇：可能沟通仍是要加强，你们进度要及时反馈

1. 对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。

柯奇豪：面对面交谈原则：其中的站立会议以及leangoo进度的监督做用仍是很显而易见的。

丁水源：我以为咱们小组作得最好的是"每隔必定时间，团队会在如何才能更有效地工做方面进行检讨，而后相应地对本身的行为进行调整。"原则，好比：其实队员们都不是很熟悉java和Spring Boot框架，同时大部分人也没有项目的经验，所以在研发过程中遇到了许多技术上的问题，咱们便会经常开会，相互交流，一块儿解决问题。从而对各自的下一阶段的工做进行适当调整。

• 博客要附上全组讨论的照片
  

Part 3.答辩总结

姓名	得分（百分制比例%）
柯奇豪	22
蒋雄	11
黄志铭	11
黄毓明	24
林翔宇	9
丁水源	10
杨礼亮	13

评审表格设计

Final Score：

小组	评分
第一组	53
第二组	75
第三组	73
第四组	45
第五组	70
第六组	77
第七组	68
第八组	76
第九组	62
最低分	45（第四组）
最高分	77（第六组）
有效分数	53，75，73，70，68，76，62
最终平均得分	68

Q&A

• 第一组的问题

Q1:是否考虑在beta和alpha这段期间继续完成alpha未完成的任务?

A1: 固然会接着完成未完成的任务，咱们在beta阶段来临以前尽力完成alpha阶段落下的工做量。

Q2:组内先后端的任务分配彷佛存在问题,有考虑相应的解决对策吗?

A2: 先后端在人手分配上确实是存在着问题，致使如今前端须要的工做量太大，如今咱们调整了策略，每一个前端负责各自部分工做外再完成各类部分前端的代码。

Q3:是否考虑太高并发场景下的服务器表现？

A3: 这个问题目前没有考虑过，由于有些功能尚未完成，不过考虑到各个小组内部的数据量并不会过大，并且服务器的表现如何还和价格成正比，这方面目前不会去深究。

• 第二组的问题

Q1:签到功能是否会被虚拟定位而进行不正确位置的签到？

A1: 由于签到功能的人手缺失，暂时延后开发，该问题其实以前有回答过，就是辅助加上ip地址的限制

Q2:PPT中的指定wifi签到是什么意思？

A2: 即经过连入wifi所分配的ip地址限制签到

Q3:若是成员没有打开小程序，是否会提醒发布的通知或者被邀请进的投票？

A3:能够作到的话会加入提醒的弹窗，配合已有的通知功能

• 第四组的问题

Q1:未提问

A1:

Q2:未提问

A2:

Q3: 未提问

A3:

• 第五组的问题

Q1:有没有考虑美化一下界面，或则说换一个界面风格？

A1: 我以为咱们的界面风格是能够的，简洁大方，符合办公小程序的风格，后续会在beta版本考虑进一步美化界面

Q2:队友退出没留下任何代码，能够理解为该队员没有写过代码吗

A2: 不要恶意揣测吧，写是有写的，应该是其余我的问题致使退出。

Q3:共享编辑是大家的主要功能，为何在前端方面须要三十多个页面呢？

A3: 子功能过多，何况功能没有原计划的简单明了。

• 第六组的问题

Q1:在队友退出的状况下，大家组是怎样调整分工的？

A1: 队友退出，对应负责的功能目前咱们是采用你们一块儿作，先作完对应功能的同窗来负责

Q2:在后续的做业中有没有想要采起哪一种方法来避免代码丢失的状况？

A2: 对于代码丢失这个问题，咱们目前代码是进行一更新一github的方法，及时对代码进行更新，以免丢失

Q3:前端在页面较多的状况下，有考虑什么方法来使页面更加方便本身制做来减轻压力？

A3: 咱们目前调整了工做方式，由对应功能的前端和后端一块儿负责该功能，一方面减少前端压力，另外一方面提升项目总体可行性。

• 第七组的问题

Q1:投票功能里小组选择，小组是指微信群聊吗？若是是的话，即便该群聊不在通信录里面，也能检测到吗？

A1: 小组是事先建好的工做小组，组别id是存在后端的，不是微信小组。发起人可建立小组，后来的人凭连接加入。

Q2:共享编辑，别人编辑的时候，是整篇编辑，仍是只能一次编辑一段？若是是整篇编辑，合并的时候只想合并某几段，不想所有替换，要怎么作？

A2: 对已发布文章按段处理，会显示更改日志，不用改全篇。

Q3:现阶段开发进度未涉及到核心，为何不优先开发核心功能。

A3: 核心功能其实也已经实现的差很少了，只是先后端未对接，算法已经OK了。

• 第八组的问题

Q1:团队分工有没有值得总结的地方？能够分享下

A1: 分工较平均，考虑到每一个人的具体能力。

Q2:对alpha版本的完成度如何自我评价？吸引

A2: 没有完成任务，所以较不满意。

Q3:beta版本对分工和进度跟进有什么改进的想法？

A3: 完成项目，争取改进项目。

• 第九组的问题

Q1:大家以为大家最重要的特点功能是什么？大家打算怎么实现？

A1: 共享编辑，使得文本内容共享可修改，相似于github的团队提交模式，在此基础上附带上版本的回退功能。

Q2:大家对本身的进度有具体的把握吗？分工和合做上是否是存在问题？

A2: 会根据具体的完成状况调整进度安排，可是总的来讲危机感，紧迫感不够，后续要增强。分工合做后续也会调整。

Q3:大家打算如何对代码进行管理不会丢失

A3: 代码有进展及时签进github。

Part 4.PSP与学习进度条

• 我的PSP

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划
· Estimate	· 估计这个任务须要多少时间	10	10
Development	开发
· Analysis	· 需求分析 (包括学习新技术)	10	10
· Design Spec	· 生成设计文档	10	0
· Design Review	· 设计复审 (和同事审核设计文档)	10	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	10	10
· Coding	· 具体编码	100	120
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	10	20
Reporting	报告
· Test Report	· 测试报告	0	0
· Size Measurement	· 计算工做量	10	10
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	10	10
合计		180	190

• 我的学习进度条（每周追加）

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
10	N	N	10	97	微信小程序前端数据交互，控件信息提取