过后诸葛亮（团队）

项目名称

实验室督勤管理系统

队名

三只松鼠

小组成员

朱宏韬 180320079
古 越 180320075
张星海 180320077

设想和目标

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

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

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

通过alpha冲刺阶段，咱们基本完成了原定目标，只是遗留了一些细节没有处理（好比界面不够美观）。项目的提交也遇上了原定的交付时间，因此虽然一路上有些磕磕绊绊，可是最后咱们仍是完成了目标。

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

咱们有充足的时间来作计划，但是因为没有开发经验，因此咱们初始的计划十分不全面，以致于咱们不得不在以后的冲刺阶段不断的对计划进行调整。至于团队意见，咱们通常会各自阐述本身的想法，意见不一样的时候咱们会好好争辩一番，若是最后意见不能统一，就少数服从多数。

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

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

计划

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

原计划的功能咱们都成功实现了，要说没作完的就是咱们两种计算补贴的方式是按照本身的想法设计的，不知道各位实验室管理员真实的计算补贴的方法是什么，因此可能对各位管理员提供的参考价值还能够继续提升。

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

因为项目开发的总体时间并不长，因此咱们在作好计划以后就当即开始学习相关技术，边学边进行开发，拼命实现相关功能，努力对各方面进行完善，因此能够说作的都是有价值的事。

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

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

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

总体上是按照计划在进行。初期由于对相关技术不熟悉，因此落下了不少进度，以后快马加鞭的遇上了，中途有对计划进行一些细微的调整。

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

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

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

系统的主要功能大致都实现了，可是系统内部还有一些边边角角须要完善，也要着手美化界面。会尽可能留出缓冲区，由于以前alpha冲刺的时候已经有很多熬夜的经验了，因此以后有须要的话也会继续加班。

资源

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

1、硬件资源，三台笔记本是够的；2、软件资源，开发软件均可以在网络上下载，因为组长是正经科班出身，在软件、开发平台方面给了小组成员很大帮助；3、时间资源，由于对软件开发的不熟悉，咱们小组各成员花了比较多的时间在数据库，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.（时时总结如何提升团队效率, 并付诸行动。） 事例：当某个成员有关于提升效率的想法或者方案时，咱们会停下手上的工做开一个短会，让该成员分享其想法，若是是一个好点子咱们会尽快应用到工做中，尽最大可能提升工做效率。