您好,欢迎光临本网站![请登录][注册会员]  
文件名称: 我们这样实践Scrum开发
  所属分类: 其它
  开发工具:
  文件大小: 261kb
  下载次数: 0
  上传时间: 2019-03-17
  提 供 者: weixin_********
 详细说明: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、在挂纸板上写上最重要的事情 下面是个小时的回顾会议的时间分配建议: 在挂纸板上写上我们的成功经验是什么 起步 % 分钟 、在排纸板写上.有什么能够改进和谁负责,然后共享信息 分钟 分成内个区域:团队和公司 成功经验,发现问题,改进方法 分钟 每个人用贴纸写出、张贴、讲解“最重要的事情”、决定如何改进 分钟 成功经验”、“需要改过”,限制在分钟完成。然结束回顾会议 分钟 后将后两者确定“谁负责”,再排定优先级 经验分享 每个与会者对会议做简短的总结 如果某一个或多个成员非常被动的发言,可将分为若干个小组,如人一个组,有 将“需要改进”的部分增加到障碍 个活跃些 我们的 实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考 第页共页 (袁斌) 实践者,博客 邮箱: 手机 尝试回顾会议由团队所有成员轮流主持 或者有重大决议的 的回顾会议,建议领导( )参加,这样领导会 了解团队重大决议的背景,并为领导支持这些决议提供沟通基础。半时的 的回顾会议 领导不需要参加,因为领导往往会不自觉的主导会议,而且团队成员发言会有所顾忌 每个人发言吋,不用我或者我们作为主语,如果要涉及某个成员的功能、代码等问题, 最好是用问题本身作为讨论,而不是将你、你们加上。例如,如果你说 你实现的登求功能太多,以至,建议改为登录功能的太多,让我们看一下问题 在哪里。 我们的实践更加符合我们项目的场景,包括客户、公司、团队的实际情况。仅供参考 第页共页
(系统自动生成,下载前可以参看下载内容)

下载文件列表

相关说明

  • 本站资源为会员上传分享交流与学习,如有侵犯您的权益,请联系我们删除.
  • 本站是交换下载平台,提供交流渠道,下载内容来自于网络,除下载问题外,其它问题请自行百度
  • 本站已设置防盗链,请勿用迅雷、QQ旋风等多线程下载软件下载资源,下载后用WinRAR最新版进行解压.
  • 如果您发现内容无法下载,请稍后再次尝试;或者到消费记录里找到下载记录反馈给我们.
  • 下载后发现下载的内容跟说明不相乎,请到消费记录里找到下载记录反馈给我们,经确认后退回积分.
  • 如下载前有疑问,可以通过点击"提供者"的名字,查看对方的联系方式,联系对方咨询.
 输入关键字,在本站1000多万海量源码库中尽情搜索: