事后诸葛亮（团队）

Posted 2021-01-23 marboy

项目名称

实验室督勤管理系统

队名

三只松鼠

小组成员

朱宏韬 180320079
古 越 180320075
张星海 180320077

设想和目标

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

本系统的目的分为两个方面：其一是记录学生考勤信息，并围绕考勤信息形成一系列评价标准，以此督促学生养成良好的学习生活习惯，提高学习工作效率；其二是帮助管理员记录相关信息，并提供参考评价标准，从而简化管理员的工作。
我们认为我们的定义已经十分明确，也将详细的用户场景记录在需求报告中了。

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

经过alpha冲刺阶段，我们基本完成了原定目标，只是遗留了一些细节没有处理（比如界面不够美观）。项目的提交也赶上了原定的交付时间，所以虽然一路上有些磕磕绊绊，但是最后我们还是完成了目标。

3. 是否有充足的时间来做计划?团队在计划阶段是如何解决对于计划的不同意见的？

我们有充足的时间来做计划，可是由于没有开发经验，所以我们初始的计划十分不全面，以至于我们不得不在之后的冲刺阶段不断的对计划进行调整。至于团队意见，我们一般会各自阐述自己的想法，意见不同的时候我们会好好争辩一番，如果最后意见不能统一，就少数服从多数。

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

最大的教训自然是要在项目初期做出更加完善的计划，更合理的分配时间，分配工作。同时对会遇到的难关也会有足够的重视，不会到紧要关头才发现自己先前对这个问题太过小看，以至于无法按时完成当天的工作。如果历史可以重来，我们会做出更加详尽的计划，遇到问题是也会更快的找到解决方式。

计划

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

原计划的功能我们都成功实现了，要说没做完的就是我们两种计算补贴的方式是按照自己的想法设计的，不知道各位实验室管理员真实的计算补贴的方法是什么，所以可能对各位管理员提供的参考价值还可以继续提高。

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

由于项目开发的整体时间并不长，所以我们在做好计划之后就立即开始学习相关技术，边学边进行开发，拼命实现相关功能，努力对各方面进行完善，所以可以说做的都是有价值的事。

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

我们对每一项任务都有定义，但是衡量的标准不够清晰。因为虽然我们对项目都有清晰的设想，但是在具体的功能实现之前，谁也不知道最后能达成什么样的效果，大家都想着先把东西做出来，之后再看看跟预期有什么出入。所以我们可能没有具体的评价标准。

4. 是否项目的整个过程都按照计划进行？

整体上是按照计划在进行。初期因为对相关技术不熟悉，所以落下了很多进度，之后马不停蹄的赶上了，中途有对计划进行一些细微的调整。

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

我们确实想要在开发途中留下一定的缓冲区，好进行修整并做好下一步的安排，但是因为所给的开发时间实在太短了，从头到尾都是在赶工，所以遇到问题的时候也只能让相关人员及时解决或作出调整，免得项目最后无法交付。

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

系统的主要功能大体都实现了，但是系统内部还有一些边边角角需要完善，也要着手美化界面。会尽量留出缓冲区，因为之前alpha冲刺的时候已经有不少熬夜的经验了，所以之后有需要的话也会继续加班。

资源

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

一、硬件资源，三台笔记本是够的；二、软件资源，开发软件都可以在网络上下载，由于组长是正经科班出身，在软件、开发平台方面给了小组成员很大帮助；三、时间资源，因为对软件开发的不熟悉，我们小组各成员花了比较多的时间在数据库，mybatis框架，java代码等方面。

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

在总体方面我们划分了环境搭建，建立数据库，编写系统各模块代码三大部分；编写系统各模块代码是其中的最主要部分，这一部分我们根据模块功能来划分任务量。我们为预计的每个项目分配合理的工作量，根据工作量的多少来计划每天需要完成的工作。每一天根据前一天完成的情况再制定当天的工作任务和工作量。

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

测试的时间远远不够，特别是前期因为我们对项目的各种方面都不熟悉，对数据库的使用，开发平台的使用等等尚存在一些问题，在完成任务上就花费了很大功夫，导致留给测试的时间很少，使得测试仅限于很初级的层次，因为代码、模块、ppt、文档都是分担到每个人手上，所以分配不好，工作量很大。

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

我觉得针对文档分工一块，有些组员对画图比较熟练，有些组员对文字内容比较擅长，这个分配如果合理的话会比较有效率。

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

有时各组员协同工作，如果没有事先约定好一些内容，那么汇总时发现各人的风格、想法不一样，为了整体的统一，我们又得花大功夫去整改，这就违反了分工的的初衷。但现实的情况是，缺乏经验的我们无法预知我们的合作应该事先约定什么，或我们的合作会遇到什么样的问题可以通过事先约定来避免，所以经验只能通过失败之后的默契来获得，丰富的失败经历才会成就更简洁更顺利的成功。

变更管理

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

我们团队有三人，两人在2号楼，一人在四号楼，所以前期交流都是在二号楼的秘密基地进行，三个人在一块，互通消息，面对面地交流，快速有效，简单简洁。后期四号楼的组长实验室搬到了二号楼，交流更加通畅了，或实验室，或深夜食堂，或图书馆，沟通方便。

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

我们针对系统的主题，优先实现系统的必需功能，且遇到的有难度的功能必须保证实现。对在系统中起辅助作用的功能模块比如相关管理几大模块，消息中心模块内的功能，尽可能实现其主要功能，对实现起来比较难，比较耗时的功能，我们会根据项目进度、时间、人力等因素考虑其存在必要性。

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

做好了是可以实现基本功能，可以满足日常使用需要的强度。

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

对可能的变更，在不改变当前数据库结构，数据表的情况下，增加功能是可以实现的。

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

对于意料之外的工作请求，我们会对其进行评定，该请求是否是应该考虑到需求里而被我们当前的开发忽略了的，或是是一个不合理的请求。对于前者，我们会努力改变我们的数据、系统来达到该请求内容、功能。

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

变更其实是一项很考验我们软件结构的操作，如果我们的软件结构合理，那么对于新增加的功能是比较友好，容易改动的。若是结构不够独立，那么有可能牵一发而动全身，伤筋动骨一百天，那个滋味确实不好受。
如果历史重来一遍的话，我们的代码多少会有些优化的。

设计/实现

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

项目的设计工作是十一月中旬左右开始的。项目最初的点子是张星海同学提出的，因为他本身就当任自己实验室的管理员，所以对实验室管理员的繁琐工作深有体会。之后由我们三个小组成员共同商讨项目细节以及具体要实现的功能，由于是三个人共同设计，我们每个人都对这个项目有自己的期待，干起活来自然更起劲，所以这个设计的人可以说是合适的。

2. 工作实现过程中有没有碰到不能解决的问题，团队是如何解决的？

开发途中遇到的难以解决的问题，我们一般是自己网上查找解决方法，之后组内讨论，还不行的话会向相关的技术大佬请教，最后总能找到出路的。

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

开始的UML文档和现在的状态确实有些微的差别，因为开发初期计划的不合理，之后在实现的时候不得不对原先的设计做出一些改动，随着工作的进行，我们慢慢的解决了遇到的问题，也消除了因为设计的不合理而带来的负面影响。

4. 在发布之后有没有发现bug? 我们在设计/开发的时候为什么没有想到这些情况?

确实有发现一些bug。因为我们对相关的技术不熟悉，在开发途中都是现学现用，并且对各模块之间的相关性认识不够准确，所以没有预想到这些bug的存在。好在我们的bug对系统的主要功能不会产生影响，只要管理员操作正确，这些bug甚至不会暴露出来。我们的学习之路还很漫长。

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

一次完整的项目开发让我们学到了很多，比如更加深刻的认识到开发项目远远不只是敲代码而已，项目成员之间的合理沟通可以有效的促进项目的进行，一个好的计划可以节省大量的开发时间等等。有趣的是因为多次在一起熬夜，我们发现了多条在晚上数计学院关闭之后从数计学院院楼逃生的通道。
如果历史可以重来，我们会做出更加完善的计划，更加合理的时间安排，更适合每个人的分工。当然，要尽量避免熬夜。

测试/发布

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

有的，我们的测试分为单元测试和系统测试两种，单元测试是安排在每个功能完成时由负责该模块的同学进行测试。系统测试是项目接近结束或者项目结束后对整合的系统进行系统且全面的测试。

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

是的，在项目的验收前有测试安排

4. 团队是如何测量并跟踪软件的效能的？

我们在项目开发过程中有程序员对模块的初步测试，在项目开发的中后期，由团队成员对项目进行交叉测试、重复测试、覆盖系统的全部已实现功能。在测试中发现系统中可改、可不改的内容，发现系统中有错误和无错误的内容，发现系统中存在的不合理逻辑等。

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

我们在测试中学到了一个道理，或者说学会了一个认识问题的角度，那就是学会站在别人的角度思考问题，一个合格的测试或者说一个高明的测试者是会让自己变成一个完全的客户的角色的，所以想象力或者说丰富的项目经验或人生阅历对测试是非常重要的要素。
如果历史重来一遍，我们愿意多花一倍时间用在对前期开发的功能模块的编写和测试上，这样虽然前期会多花很多时间，但对后期的工作会有很好的铺垫，程序会有更规范的格式。

团队的角色，管理，合作

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

在确定角色时我们遵循两个原则：
(1)充分利用各个成员的特长优势；
(2)每个成员必须参与各个方面的任务。
先由在某方面具有优势的成员开展该方面的工作，其余成员作为该方面工作的辅助者，在进行过程中逐渐积累经验，当水平达到一定程度后即可独立进行该方面的工作。是人尽其才，充分发挥每个成员的优势。

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

有。团队成员的互相帮助是团队工作效率稳步提高的关键因素。古云：三人行必有我师焉。在平时的开发过程中，每个成员取他人之长，补己之短，不仅提高了整体的效率，也提高了自身水平。

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

我们每天都会开展一次以上的讨论会，项目管理、合作方面的问题是我们讨论的重点，例如进度安排、管理制度等问题，我们会把问题摆出来讨论，大家分别论述自己的观点和想法，若有意见冲突则少数服从多数，决定后立即实施。项目管理和合作分工等方面的工作都是在一次又一次的调整中不断完善的。

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

在这次为期近半个月的软件工程实训中，我们经历了确定题目、需求分析、项目设计、项目实施、项目测试和项目验收这些过程，并从中获得了很大的收益。首先是程序编写能力和文档撰写能力得到了提高，同时总结和分析问题的能力也得到了提高。另外，对用户需求分析和软件测试也有了更加深刻的认识。学会敏捷开发：敏捷是指能够让团队思考更加有效、工作更为高效，并且做出更好决策的一组方法和相关理念，同时，敏捷也是一种思维模式，正确的敏捷模式有助于团队成员共享信息，从而共同作出重要的项目决策，而不是让一个人独自作出所有决策，在这次敏捷开发训练中，每个成员都有对实践应用的发言权，每个人都必须清楚整个项目的开工计划、设计和改进流程，我们深刻感受到这种新的思维方式能够帮助我们更加高效地工作。如果历史能够重来，我们会在项目的需求分析阶段和功能设计阶段做更加充足的工作，因为这两个阶段工作的任务可以说是整个工程大方向的确定，若完成质量高，有利于后续工作用更短的时间实现更好的效果。

总结

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

我们团队已经顺利度过了磨合期，目前处于规范期。

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

(1)团队里各成员之间的默契程度得到了提高；
(2)编程能力有很大的提升；
(3)对软件测试有了更加深刻的认识；
(4)较为完整地感受了一次软件开发的全过程。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

(1)原则：The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.（无论团队内外，面对面的交流始终是最有效的沟通方式。）
事例：在Alpha阶段我们每天都会在一起开展工作，有什么问题马上交流，通常很快可以解决或者达成一致的意见。有几次任务量较大，大家回到各自宿舍加班，有问题通过线上交流，明显感受到了这样交流的效率没有面对面交流的效果好。另外，向学长学姐和组外同学请教时我们也尽量采用面对面交流的方式以获得最好的交流效果。
(2)原则： Continuous attention to technical excellence and good design enhances agility.（只有不断关注技术和设计才能越来越敏捷。）
事例：在设计实现学生补助模块时，起初计划通过管理员直接确定补助金额，后来发现这样的效果不够理想，于是我们采用策略模式对该模块的实现进行优化，得到了更好的效果。
(3)原则：The best architectures, requirements, and designs emerge from self-organizing teams.(只有能自我管理的团队才能创造优秀的架构, 需求和设计。)
事例：我们团队要求每个成员对当天遇到的问题进行总结进而转化为经验，并且在每天工作结束时进行组内分享。将大问题划分成小任务分配给每个成员，并且每个任务的执行者都要给出计划完成时间，若在执行过程感觉不能够按时完成需立即报备组长并说明缘由，以便于整体调度。除此之外团队里还有其他相关制度，要求每个成员严格执行，这是我们团队能够不断进步的重要原因。
(4)原则：At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.（时时总结如何提高团队效率, 并付诸行动。）
事例：当某个成员有关于提高效率的想法或者方案时，我们会停下手上的工作开一个短会，让该成员分享其想法，如果是一个好点子我们会尽快应用到工作中，尽最大可能提高工作效率。