Beta阶段敏捷冲刺总结

时间 2019-11-08

标签 beta 阶段敏捷冲刺总结繁體版

原文原文链接

设想和目标

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

在最开始的时候咱们就是为了解决集美大学计算机工程学院网页没有搜索引擎的问题。由于没有搜索引擎，在搜索内容时须要根据查找信息所属的不一样区域来查找，这个过程很是不方便用户信息的得取，也很容易找不到相关信息。咱们在Alpha阶段最简单的实现了计算机能够查找信息，而且相应的进行显示，可是由于没有部署到服务器上，没办法发布出去，不能进行普及，因此Beta阶段咱们主要解决服务器部署的问题，而后再针对一些小细节来方便用户体验，提升用户使用的满意度。
关于定义在前期的时候就已经清晰定义了，因此整个设计过程当中仍是很清楚的。典型的用户和典型的场景有在需求说明书中详细给出，主要针对的一直是普通用户，能够是老师也能够是学生，更能够是想要报考集美大学了解计算机学院的人群。程序员

2. 咱们达到目标了么（原计划的功能作到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
咱们基本目标都达成了，可是没有把Beta阶段全部的目标都实现。在Beta阶段咱们计划了以下：编程

新增其余学院的搜索引擎
实现网站的定时爬取以及es的自动同步
主界面设置最新通知播报栏
新增按时间筛选信息功能
扩大使用范围至移动端
将项目部署到服务器

可是最终咱们的版本里更改了主界面设置最新通知播报栏，从原先设想的多个通知栏变成一个最重要的通知栏，而新增按时间筛选信息功能由于时间的缘故最终没有去实现它。虽然少了这一部分，可是整个的主要部分都完成了。在用户调查阶段参与测试的用户79名，相信不久的未来会有更多人使用的。浏览器

3. 和上一个阶段相比，团队软件工程的质量提升了么？在什么地方有提升，具体提升了多少，如何衡量的？
总体质量效率都有提升。以前在各个功能的实现上都走了不少弯路，然而如今实现的不少功能均可以在预期时间内完成，并且由于期末你们时间比较有限，有几回队员没办法都到，虽然人数减小了，可是项目的进展并无影响。服务器

4. 用户量, 用户对重要功能的接受程度和咱们事先的预想一致么? 咱们离目标更近了么?
接受程度比咱们预计的要高一点，由于最开始作的时候主要突破在界面以及细节完善上，可是只能凭借咱们本身的主观感觉来设计。可是后来咱们发现，之前针对一个学院的数据时仍是能够作到搜索比较精准的，等数据量扩大后，精准度上有所减小，不如第一阶段的精确度了，这个应该是关键字的索引那边须要更改，那个关键字精确的方法不适应于较大数据量的状况。网络

5. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?
整个开发下来，我以为不少的设想须要有延续性，不能看得太眼前，否则可能将来须要动基层建设。若是历史历来一遍，我以为咱们能够在前期的时候除了关注点在界面设计上，应该在关键字索引的地方多下点功夫，应该选择一个即便数据量比较大但也一样适用的方法来实现。框架

计划

1. 是否有充足的时间来作计划?
是的，预留了一个半天时间专门用来准备beta阶段的冲刺计划。工具

2. 团队在计划阶段是如何解决同事们对于计划的不一样意见的？
和Alpha阶段同样咱们，当产生分歧的时候咱们首先会进行讨论，最后得出一个你们都满意的方案，固然每一个人都须要作出必定的妥协。性能

3. 你原计划的工做是否最后都作完了? 若是有没作完的，为何?
beta阶段的计划都完成了。这一次咱们预留的时间至关充足，最后距离截止时间甚至还有一周。冲刺过程当中对计划有进行必定的调整，不过误差不大。学习

4. 有没有发现你作了一些过后看来不必或没多大价值的事?
原定计划中有一项按时间排序功能，在着手准备的时候发现，主流的搜索引擎有按时间范围筛选，但没有按照时间排序的，实际运用上来讲按时间排序也没有什么实际意义。在这一功能的讨论上，浪费了咱们一些时间，最后删除了这一功能。因此在作功能的规划的时候，仍是要再多调研一下。

5. 是否每一项任务都有清楚定义和衡量的交付件?
对比alpha阶段，这一次咱们有着清楚的定义，但放弃了过于高标准的定义，追求功能的基本实现。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为何没有估计到?
本阶段顺利的按照计划进行，最后提早一周完成冲刺。惟一的意外是域名的申请备案，到用户调查结束都没有审批下来，好在影响不大。

7. 在计划中有没有留下缓冲区，缓冲区有做用么?
留下一周的缓冲区，但没有使用上，缘由是用户调研结果不须要咱们作出过多的更改。

8. 未来的计划会作什么修改？（例如：缓冲区的定义，加班）
alpha阶段，咱们计划对任务量进行压缩，留下充足的缓冲空间，这一点咱们在beta阶段完成的很好了。若是还须要对产品进行迭代，咱们能够保持现阶段的节奏进行。

9. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
beta阶段对比alpha阶段来讲，更顺利，包括技术和沟通上都有了很大的进步。历史再来一遍的话，咱们也许不能作到更好了。

资源

1. 咱们有足够的资源来完成各项任务么?
      alpha阶段已经有基础了，而Beta阶段新增的功能网络上也有一些参考资料。
2. 各项任务所需的时间和其余资源是如何估计的，精度如何?
      根据我的开发阶段每一个人所须要的时间进行估计，精度较为准确。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不须要编程的资源 (美工设计/文案)是否低估难度?
      测试时间相对Aplpha阶段较为足够。对于缺乏笔记本电脑的成员，在除了必定要全体面对面沟通的状况下，咱们采起了网上群视频通话的方式进行共同开发。对于其余资源，美工设计方面在Beta阶段无需改进，而对于搜索引擎来讲文案并不须要。
4. 你有没有感到你作的事情可让别人来作（更有效率）?
      Alpha阶段虽然是混着作的，但仍是有一些大体的成员分工，因此在Beta方面也是考虑了Alpha阶段的任务安排状况来进行成员分工，你们都是作本身较为擅长、Alpha阶段有经验的任务，因此仍是很合理的。
5. 有什么经验教训? 若是历史重来一遍, 咱们会作什么改进?
      由于计划新增的功能较多且后阶段临近考试，因此提早完成了项目，计划新增的功能中有些须要大量的时间研究且难度较高，最后未能完成。计划时考虑时间和完成难度，作一个更合理的优化计划。

变动管理

1. 每一个相关的员工都及时知道了变动的消息?
alpha阶段的时候由于没有太多的使用码云来同步代码，因此在beta阶段的时候咱们有专门注意代码的上传，每次冲刺完后都有在码云上传相关代码。同时也有在用qq传输，或者u盘。

2. 咱们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实现的确定是不能影响主要程序使用的地方，好比搜索引擎必须能搜索到内容，结果不能错。推迟的内容是分词器能不能自行控制。

3. 项目的出口条件（Exit Criteria – 什么叫“作好了”）有清晰的定义么?
有清晰的定义，能用搜索引擎来搜到咱们学院的内容，有两个页面，一个是搜索引擎的干净整洁首页面，一个是搜索到内容的显示页面，第二个页面能准确搜索到用户须要的内容，而且进行一个最优排序。

4. 对于可能的变动是否能制定应急计划?
能，刚开始原本是定制的全部学院都作一个搜索引擎，可是后面发现要完成一个就须要花一下午的时间，因此咱们就改成只加了一个航海的搜索，也是由于航海没有搜索引擎，而且也能证实咱们也能把其余的学院都爬下来只是须要时间而已。

5. 员工是否可以有效地处理意料以外的工做请求？
能，当咱们PM在冲刺以前给的任务，在进行以后发现还有一些零碎的关键任务没有人去完成，PM会按照你们擅长的部分去分配，而且会说一个截止日期，会在群里面督促你们尽快完成，因此咱们每次都能有效的完成意料以外的工做。

6. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
完成一个项目的时候不能死脑筋，必须作完这个才干吗，有时候须要灵活的运用和方法来促使整个项目的完成，会比一我的钻牛角尖好得多。此次咱们安排了不少次冲刺，时间安排的很棒，不会说由于最后没时间的赶工，由于你们最后都有考试，因此提早了两三天就结束项目。

设计/实现

1. 设计工做在何时，由谁来完成的？是合适的时间，合适的人么？
设计工做在第一次老师给出这个项目须要几个几个星期完成的实验课，咱们在实验课上就开始讨论前端页面的样式和要求，同时也在网上查找搜索引擎和爬虫的相关知识，你们都在实验课上一块儿讨论，可是这个时间是远远不够的，后面冲刺的时候最开始也有讨论过咱们程序的走向，讨论好后最终定下终稿。

2. 设计工做有没有碰到模棱两可的状况，团队是如何解决的？
用户测试这一块，咱们是用的调查问卷，在制做调查问卷，提问的时候由于有些考虑到不少人不喜欢填写调查问卷，因此咱们准备把问卷作的简单一点，我以为是用户的建议是最重要的，因此我推崇就一个空，咱们的搜索引擎有什么须要改进的么，这样咱们就能拿到咱们须要的内容，别人也不会以为很烦，可是秦玉以为应该像普通的问一些问题，否则空口答别人可能也没什么建议，咱们要的数据就根本没有。

3. 什么功能产生的Bug最多，为何？在发布以后发现了什么重要的bug? 为何咱们在设计/开发的时候没有想到这些状况?
爬虫功能产生的Bug最多，由于界面不同，学校的网站不是Css结构的，彻底是又一个一个的表格写出来的网页，因此爬取跟普通的网站爬取又有区别，都是一步一步的学习改进才爬取出数据的，由于对爬虫理解的不深。咱们尚未发布。同时也是咱们对爬虫了解也不够深刻，只能爬取到红色标题的内容，可是通过后期的改进已经能爬取所有的内容了。

4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审统一由一我的来规范代码，严格执行了代码规范，因咱们在编写的时候就在注意代码的编写，这样方便你们的理解同时后期也不用改这么麻烦。

5. 咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
只有当本身真正开始编写代码的时候你才能进步。编程的重要任务还须要分的细致一点，这样你们都能写到关键的代码，更多的熟悉爬虫。

测试/发布

1. 团队是否有一个测试计划？为何没有？
没有花太多的时间在测试上，只是有一个大概的测试计划。由于Beta阶段完成的功能比较零散，并且不少是在Alpha阶段作一些改进（如新增其余学院的搜索引擎），代码框架都是一致的，因此在搜索速度、爬取速度等方面基本没有变化。
2. 是否进行了正式的验收测试？
进行了正式的验收测试。

3. 团队是否有测试工具来帮助测试？
没有用到，只是用黑盒测试、浏览器自带的性能测试等方法来测试。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工做有用么？应该有哪些改进？
咱们并无测量并跟踪软件的效能，咱们只有代码测试各个浏览器的页面是否正确，搜索速度，爬取速度等的测试，后阶段进行用户调查，调查问卷中附加了网页连接，其实也是在测试服务器和用户交互。颇有用，让咱们的程序更符合大众使用的要求，改进了不少咱们忽略的点，同时也验证了服务器性能。

5. 在发布的过程当中发现了哪些意外问题？
经过用户调查后获得的数据，发现搜索获得的结果项中的摘要部分，是显示文章中匹配到的最后一个关键字的地方，因此若某文章中该关键字出现的位置分布在文章的前部和后部，则会致使摘要显示的篇幅比较大，其实应该作到像百度搜索出来的结果摘要，显示固定的大小。

咱们学到了什么? 若是历史重来一遍, 咱们会作什么改进?
在发布过程当中发现的摘要问题，咱们在编写及测试的时候都没有意识到，在用户交互方面还有所欠缺。在编写项目的过程当中，应该更多的以用户的角度去思考，由于作出来的产品是给用户用的，而不是程序员自己，固然在技术方面，则是要以程序员的角度寻求最优解。

团队的角色，管理，合做

1. 团队的每一个角色是如何肯定的，是否是人尽其才？
此次的角色肯定会更多地仍是从比较细的方面来划分，由于beta阶段与alpha相比，目标明确了不少，最后分出来的任务也比较细致，而后根据每一个人的能力或是意愿来进行任务的分配，大体能够作到人尽其才。

2. 团队成员之间有互相帮助么？
有互相帮助，由于咱们平时都是聚在一块儿来完成这个项目的，所以在遇到困难的时候，通常会直接提出来，而后手头上比较闲的同窗就能够一块儿来想解决问题，解决完之后积累下来的经验也会跟其余成员交流，防止踩到同一个坑里。

3. 当出现项目管理、合做方面的问题时，团队成员如何解决问题？
遇到了这方面问题的时候，通常就是让矛盾双方阐述本身的想法，而后再一块儿交流，最后达成一致，可是其实通过了alpha阶段，咱们在这方面都比较成熟和默契，通常不会出现这种问题。

总结

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

你以为团队目前处于萌芽/磨合/规范/创造阶段的哪个阶段?
咱们团队目前处于创造阶段。beta阶段咱们的团队成员已经对规范方面有了比较好的实现，而后集体意识也有所提升，对于项目的走向也有一个比较好的把握。

你以为团队在这个里程碑相比前一个里程碑有什么改进?
相比于alpha阶段，首先，咱们团队成员之间的配合更加的有默契，可以更好的沟通交流；其次咱们在技术能力方面也有很大的进步，从最开始对搜索引擎的贫乏的了解到如今已经能大概掌握其全貌以及具体实现方法；最后，咱们团队在代码规范方面和管理方面也有了比较大的改进，前一个阶段比较不注重规范，主要仍是求能实现功能就行，而后在管理方面也没有使用专门的工具来处理，beta阶段开始咱们会比较注重这一点。

你以为目前最须要改进的一个方面是什么?
我以为虽然咱们最后完成了这个项目，可是整体的完成效果其实仍是有一些瑕疵，主要仍是由于咱们投入的时间不太多，所以我以为须要改进的是但愿咱们团队的成员能投入更多的时间在项目上，这样作出来的效果应该会更好一点。

对照敏捷开发的原则, 你以为大家小组作得最好的是哪几个原则? 请列出具体的事例。
对照TSP原则，我认为咱们小组在如下几个方面作得比较好：

团队的各个成员对团队目标、角色、产品都有统一的理解
在咱们开始对产品进行讨论的时候，就已经小组达到一个共识，而后在后面不断地编写程序完成项目的时候，咱们也会按期交流一下咱们项目的将来走向以及其余一些与项目相关的内容。
增长团队的自我管理能力咱们团队的每一个成员对于咱们的项目都可以比较好的投入到里面，每一个人都有本身的定位，也都能在计划时间内完成任务。