我们这样实践Scrum开发NULL 博文链接：https://agiledo.iteye.com/b

文件名称: 我们这样实践Scrum开发

所属分类: 其它

开发工具:

文件大小: 261kb

下载次数: 0

上传时间: 2019-03-17

提供者: weixin_********

下载 (261kb)

不能下载？报告错误

详细说明：NULL 博文链接：https://agiledo.iteye.com/blog/558517(袁斌) 实践者,博客邮箱: 手机阶段推荐做法(部分摘自 Scrum checklist) 我们的实践 1.角色:高级软件工程师、架构师、美工、QA、第三方技术支持 2.最关键特性:必要的技能、沟通意愿、对结果负责 3.我们尝试∫团队完全由高级软件工程帅组成,质量由工程帅负责,结果非常不好,一个是质量差,另一个是没有很好的技高手,设计必要的前瞻性和技术难点经常困扰。后来增加了架构师,增加了编码沇程,部分解决了第二个问题和第·个问题中的代码质量,但功能质量还是不能保证,例如边界、各种异常、非关键的正常流程往往被忽略。于是增加了QA。此时的流程是: Daily build,开发人员根据功能最要的验收测试后发布在测试平台上,巾QA进行测试。这样QA做 Story增量测试,同时逊可以兼仼部署的工作。但我们还是有问题无法解决, 例如CMS、Ajax技术难点、整体网站优化,这样需要更加专业的技术服务,我们和一些专业公司签署技术服务协议,包括外包、现场支持等 1. Cross- functional团队 4.最核心的是人,所以选人是第一步的,如果已经入职的人员不合适,磨合仍然不能符合团闭队建设2.self-0 rganization 队要求,尽早让其离开闭队,调整到公司的其它岗位。我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机参加者: 前提:已经准备好,可以是故事,也可以是 ,但往往不会提供, 也不追究,可以要求提供需求来自哪里(直接客户、老板、市场销售部门产品部、技术部门),这个在现实中成为优先级的排列依据。的没有任何书面的细节。包含了业务需求、上一个遗留的技术部门提出的技术需求(开发环境的搭建、基础架构的实现等) 过程:介绍需要评估的所有背后的用例,仅是要的正常流稈即可各成员首先选择最小用例的 ,指派其工作量为,然后针对每一个和的工作量比较,我们是用为评估方法,直接用任何近似的比例,例如可以认为是也可以认为是(我们也在同时尝试用评估卡片的数值,正在看不同的效果)。大家同时亮出什算比例,分歧最大的成员进行讨论。对」任何和现有功能依赖关系很弱的功能或者团队成员对参加者整个系统都很熟悉,最多讨论两轮,根据最后所有人的平均值作为佔算比例,这些功能可以巾前提: )已经排列好优先级,故事点评估团队中的饪何人实施;对于团队中少数人了解的功能或者技能(双机热备等),主要由这些人卡片(, ,,,,)为每一进行评估,并给出理由,其他人给出一些辅助意见,同时这些功能也主要由这些人完成。大家个团队成员准备好。当然,1 deal day也是另外一种评评估最小用例的,然后按照估算比例计算其他故事的最后将估算结果添加到估方法中。如果先介绍完成员经比较清楚,工作量的袢估可以不参加。过程:介绍需要评估的背后详细的用例,参加的好处是透明的过程增加双方的信任感。用的最人原因是、管理层需要明确的估各成员首先选择最小用例的 ,指派其工作量为,算时间然后针对每一个和的工作量比较,同时亮形成期望的日标,这个日标是根据业务优先级以及在评估会议上得到的出评分卡片。如果有分歧,分歧最大的成员进行讨论,的评估值由综合次定。此时提供期待目标中足够的信息,并以文档的然后冉次投票,知道所有人意见一致为止。将评估结果形式发给团队。例如报表需求,足够的信息包括,通过哪些查询条件,得到什么查询结果,查添加到中询条件和杏询结果中的字段定义交付物:更新后的通知所有参加会议的人员交付物:更新后的通知所有参加会议的人员评估会议持续时间:无推荐持续时间小时我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机明确的时间表,这个一般确定在,但是也会因为客户的要求或者市场的要求而改变。例如我们的客户一般要求每月的第一天开始部署新的程序,此时我们的周期为个自然月;如果我们的市场宣传需要个配合(天后),那么周期会定在天。日标只有一个:提供价值会向团队介绍半年之内的这个团队非常关心,因为可能涉及到设计等;对于产品的远景,团队会听一听,但不会特别关心,有时候就不会涉及产品的远景。如果有的话,或者开发闭队増加认为遗漏的问题,并调整优先级。如果这些问题有在期望的目标内的,团队需要评估工作量,否则可以留在下一次的评估会议再评估向团队介绍期望的日标。介绍各个背后的用例,包括正常流程、异常流程。此时团队有任何细节问题都可以向提问以获得答案。界面原型也是讨论的一个方面。由项目经珄进行整理、记录。以报表为例,此肘就增加了如何排序等细节明确的时间表以上持续时间:小时, 向团队阐述产品的远景团队根据项目经理的整理资料,再回顾·次背后的用例,有不确定的地方和如果中有问题遗漏,可以向中讨论。同时完成各个功能的最主要验收标准增加问题,并重新排列优先级持续时间小时计划会和团队一起确定目标交付物:明确的周期和的用例资料,我们的資料包括文字描述的正常、异议持续时间:小时常流程和手工界面原型照片我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机按照目标中的各项功能分出相应的任务,确保考虑到工作中两个关键的细节:编码测试如果任务需时超过一天,尝试将此任务分解为几个小任务,任务的分解周期是小时如果有多个任务非常小,例如修改,可以几个合在一起作为一个较大的任务。任务完成按照日标中的各项功能分出相应的任务,硝保的时间是在以没有任何外界干扰为前提,例如额外的技术支持等考虑到工作中所有的细节:编码、测试,代码评审、会通过分解任务判断功能()最后的工作量评估。同时团队反馈本周期内可用的议、学习新技术、编写文档等资源(),乘以资源利用率(需求细化的稈度、写文档的时间、会议、技术支持等因素), 如果任务需时超过一天,尝试将此仁务分解为几个小就是本内团队可以完成的工作量。用这个工作量去和目标中包含的的任务工作量比较,多删少补,以达到和团队都认可的日标通过分解任务判断功能()最初评估的工作量功能已经初步落实到人(若干人)。即具体的人(若干人)对功能负责,而不是对任务负是多是少,如果过多评估,则和一起增加责。关键的里程碑也已经确认,目的是让团队所有人对项目的进展有总体的把到中,否则删减握。计划会团队确认目标( 团队确认目标( 议持续时间:~小时持续时间:~小时参与人:团队、 (可选)、相关人员(可选)参与人:团队在上的所有仁务都是可以增删修我们每天都会有这个会议(:开始),一殷在分钟左右。每天会在分钟左右改,可重排序的任务的状态可设为“待处理”,“正在这样的会议我们会每次轮换人展示其最核心的一段代码(不超过行),大家来处理”,“已完成”的包括业务逻辑、异常处理等。会议限制在分钟,团队每人回答三个问题每大的会议,对任务的处理都在口头上(除∫可以直接移动任务),由会后整理、更上次会议时的任务哪些已经完成新白板,否则时间会很紧张。具体的白板信息,见图。说明一点:在回顾公议中人家对3周把任务从“正在处理”状态转为“已完成”状念的很多细节不能完全回忆,会议的过程不够深入,所以决定在白板中增加一项:GB,God 下一次会议之前,你计划完成什么任务? Bad、Ugly,即在 Sprint内无论是技术、沟通、管理各个层面,团队的任何人任何时候都可以如果仟务状态为“待处理”:转为“正在处坦”状在这一项中添∥自己的意见,这样在回顾会议中,甚至在开发过释中,我们都可以反思、提高态我们的沇程如果任务不在上:添加这个任务.每天的会议,除了说这三件事,我们把它作为整个团队共享信息的机会,例如某个功能细如果仁务不能在一天内完成:把这仁务细分成多个节和确认,说给大家听;有一个技术突破,说给大家听。只是的层面,如果任务谁有兴趣,可以下来细谈每日例会如果仟务可以在一天内完成:把任务状态设为“正所有人都会准时参加,因为公司做了考制度,次迟到了会扣除当日工资的% 我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机在处理” 有什么问题阻碍了你的开发如果任务状态已经是“止在处理”:询问是否存在阻碍任务完成得问题,如果有阻碍你开发进度的问题:把该障碍加入到障碍如果展开了一个问题的讨论提醒团队的成员们注意把精力集中在回答关键问题上如果相关人员想发表些言论: 礼貌地提醒他,该会议只允诈让小组成员讨论交付物:障碍、最新的最新的工作进展图我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机参与者:、、团队过程在体系中,每一个之后都会做一个演示(),以获得的反馈。在实践中,我们发现如果只在之后再做由于过程中沟通不充分, 展示的功能很可能不符合客户真正的需求,导致失败。于是,我们: 将内的 )按照耦合的程度分为几个组每一个组完成后会部署在开发平台上进行测试,此时的测试首先是的初步测试,保证可以正常运行;然后是的验收测试,保证功能没有偏离需求当第二个组的完成后,会进行整合测试在之后,再进行整体的好处仨何偏离需求的风险在期间的非止式吋被发现,得到及时处理组是按照优先级排序的,先做的是最高优先级,那么如果发生了任何意外(例如人参与者:、、团队员变动、技术障碍等)无法完成所有的那么高优先级的可以在结束团队按中的问题,逐个地介绍这次前被提交的结果,和演示新功能。如果产品负责人想要改变功能:添加个新问题到产品我们做会坚持以下原则中只是演示本次内的功能如果对功能有一个新的想法:添加一个新问题到产品演示过程中, 提出的意见,在演示会议中不做讨论,只是做记录,在会后再中进行沟通如果小组报告项目遇到阻碍现在还没能解决:把该障碍保持时间控制在分钟加入到障碍一个人完成所有的演示评审会交付物:对这次的结果和整个产品的开发状只演示己经完成的功能。除非要求,否则不展示未完成的功能。因为只有已议(验收)态的共识经完成的功能才是可以给客户带来价值的。我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机起步: 介绍会议的持续时间、目标、步骤、会议规则持续时间:小时:日标:下一个我们改进的具休措施步骤:共享信息、找出成功的经验,发现问题,提出改进意见、决定如何改进会议规则:每个人都要发言,表决的时候所有人同吋进行共享信息目的是为了建立所有人讨论的基础,可能有人生病了,可能有人只做自己的功能,不是所有人对整个有全面的了解。这些信息包括:开发过程中枚事的完成情况、新增技术、改事变更、资源变更、个人的建议、公司的政策变化等等。由于白板只能记录每日的情况, 所以我们在实践中在白板中增加了一些区域记录这些信息,见图参与者 (可选) 团队找出成功的经验,发现问题,提出改进方法附属T具:为所有参与者准备的荧光笔、贴纸、红色和每个人写出最成功的三个经验,贴在自板上绿色的白板磁吸、白板和挂纸板在中确定优先级最高的个问题(优先级由团队确定),大家来发堄原因,然后提出改进在挂纸板上写上上要指导原则上要指导原则:不管我的方法。最好要列出更多的原因和改进的方法。往往第一个原因和改进的方法是表层的,深入们现在发现了什么问题,我们必须懂得并坚信每个人通的讨论才能找到深层的原因和根本的改进方法。过他们当时所知的,他所拥有的技能和可得到的资源,決定如何改进在限定的环境下,都尽其所能做出了最好的成绩在改进的方法中找到团队认为在下一个中可以实施的改进方法。如果是公司负责的, 在挂纸板上上一个全少三贞纸连在一起长的时间则由记录后和、管理层沟通轴,标记出的开始和结束时间结束回顾会议:将会议的结论记录在案,发给所有的参与者 a、在挂纸板上写上最重要的事情下面是个小时的回顾会议的时间分配建议: 在挂纸板上写上我们的成功经验是什么起步 % 分钟、在排纸板写上.有什么能够改进和谁负责,然后共享信息分钟分成内个区域:团队和公司成功经验,发现问题,改进方法分钟每个人用贴纸写出、张贴、讲解“最重要的事情”、决定如何改进分钟成功经验”、“需要改过”,限制在分钟完成。然结束回顾会议分钟后将后两者确定“谁负责”,再排定优先级经验分享每个与会者对会议做简短的总结如果某一个或多个成员非常被动的发言,可将分为若干个小组,如人一个组,有将“需要改进”的部分增加到障碍个活跃些我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页 (袁斌) 实践者,博客邮箱: 手机尝试回顾会议由团队所有成员轮流主持或者有重大决议的的回顾会议,建议领导( )参加,这样领导会了解团队重大决议的背景,并为领导支持这些决议提供沟通基础。半时的的回顾会议领导不需要参加,因为领导往往会不自觉的主导会议,而且团队成员发言会有所顾忌每个人发言吋,不用我或者我们作为主语,如果要涉及某个成员的功能、代码等问题, 最好是用问题本身作为讨论,而不是将你、你们加上。例如,如果你说你实现的登求功能太多,以至,建议改为登录功能的太多,让我们看一下问题在哪里。我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考第页共页

(系统自动生成,下载前可以参看下载内容)