北航现代软件工程项目Postmortem
——远航1617团队事后分析报告
一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
答：我们所设计的软件是一个网络爬虫程序，其主要功能为：为“网上问答系统”提供网络资源的获取和筛选功能，通过爬虫程序，该问答系统可以从爬取到的文件中获取到自身所需的各类资源、同时过滤掉无用的广告信息等；我们的爬虫程序有明确的定位——满足后继小组的需求，因此我们对自己的定位比较清楚，对用户和使用场景也有较好的认识。
2.是否有充足的时间来做计划?
答：我们的程序是在沿用上一届学长学姐的代码的基础上进行优化和更改的，但由于各种原因，使得我们并没有在计划时间内获取到代码，导致了后期工作的延误。不过在团队成员的共同努力下，还是准时地发布了Alpha版本。
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
答：由于计划阶段是项目开发的前期，因此我们十分注重彼此的交流，在每次的Daily Scrum上，大多数队员都积极地表达自己的想法，同时和认真地听取了别人的意见，并由PM进行从中协调，这样一来，既能在最终使大家的意见基本达成一致，又能增进彼此的感情，有利于项目的进展。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
答：我们的用户目前基本定位为ILOVESE编程小队，所以与预想的一致。而据我们了解，他们对我们的程序还是比较满意的。如果进一步的对项目进行开拓的计划，我们则将进行更深层次的程序设计和功能完善。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：这次团队编程任务中，最大的问题在于代码获取耗取的时间较长，因为多次联系学长都失败了。虽然这并不是一个很重要的问题，但确实对我们的开发进度造成了一定的影响。在以后的开发过程中，我们将进一步发挥大家的能力，让我们团队能在更短的时间内获取自己所需要的资源。如果历史重来一遍，我们会更尽力地联系学长，并考虑从其它途径获取我们需要的资源。
二、计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
答：原计划的工作并没有完全做完，因为原始代码的获取时间过长导致后期工作的延误，同时团队成员刚开始由自己实现爬虫程序，需要时间学习和适应，也耗费了一些时间。未完成的工作我们将在下一个版本继续进行开发。
2.有没有发现你做了一些事后看来没必要或没多大价值的事?
答：目前还没有，我们的工作进行还是比较顺利。比较明显的感触就是：在与客户交流时，我们并不能完全只考虑顾客的需求，而应该同时考虑顾客需求的实现的可能性和必要性，同时实时地向客户反应。
3.是否每一项任务都有清楚定义和衡量的交付件?
答：是的。我们的团队的Daily Scrum都有相应人员进行记录并发布博客。我们的程序的功能测试、使用说明、发布说明也一一按时地公布到博客上了。
4.是否项目的整个过程都按照计划进行?
答：不是的。正如前面所说，原始代码的获取这一部分的计划出现了问题。不过现在这个问题也已经解决。而且这个问题并不具有持续性，所以并不影响我们下一个版本的开发和发布。
5.在计划中有没有留下缓冲区，缓冲区有作用么?
答：有。主要功能为：用于计划之外的任务安排。例如客户需求出现更改，我们需要进一步协商，则可能需要有缓冲区来提供时间方便；在项目开发过程中出现重大问题，需要大家一起讨论，则增加一次或者多次的集体会议等。
6.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
答：将来的计划：进一步加强对需求分析的计划，这样可以减少因为需求变动而改变开发计划所耗去的时间；横向地进行计划拓展，即在相同的时间长度内，丰富工作内容，增加计划项目，提高效率，这样更可以锻炼开发成员的能力，也可以有更多余力进行项目测试等内容。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：我们真切地感受到了“计划赶不上变化”的事实，每一天的任务虽然都在进行，但团队中每个人都有自己除了软件开发之外的活动和任务，所以我们并不能死死地按照计划去进行。如果重来一遍，我们会考虑横向拓展计划，提高计划的执行效率，这样既可以节约时间，又可以提高大家的能力。
三、资源
1.我们有足够的资源来完成各项任务么?
答：有的。我们从学长那里获得了原始代码，这是我们最重要的开发资源。其次，老师多次对我们的项目提供帮助，解决了我们许多难题。这都使得我们更好地完成了我们的任务。另外的，我们也可以通过网络手段等获取所需的资源，解决相应的问题。总体来说，程序开发过程中还是很顺利的。
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
答：各项任务所需时间的估计是通过询问已经开发过此类项目的前辈加上对自己能力的考虑等多个方面综合之后进行的。简单的说，就是我们既从客观上了解了爬虫开发所需的时间和资源要求等，再从主观上根据自己平时编程所需消耗时间来判断，综合之后，得出了相应结果。
3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
答：测试时所需要的时间和人力资源都是足够的。爬虫程序对硬件的要求比较低，我们在比较理想的测试条件下完成了测试。目前，在美工方面，我们仅仅考虑了比较简陋的美工设计，因此所消耗资源不多，在Beta版本中，我们将进行这部分开发的资源估计、获取和分配。
4.你有没有感到你做的事情可以让别人来做（更有效率）?
答：在团队PM的带领下，团队每个成员都积极地投入到了项目开发过程中去，所以大家完成任务的情况还是让团队里每个成员都比较满意的。不过我们可以考虑进行任务分配的优化，这样也有利于项目开发的高效。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
答：主要经验教训是：任务分配的灵活性。其实并不一定某项任务就一定只能由某个人或者某几个人完成。我们可以让团队内的成员自由选择任务，而并非简单的任务分配。这样一来，既可以调动大家的积极性，提高项目完成效率，也可以让大家都得到锻炼。
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
答：我们在进行Daily Scrum时都实时进行变更消息的通知。同时因为开发成员都是本班同学，所以项目有什么新的进展大家都是非常清楚的。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
答：主要方法为：对功能进行细致分析和讨论，再通过投票的方式决定某功能的重要性，之后如果有差别意见，则再进行新一轮简单论述后，进行新一轮投票，决定功能的“推迟”与“实现”。这个过程中如果有其它因素的导入，例如客户需求的改变，则以改变之后的设计为主。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
答：对于我们爬虫程序而言，所谓“做好了”是指：可以在满足客户需求的前提下，实现爬虫程序应有的功能。我们的程序虽然不是十全十美，但是已经可以达到客户的基本要求。在进一步的开发计划中，我们将继续与客户讨论，并进行新的功能设计和开发。
4.对于可能的变更是否能制定应急计划?
答：前一阶段的开发过程中，没有出现重大问题，所以我们还没有考虑太详尽的应急计划。但是我们在开发过程中，如果即将对功能进行修改，我们会让我们的成员对目前已完成的内容进行备份和暂存。如果发现变更后的设计不够理想，我们会回到原来的位置，重新进行开发。
5.员工是否能够有效地处理意料之外的工作请求？
答：我们的团队成员都是非常好相处的、性情温和、又不乏独立思考的成员。所以大家对于意料之外的工作请求都是能相互体谅、彼此之间协商调节的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：在变更部分，我们觉得可以跟计划部分相结合而论。那就是我们在开发初始阶段所做的设计和计划都只是为了让我们的开发有一个比较明确的目标和一个比较严谨的开发过程而已。但是等到真正开发时，我们并不能保证项目内容的一切都在掌握之内。这是我们就需要实时地对项目计划进行变更和修改，这样我们才能更好地完成项目开发。
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
整体设计是在项目开发的前期，由团队大家共同讨论决定的。在之后的项目开发里，不同的设计工作由不同的开发人员完成。这些工作最后都取得了良好的结果，所以可以说是合适的时间、合适的人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
答：较少，主要解决方法还是通过Daily Scrum大家进行讨论后解决的。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
答：用到了单元测试的工具，这是为了爬虫程序中不同部分的测试而使用的工具，收效还是比较理想的。
4．什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
答：在爬虫程序中，广告过滤的功能和文件下载功能Bug较多；因为不同的广告地址有不同的编码格式和文本内容，我们需要对不同地址的不同编码格式的URL地址进行处理，例如含有中文的地址等，这就导致的工作的复杂性；文件下载则是因为下载文件的类型多，下载分类复杂，导致代码编写复杂，容易出现编写错误等。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
答：代码复审由主要的开发人员和测试人员进行。在使用简单测试用例的过程中一边测试、一边审查代码。我们较为严格的执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：主要学习：结队编程技巧。我们团队内人员的软件开发技巧好坏不齐。为了让编程能力较差的同学也得到一定的锻炼，我们选择了结对编程的方法，让团队成员两两合作，相互学习，这样既能提高团队成员的编程能力，也进一步让大家的更好地进行了交流。
五、测试/发布
1.团队是否有一个测试计划？为什么没有？
答：有，但是不完善。我们项目的测试方法就是直接运行程序。通过多次的，给予程序不同输入的迭代式的测试。这个方法虽然比较方便操作，也能比较有效的得到所需的测试结果，但是操作起来确实不是很方便，也具有一定的偏差（跟测试条件的硬件环境有关）。
2.是否进行了正式的验收测试？
答：是的。我们将测试的结果进行了汇总之后攥写了测试报告。
3.团队是否有测试工具来帮助测试？
答：目前没有用到特殊的测试工具。所测试的网站都是由测试人员自己输入进行测试的和监控的，所以可能并没有十分准确。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
答：我们通过控制变量法，分别记录爬虫程序在不同网站相同爬取页数、相同网站不同爬取页数条件下的运行结果进行性能测试。从结果来看，这有利于我们更好地了解我们爬虫程序的性能。我们也查看了程序运行时的CPU占用率等。
5.在发布的过程中发现了哪些意外问题？
答：主要问题：可执行程序导出出现错误信息。这个问题我们还在进一步研究过程中。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
答：学到了：软件的测试和我们原来编写的窗口化程序的测试是完全不一样的。软件测试需要综合地、多方面的测试，包括性能和功能的实现等，这比简单的窗口程序的设计来得复杂的多。如果有机会重来，我们可能建立一套较为完善的测试计划，这样才能得到更好的测试结果。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
答：我们团队应该属于CMM中“已定义级”的阶段，并且正在向“ 已管理级”进步中，我们会继续努力，学习在软件开发过程中合理的利用各种资源的。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
答：就团队成员的表现情况而言，应该已经过了磨合阶段，初步进入规范阶段了。接下来就看各位团队成员在Beta版本开发过程中的表现状况了。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
答：团队成员对于我们团队的感情更深厚了，对我们开发项目的认知程度也比之前更深层次了。
你觉得目前最需要改进的一个方面是什么?
答：团队成员的编程能力参差不齐，所以我们比较急切需要提高各位成员的编程能力，特别是JAVA语言的使用能力。如果编程能力提高了，我们将能更好地进行程序设计和功能开发！
另外的补充问题：
1) 对比敏捷的原则, 你觉得你们小组做得最好的是什么?
答：最好的主要为以下两点吧：
第一、结队编程。正如报告前部分所说，我们团队在开发的过程中用到了结对编程的方法，这样能让编程能力较差的同学跟着编程能力较好的同学一起学习和开发，这样既能让我们的成员得到能力上的锻炼，也能让我们的项目更加完善，让各项任务完成得更加高效；
第二、沟通与反馈。我们与我们的客户团队是同学，所以我们会适时的了解客户的需求，客户团队也会与我们讨论他们的需求情况，并结合我们当时的开发进度提出一些建议或者想法。这样既能保障我们开发的产品能另我们的客户满意，又能保障我们的工作在可控的范围之内。
2) 什么是在下个阶段 M2 要改进的地方? 越具体越好。
答：
第一、功能设计：在下个阶段，我们将会在我们的爬虫程序中加入更多的功能，并进行更好的优化。主要包括：广告过滤功能的优化、爬取网页URL地址的进一步解读和优化、下载文件类型的扩充、URL输入方式的优化、数据库的维护和优化等；这些功能的实现和完善主要是为了我们的项目能更好地迎合客户的需求，更具有人性化；
第二、测试计划：Beta版本的发布应该是比Alpha版本更严格的。所以我们所做的测试内容应该也更具有完整性和必要性。为此，我们将建立自己的测试计划，在沿用“控制变量”法的基础上，融入“头脑风暴”和“淘汰法”等方法，进行更全面更完善的软件测试。
第三、人力资源分配优化：虽然之前一阶段的资源分配也是比较合理的，但是还有规划空间。所以在这一新的阶段，我们会更加重视这方面的优化，以此提高我们项目开发的效率。另外的，新阶段的开发过程中，我们团队的成员与其它团队成员进行了交换。我们将会合理地为我们的新成员执行工作计划，让他更快速地融入我们的团队，让项目开发更加顺利！
以上，为远航1617团队的事后分析报告！