过后诸葛亮（追光的人）

交换组员的工做交接和培训方案

工做交接

• 新成员冯凯，考虑到项目技术不一样，学习项目技术的成本太高，通过商讨让其负责对beta的成品进行验收和测试；原成员fishkk的工做均摊到其余三个后端成员上；

培训方案

• 阅读熟悉以前的项目文档，熟悉测试要求，能达到根据验收标准完成验收报告的程度；

设想和目标

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

咱们的软件主要针对大学生社交，还有平常的校园互助、校园小应用；
1.信息壁垒
2.信息可靠性不知晓
3.社交圈子窄
4.资源没法合理利用
5.问卷调查困难
6.学校开展活动，学生参与积极性不高

在选题报告中有详细的定义；

在选题报告对典型用户和典型场景都有清晰的描述；

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

原计划的功能基本完成；

原计划并无完成完整项目的打算，因此还没有能够交付；

原计划未列出用户数量要求；

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

软件工程的质量提升了

会议的效率；编码的规范；若是用工做量/时间来衡量的话，相比团队创建初提升了1.5-2倍；

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

Alpha阶段并无预估上线和拥有用户；

咱们目标更近了，论坛社交模块基本完成；只剩余一些校园小应用，能够再后续初版本发布以后，进行增量开发；

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

在最先的团队的会议中忽略了团队建设，而只是讨论分工，致使你们虽然在一块儿作项目，可是感情并无创建起来；在后续的合做中发现维系一个高效的团队，这种互相承认和情感交流是很重要的

在制做文档的时候过分拘泥于老师的题目要求，为了完成而完成，而未真真切切的去考虑软件工程思想的要求；文档服务于软件工程，应该主要着眼于项目的实际，作出切实可用的文档；

在预估Alpha工做量的时候，预估的工做量是没有太大误差，可是缺乏对可否按时完成的估计；

• 咱们会作什么改进？

作好团队建设；

在后续的文档制做中更加用心，着力于服务项目的开发；为后来者留下一个好的基础（老师询问是否愿意将项目传给下一届，咱们是十分愿意的）；

预估工做量和安排计划以前，应该统计一下成员能够付出的时间再进行计划安排；

计划

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

在Alpha冲刺前咱们花了数天的时间来分配学习任务，后面又有对计划和分工组织会议进行讨论；

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

咱们对于计划的意见比较统一；计划是组长提出，队友分析讨论的结果，由于很早就对成员进行了分工，因此并未出现意见冲突；

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

未彻底做完，还剩余先后端对接的工做；

对成员的时间、精力缺少统计和考量，拟定的工做量太大（十天335小时的工做量）；

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

接口设计这一块设计了一些暂时没有用到的接口；如今看来是能够放到beta阶段作的；

前端使用weex做为主界面，对于h5和小程序不支持，其实彻底可使用vue来写，这样平台都能通用；

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

对每一项任务都有一个测试和验收，验收测试以后才进行下一部分的开发；

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

按照计划进行，未出现什么意外；

没有遇到什么称得上风险；代码按照原定的安排有序开发；若是先后端对接没有完成是风险的话，没有估计到是由于对成员的时间、精力缺少统计和考量，拟定的工做量太大；

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

没有留下缓冲区；

缓冲区有利于应对突发事件；处理项目的风险；

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

缓冲区设立应该怎么考量？其实队员除了软工实践这门课程还有其余不少事情要忙；定期完成工做都是一个挑战；

若是要靠队员通宵来定义这个缓冲区的话，不设置也罢；

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

技术上：后端学到了spring boot的开发；前端学到了vue、uni-app、weex的入门知识；测试上对于测试工具和测试方法有了更深入的理解；

团队上：咱们更加熟悉团队协做来完成项目这个流程；对于一些软件工程的理论和思想在“作中学”中有了更深入的理解；

若是重来一遍，咱们可能仍是会选择这些技术栈，由于这些技术实用，而且上手并不太困难；

资源

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

资源上主要只须要时间资源；这方面咱们是短缺的；

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

对于后端，按照每一个接口2个小时；前端一个界面4个小时；精度比较准确，咱们实际的开发所需时间相差很少；

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

对于测试，我能专门安排了一个队友来进行测试的工做，对于软件有免费的软件使用，硬件并没有过高的要求，这些都已知足需求；

美工设计/文案在以前的原型设计、选题报告等都已经完成了；此次Alpha并没有这些资源要求；

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

从如今的成员满意度来看，你们对本身的工做状况、工做成果都是比较满意的；学习的技术也是本身原先想学的，因此技术上并无这一块的想法；

可是对于博客的撰写，成员“星夜、痕”的文笔不错，若是让他来作，应该会比衡与墨作的更好；

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

经验教训，由于没有惨痛的过程，因此没有什么教训；

经验这一块来讲，项目实时进度的把控对于PM来讲很重要；在Alpha冲刺以前就要充分设计和考虑项目须要用到的技术，而且提早布置成员学习，这样才不会在Alpha阶段手忙脚乱；

改进：时间的分配须要慎重考量，太重的工做量会致使没法预期完成；团队的前端和后端应该进行更多的交流；在会议讨论工做之余，要作好团队建设；

变动管理

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

经过每日会议和实时的qq讨论，你们没有错过实时的变动消息（其实也没多少变动消息）；

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

在Alpha以前就以为好了优先完善论坛和帖子功能，先不完成校园小应用；这一方面的考量是来自于工做量的估计；时间不足以咱们完成全部的功能；

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

在以前的系统设计验收标准中有明确的定义；

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

能；应急加班；哈哈，你们都很给力；所幸没有什么大的变动，仅仅是接口参数调整啊，界面增长按钮啊，这样的一些小变动；
Alpha后换人这个变动，对于换人，因为技术上并无彻底依托于某一个成员，而且比较困难的部分也在Alpha阶段完成了，因此换人对于项目并无太大的影响；

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

没有遇到；基本是按照预期的流程计划走的；工做安排会提早协调好；

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

验收很重要，前一步骤没有验收好会致使后面的工做作的很差；
应对变动的最好方法就是平均的安排任务，尽可能不要把任务和技术积压到一我的身上；还有就是提早布局，不管是技术学习仍是工做安排；
改进的话，对于队友的学习状况缺乏反馈和帮助，致使队友上手较慢，所幸安排学习的早，否则会致使突发状况的时候过于倚重某个成员，计划没法变动；

设计/实现

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

在Alpha以前就进行了设计工做，你们一块儿完成的；

是合适的时间，合适的人；

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

没有，在原型设计以前的需求分析中，你们都进行了很细致的讨论，这为后面的设计工做作了铺垫；

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

使用Junit来进行了单元测试；使用Jprofie进行了性能分析；

这些工具颇有效，在移交测试人员进行测试以前就减小了不少bug；

uml相比alpha以前有了一些字段的增长，在实际开发中漏发现以前漏考虑了；

有对uml的文档进行更新；

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

每一个功能都有差很少的bug产生，由于队友对于框架熟悉程度不够，对于后端开发理解不够；

Alpha阶段 还没有发布，项目还未完成；

Alpha阶段 还没有发布，项目还未完成；

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

测试时同时检查了代码规范； 整合时再度检查了代码规范；

是，严格执行了代码规范；

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

设计必需要充分，这样开发才会省力；

改进人力检查代码规范很辛苦，应该给ide装上一个检查代码规范的插件；

测试/发布

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

有，先测接口，再验收界面，再测试先后端对接后的成品；

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

是；对于不合格的部分回滚开发人员修改，直到测试经过；

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

使用postman进行接口测试；Junit进行单元测试；

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

使用Jprofie进行了简单的效能分析；

是有用的；可是仍是不够全面；

改进：增长对后端的压力测试；

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

Alpha还没有发布；

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

测试要全面而具体，而且回滚要及时而且严格；单元测试应该融入到项目开发之中；

改进：编码实现对接口进行自动化测试；对后端进行压力测试；

团队的角色，管理，合做

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

从成员的原有技术栈、成员的兴趣来考量；

除了衡与墨以为“星夜痕”的文笔更好，若是让他来撰写博客会更好以外基本人尽其才；

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

会；遇到问题会一块儿讨论而后解决；

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

解决最好的方式是线下交流；事实也验证了这一点；

感谢总结：

221600219 衡与墨

最感谢的是 真·大熊猫 ，谢谢你对个人包容和理解，而且主动在项目中承担了不少的工做，分担了不少的压力，你的责任心有时候让我自惭形愧，和你合做真的很幸运，但愿你能考研到理想的学校；
其次感谢fishkk，对于不少后端的工做，都安排到了你的身上，感谢你一直的支持和理解；
感谢星夜、痕，在有些时候，我提出问题的方式太尖锐，感谢你一直以来包容我，理解我，和你搭档真的很开心；
感谢其余的队友：kilig、巴啦啦魔仙、lc，大家一直都很信赖我，很是积极的完成工做，项目的顺利进行，离不开大家；

221600240 真·大能猫

我感谢组长衡与墨对个人帮助，  由于app前端从未接触过，对我来讲是一个全新的领域，是组长给了我入门的途径以及在开发过程当中帮我解决了一些我解决不了的问题，也感谢全部队友对我负责的模块的建议，让我能更好的完善个人工做。

221600212 kilig

我感谢 组长衡与墨 在包括结对在内的整个软件工程，给我带来许多帮助，积极带领咱们的团队有条不紊的完成任务，承担了不少责任，在此次活动负责的测试任务也让本身收获很多，此次的冲刺对于我从此的学习是一个很重要的指导。

221600235 fishkk

我感谢 组长衡与墨 对个人帮助， 由于某个具体的事情: 对于没有后端开发的经验我来讲，在后端开发过程当中由于过于依赖前端发生了一些没必要要的疏忽，感谢组长大人的及时提醒和指正，这对于我从此的后端开发学习是一个很重要的建议和指导。

221600236 巴啦啦魔仙

我要感谢 组长小墨 这个项目作到今天这个地步他的付出是至关重要的，他有过作项目的经历，针对咱们每一个人都能很合理的安排任务，对于技术也懂得比较多，告诉咱们应该学习什么技术。若是没有他，该次软件实践，我可能就像和以往的实践课程同样应付了事，不会学到这么多东西，没机会接触到何如组织一个大型的项目。还有，他今天请我喝奶茶了，谢谢组长的奶茶。

221600103 lc

我感谢队友真·大能猫和组长小墨的帮助，在此次项目中咱们负责前端开发。当我在开发界面的过程当中碰到了困难时，经过求助获得了他们及时的帮助。我也所以在此次开发过程当中学到了很多知识，也在不知不觉中养成一些好的习惯，学到解决问题的好方法。

221600205 星夜、痕

我感谢小墨对个人帮助。在Alpha冲刺以前，小墨就为咱们统一推荐提供了一系列方便快捷的软件：IDEA编译软件、navicat 数据库软件、postman测试软件。以后还给咱们寻找到spring boot入门视频以及spring boot web进阶 和 Hibernate注解的慕课网教学。也就是说，在 Alpha冲刺以前，小墨就为咱们作了不少铺垫。然而，在实际写代码的时候，我仍是出现了一些问题，并且是很严重的那一种。在写代码的时候，我依旧是采用之前写代码的方式，建立本身的一个项目，而后参考网上教程和队友们写的代码，本身写一份。举一个简单的例子：就像是当时我不了解 token 接口的怎么写，而后我就把小墨写的token接口一句一句的照搬到本身建立的项目中。但后来是长平点醒了我，咱们是一个团队，何况github的做用即是把本身写的代码融入到团队项目中，善于运用队伍里已有的方法，而不是根据本身的须要，从团队代码中扣取一部分来本身建立的项目中。这大概是一种里程碑式的心态转变，也让我更喜欢和热爱咱们的团队。再次感谢小墨队长。

总结:

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

档次二：CMMI二级，管理级；

这个级别的表述：　　

在管理级水平上，企业在项目实施上可以遵照既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的全部项目实施都会获得成功。

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

规范阶段；

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

效率上、人员默契上、技术能力上都获得了较大的提升；

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

改进：开发专门的测试脚本，方便测试；

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

四、在整个项目开发期间，业务人员和开发人员必须每天都在一块儿工做。

五、围绕被激励起来的人个来构建项目。给他们提供所须要的环境和支持，而且信任他们可以完成工做。

六、在团队内部，最具备效果而且富有效率的传递信息的方法，就是面对面的交谈。

八、敏捷过程提可持续的开发速度。责任人、开发者和用户应该可以保持一个长期的、恒定的开发速度。

十二、每隔必定时间，团队会在如何才能更有效地工做方面进行检讨，而后相应地对本身的行为进行调整。

4 -> 咱们的业务开发人员都在校内，业务和开发兼顾；

5 -> 咱们充分信任队友；

6 -> 咱们天天面对面交谈（每日立会）；

8 -> 开发速度稳定；天天都有规定的进度安排；

12 -> 在每次每日立会都会对以前的工做进行反思；

正如咱们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提升软件工程的质量呢？

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

使用专门的idea插件来提升规范编码；

2. 整个程序的架构如何具体提升？ 如何经过重构等方法提升质量，如何衡量质量的提升？

重构使用微服务架构，解耦系统，分红多个服务，下降系统的耦合度，提升系统的容量；

3. 其它软件工具的应用，应该如何提升？

多查阅idea、Hbuilder x的使用教程；

4. 项目管理有哪些具体的提升？

分工上、工做量预估上；

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

还未上线，暂时没有这个考量；能够实现对应的接口和管理界面来呈现每日/周活跃用户等数据；

6. 项目文档的质量如何提升？

减小口语化；多使用标准的项目文档词汇来进行描述；

7. 对于人的领导和管理， 有什么具体能够改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

重视团建，营造良好的团队气氛；

8. 对于软件工程的理论，规律有什么心得体会或不一样意见？ 请看阅读做业。 (这个做业的期中阅读)

理论来源于实际，实际不能只看理论；在实际中思考理论是更可取的方法；

过后诸葛亮讨论会议照片

咱们在觅蜜喝奶茶，一块儿聊天，总结alpha的收获并思考改进的方法；