Alpha阶段敏捷冲刺总结
Posted qin-yu
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Alpha阶段敏捷冲刺总结相关的知识,希望对你有一定的参考价值。
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们设计的软件主要是为了解决集美大学计算机工程学院网页没有搜索引擎的问题。没有搜索引擎使得用户不能快速地查找文件和公告,很不方便。定义得十分清楚,爬取学院网站数据,并且建立一个搜索引擎来方便访客查找。有十分清晰的描述,我们用户只有一种,不分老师和学生,来访者为一类用户,打开我们的搜索引擎填入想要搜索的内容就可以查找了。
2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么?原计划达到的用户数量达到了么?)
基本达成目标,实现了我们学院的搜索引擎。但是我们原计划中的细小功能没能完成,例如在搜索框的下方显示学院最新发布的通知、学院首页搜索引擎的入口等。最终按照原计划交付了,记错了截止日期,导致我们的最后几次冲刺很仓促,但是我们还是在最后的期限完成了功能,按时交付。因为页面不会因为用户的类型不同而改变,所以用户总体都看做为一个,没有用户数量的考虑。
3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?
目前alpha阶段刚刚完成,故没有上一阶段进行对比。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量我们事先就当做每个人都是一样的页面,还没有测试过超过100或者1000的人调用我们数据库会不会崩溃。用户对重要功能的接受程度和我们事先的预想一致,我们内部调用的算法是可以完全满足的,同时还有满足拆分树来分词查询,尽量查到用户需要的,最优算法。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
我还是觉得我们项目启动的太慢了,所有后面一碰到什么要用的环境,就需要去安装去,了解,太花费时间了。在前期设想阶段要贴切实际,不要天马行空,不然最后没法实现,也会给团队造成更多的负担。
计划
1. 是否有充足的时间来做计划?
有,我们PM做得很好,每次要开始冲刺之前就想好每个人的任务,今天的主要目标,并且分配下来。所以我们每次冲刺都能够很快进入状态,不会产生拖拖拉拉单个成员之间不知道该做什么的情形。但实际上我们只有在集体开发的时候效率特别高,在个人开发的时候效率很低,可能也有其他队员在起一个互相监督的作用。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
我们一般情况下会在会议中提出并共同讨论,根据实际情况提出多种看法。一般情况下,讨论到最后都能够达成共识。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
alpha阶段的最基本的目标是——实现搜索引擎,这一点完成度很高。但搜索引擎的附带细节,例如按时间排序、标签搜索、最新通知等功能没能完成。原因主要分主观和客观,主观上来说,我们在计划阶段设想太过详细,导致任务量过多,没能很好完成。另外,在学习新知识和环境搭建上花费了较多时间;客观上,对于这个项目,我们所需要学习的知识原理比较多比较难也是没能完成原计划的重要原因。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没必要的事没发现,倒是觉得有一件有价值的事但我们没有很好完成的事——代码管理。没有善用git进行代码管理,带来了一些代码更改、共享的问题,不那么快捷有效,并且没能很好的保存提交记录。我们在之后的阶段会尝试使用科学合理的代码管理方式。
5. 是否每一项任务都有清楚定义和衡量的交付件?
在功能相关的任务上,都有过清楚的定义,这也是一些功能没完成的原因——一些定义太细致高端而没能完成。
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
项目大致按照计划进行了:学习、配置、代码编写。出现意外是,记错了截止时间,导致最后三次冲刺很仓促,都是加班加点进行的。时间不够这个风险是没想到的,按照原计划,七次冲刺的任务都被安排的很好,前几次冲刺完成时间都与原定的情况差距不大,没想到会把截止时间记错。
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
有,但是没用,和第六的问题类似。
8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
由于我们的alpha计划相对还是合理的,所以下一阶段最重要的是,别再把时间记错啦!!除此之外,我们还要把时间任务往前压缩,在截止前留下充足的缓冲区,应对可能的突发情况。还有就是,在人员任务安排上要更合理,争取提高效率,不“加班”!
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
编程能力上,我们对python有了很大程度上的理解和熟悉,特别是爬虫框架;在团队合作上,学会了合理分配任务,最重要的还有沟通。
资源
1. 我们有足够的资源来完成各项任务么?
python作为一门相对成熟且开源的语言,网络上已经有非常多的资料可以参考了。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
根据个人开发阶段每个人所需要的时间进行估计,精度较为准确。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
缺少测试时间。共同开发时,一名成员缺少一台笔记本电脑,最后尝试使用远程演示的方式参与共同开发。其他资源难度还在我们能力范围内。例如美工设计,我们有一位摄影和ps爱好者(韩烨),还有ps大神(雯婷),另外前端框架自带的样式往往就很优秀,可以直接使用。
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
其实我们都是混着做,做一会儿不懂就问别人,大家一起攻克难关,其他的人的任务都分配的很合理
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
更好地规划测试时间,争取更完善。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
虽然我们没有跟着老师的方法用git,及时储存当天的编写的代码,但是我们都有在qq群里面共享今天的代码,并且没有来的人员我们都通过语音的方式有在及时的联系,来共同完成整个项目的进度
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
当我们的程序首次能爬下w学院网站的时候我们发现我们是能爬下来a,但是a爬下来的数据只有十几条,仔细一看,原来只爬了学院红色标题的链接,黑色标题的并没有爬下来,当时我们选择了这个功能实现了就好,抓紧时间做后面的搜索引擎,这个问题可以后面再完成,因为对整个程序的运行并没有太大的影响。搜索引擎的实现比爬到数据更重要,所以必须完成。我们是根据最后演示的完整程度来决定推迟和必须实现。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
有清晰的定义,能用搜索引擎来搜到我们学院的内容,有两个页面,一个是搜索引擎的干净整洁首页面,一个是搜索到内容的显示页面,第二个页面能准确搜索到用户需要的内容,并且进行一个最优排序。
4. 对于可能的变更是否能制定应急计划?
能,最开始我们在建立搜索引擎的时候本来是规定好用的是luence来建立索引,最后大家在经过一番学习之后改成了ElasticSearch,因为用这个方法建立索引特别方便,它有自带的方法能够让我们调用,我们也不用考虑最优树的算法,直接调用就好。
5. 员工是否能够有效地处理意料之外的工作请求?
能,当我们PM在冲刺之前给的任务,在进行之后发现还有一些零碎的关键任务没有人去完成,PM会按照大家擅长的部分去分配,并且会说一个截止日期,会在群里面督促大家尽快完成,所以我们每次都能有效的完成意料之外的工作。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
完成一个项目的时候不能死脑筋,必须做完这个才干嘛,有时候需要灵活的运用和方法来促使整个项目的完成,会比一个人钻牛角尖好得多。我们的冲刺时间安排的有点紧凑,当时应该早一点安排提前多冲刺。
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计工作在第一次老师给出这个项目需要几个几个星期完成的实验课,我们在实验课上就开始讨论前端页面的样式和要求,同时也在网上查找搜索引擎和爬虫的相关知识,大家都在实验课上一起讨论,但是这个时间是远远不够的,后面冲刺的时候最开始也有讨论过我们程序的走向,讨论好后最终定下终稿。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
设计前端是时候,我们在讨论的时候就前端的问题争论了很久,因为也是各队员之间表述不清楚,有三个人是觉得应该在学校的页面上加一个搜索引擎的方框,PM就以为我们要做一个以学校网站为基础的搜索引擎,提醒我们老师是让我们摒弃学校网站的,因为学校网站太垃圾了,其实我们的意思只是说加一个小方块在学院网站上,这样我们的搜索引擎才有人用,不然别人要专门找我们的页面很难找到,PMs就说这个是都是整个项目完成之后的单独任务了,所以这里先不提后面需要实现的内容,现在只要讨论我们现在迫切必须完成的任务。
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
团队有各个浏览器的页面是否正确,搜索速度,爬取速度,但是没用TDD,UML,我现在觉得无效,但是要真正用过之后才知道是否好用,在编写代码的过程中逐渐发现很多问题才产生的新的需求和想法吧,肯定是要更新UML 文档
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
爬虫功能产生的Bug最多,因为界面不一样,学校的网站不是Css结构的,完全是又一个一个的表格写出来的网页,所以爬取跟普通的网站爬取又有区别,都是一步一步的学习改进才爬取出数据的,因为对爬虫理解的不深。我们还没有发布。同时也是我们对爬虫了解也不够深入,只能爬取到红色标题的内容,但是经过后期的改进已经能爬取全部的内容了。
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
代码复审统一由一个人来规范代码,严格执行了代码规范,因我们在编写的时候就在注意代码的编写,这样方便大家的理解同时后期也不用改这么麻烦。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
只有当自己真正开始编写代码的时候你才能进步。编程的重要任务还需要分的细致一点,这样大家都能写到关键的代码,更多的熟悉爬虫。
测试/发布
1. 团队是否有一个测试计划?为什么没有?
我们团队没有测试,也是因为前面花太多时间在学习爬虫,后面没时间写测试了,但是因为老师后期是强制要求有的测试计划,所以我们后面也花时间做了各个浏览器的页面是否正确,搜索速度,爬取速度等的测试。
2. 是否进行了正式的验收测试?
进行了正式的验收测试,相关测试都在这次写完了。
3. 团队是否有测试工具来帮助测试?
好像没有用到,只是用的自带的方法来测试。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
我们并没有测量并跟踪软件的效能,我们只有代码测试各个浏览器的页面是否正确,搜索速度,爬取速度等的测试。很有用,让我们的程序更符合大众使用的要求,改进了很多我们忽略的点。比如用户量,和各个浏览器的页面是否显示正确,和爬取速度的改进。
5. 在发布的过程中发现了哪些意外问题?
我们的前后端交互还没有解决,我们现在只能实现先爬下数据放在数据库里,然后调用搜索引擎来从数据库里寻找数据,所以没有发布
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
测试在每一次项目完成的时候都很重要,关乎一个软件是否能运行和发布的重要信息。如果历史重来一遍,我们应该花更多的时间在测试上,而不是写代码和学习爬虫上。
团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
比如雯婷和晓菲同学就是典型的专研代码攻克难关的人,PM主要负责每个人的任务完成情况,并且合理分配每次冲刺人员安排,促进项目的完成,因为也是这么久的同学,谁的实力都互相清楚,自然知道谁适合干什么,能做什么。
2. 团队成员之间有互相帮助么?
有的,当一个人遇到的一个难题很久没解决,大家会一起同时解决这个问题多出点子,解决了大家一起分享答案。当有什么不会的也会互相请教对方这个部分她是怎么完成的。
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
每当我们遇到问题的时候,先每个人完成的叙述你的想法是什么,别人先不打断,描述个人的想法,交流是最重要的,先讲道理,再辩论,如果还不行就群众投票,再不行就石头剪刀布
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
勉强能达到 第二级 可重复级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽向磨合过度。团队成员已经基本互相熟知,能够有效进行沟通,配合较好。在一些方面还缺少一定的规范。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
这个问题暂不讨论。
你觉得目前最需要改进的一个方面是什么?
最需要改进的是增加合理规范的代码管理。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
整体上来说完成度都不错,至少在成品的时候体现了简单这一原则。但在设计阶段和编程阶段,完全没有体现这一主张,设计了过多过细节的功能。其他方面没有太过突出的优势。
博客要附上全组讨论的照片。
以上是关于Alpha阶段敏捷冲刺总结的主要内容,如果未能解决你的问题,请参考以下文章