《Scrum实践中的困难、挑战与三级助力》由会员分享，可在线阅读，更多相关《Scrum实践中的困难、挑战与三级助力（62页珍藏版）》请在金锄头文库上搜索。
1、Scrum实践中的困难、挑战与三级助力李连华MSN： 新浪微薄： http:/ Sprint(4)改进社区IC,Scrum实践中的困难、挑战与三级助力,4,改进backlog,Sprint,ETC,能量支持资源引导(偶尔),改进backlog,Sprint,IC,改进backlog,Sprint,IC,障碍,简单回顾分布式团队实施,软心肠的千万不要把敏捷扩展为分布式模型。两种方式：(1)协作式同地化团队(2)有意分布团队笔者参与的，都属于同地化团队。只有在透明性存在较大问题时，才主张采取有意分布团队。走动式管理替换为飞行式管理。电话会议(如PlanMeeting),Scrum实践中的困难、挑战
2、与三级助力,5,同地化,有意分布,Scrum实践中的困难,Scrum实践中的困难、挑战与三级助力,6,1.Product Backlog管理,+ 如何演示+ 客户(用户),Scrum实践中的困难、挑战与三级助力,7,1.Product Backlog管理,Scrum China典型问题长期项目产品线技术长线,Scrum实践中的困难、挑战与三级助力,8,2.Done定义,Done是可交付的元素定义,Scrum实践中的困难、挑战与三级助力,9,Product Backlog设计可运行的软件软件运维,质量倒三角,OP与PE的故事,3.Sprint Backlog预估分为初始预估和迭代中预估两部分。
3、在一个Sprint中持续更新估计要完成一个任务所需要的(剩余)小时数。 不应该与工时报告混淆；工时报告并不是Scrum的一部分。 在Scrum中没有一个跟踪团队工作时间大小的(统一的)机制。团队是通过计划目标（交付数量）来进行度量，而不是通过达成目标所需要的时间（小时数）。Scrum是结果导向，而不是效率驱动。,Scrum实践中的困难、挑战与三级助力,10,Sprint backlog预估工具与burn down图,初始预估是所有软件研发活动的难点：实践中，一个task大小不要超过2个工作日估计采用集体智慧计划纸牌利用burn down图经验,Scrum实践中的困难、挑战与三级助力,11,抢肉
4、的故事，最乐观与最悲观估计,估算粒度,Scrum China-讨论“故事点估算优于小时估算”,Scrum实践中的困难、挑战与三级助力,12,4. Daily Scrum定时站立 标准内容准入反馈,Scrum实践中的困难、挑战与三级助力,13,有用性,不停的问自己：“我们的团队发现daily scrum的好处了吗？”如果答案是否定的，找出原因！他们是否是自管理的？他们是否分享他们的经验？他们开会之前是否有准备？他们汇报工作是否清晰？开会时间过长？等等Sprint 分析和回顾,Scrum实践中的困难、挑战与三级助力,14,5. Sprint Review,Scrum实践中的困难、挑战与三级助力,1
5、5,Sprint回顾议程,来自CST的Mitch Lacey的议程样例1. sprint目标2. 团队承诺的产品backlog条目3. 参照“done”标准团队已经实现的产品backlog条目4. 参照“done”标准团队未实现的产品backlog条目5. 已经做了的决策6. 在sprint中团队遇到的障碍7. 版本计划复审、预算消耗速度等等8. 演示和对话9. 回顾、改进、终止,Scrum实践中的困难、挑战与三级助力,16,6. 问题反馈与自优化,Daily Scrum:“我遇到什么问题”Burn Down:“速率是否正常，发生了什么”心情图Sprint Review,Scrum实践中的困难
6、、挑战与三级助力,17,发现和适应,检查考察“what”围绕产品，进行监控 、调整 与product owner和stakehoders之间建立信任从product owner和stakehoders那里得到反馈回顾考察”How”围绕过程，进行监控 、调整在经验中学习，提升沟通能力帮助team集中精力在过程的改进上,Scrum实践中的困难、挑战与三级助力,18,7. SOS Scrum Of Scrums,Scrum协同大项目scrum团队scrum关注交叉和集成领域不要天天举行不需要限定15分钟可以解决问题维护：方案&Action问题backlog主动管理依赖： (1)持续集成有助于发现(2
7、)举行发布会议(3)共享团队成员(4)使用集成团队,Scrum实践中的困难、挑战与三级助力,19,PO,Team,Master,scrum,scrum,Scrum带来的根本性挑战,Scrum实践中的困难、挑战与三级助力,20,.每月都能交付一个产出将会在整个组织里引起连锁反应,Scrum实践中的困难、挑战与三级助力,21,Scrum,团队的功能化与专业化,跨职能的特性(功能)团队，是scrum所推崇的。专业化的组件团队，是scrum主张避免的。不是按照组件来组织团队结构，而是让项目中的每个团队理想地负责一个可工作特性的端到端的交付，这是一个更好的方式。 这些都是令人很痛苦的问题。 但保守的使用
8、组件团队，在实际的 经历中，专业化(组件)团队共享是 不错的方式。,Scrum实践中的困难、挑战与三级助力,22,问题：(1)学习成本？(2)人员成长？(3)职业发展？(4)专家资源？,组织角色,SCRUM与很多传统的组织角色及其职责有冲突。项目经理会消失吗？直线经理问题列表教练、老师、导师其他角色切记，这是一些人的个人前途和职业的变化！这是困难的，有时甚至痛苦。,Scrum实践中的困难、挑战与三级助力,23,问题列表,在sprints中，将发现软件可以优化和改进的问题列表。,Scrum实践中的困难、挑战与三级助力,24,管理层的工作是确定优先级，系统地解决这些问题。这是非常困难的工作,公司组
9、织架构与升迁路线,矩阵式管理,Scrum实践中的困难、挑战与三级助力,25,scrum,scrum,人力资源与绩效评估,Scrum实践中的困难、挑战与三级助力,26,当今的绩效管理，是针对个人的。个人的贡献，个人的作用，个人的成长，已经是激励的核心。企业，本质上喜欢个人的责任胜过小组。虽然，scrum更重视衡量团队，衡量团队的贡献度。但是，这与绩效管理是需要阵痛中寻求融合的。实际实践过程中，基本上都是在结合团队评价与个人评价的方式。,人力资源与绩效评估,Scrum实践中的困难、挑战与三级助力,27,人的发展,一个更加本质的问题是，人的发展问题。传统管理学中，给予两条发展路线：(1)技术长线(2
10、)管理级别与汇报人数但在自组织团队中，这两条发展路线都是需要重新审视的！有两个行业对照案例：,Scrum实践中的困难、挑战与三级助力,28,点餐员,厨师,流动工,前锋,门将,中后卫,为球队名字而不是t恤号码踢球,兼容不确定性,在某些行业，尤其是在互联网和研究性内容为基础的领域，有较多“需求”是不确定的，例如，UED难以确认用户习惯，算法策略难以确定方案和效果。双线scrum是一种尝试。,Scrum实践中的困难、挑战与三级助力,29,实施,Sprint0UED/算法,sprint1,UED/算法,实施,sprint2,UED/算法,兼容各种方法论,Scrum与瀑布：瀑布在前、瀑布在后、瀑布两头兼
11、容ISO9001/CMMI监管：是了解项目的需要，不同于项目管理。从product backlog和burn down图入手。文档：文档只要是为了记录沟通而不是为了交接工作而编写的，就不是罪恶的。,Scrum实践中的困难、挑战与三级助力,30,Scrum,-Product Backlog-任务墙/Burndown图-工程实践-过程可视化,过程可存档、监控、优化(标准流程)ISO9001/CMMI,在此处融合,重要的是持续推动,Scrum实践中的困难、挑战与三级助力,31,Scrum持续推动,Scrum实施就如火箭发射，想要到预定轨道，则需要不断克服自身“企业重力”，持续推动。企业重力：职位与交
12、接文档与流程控制力成就与评价体系行政三级助力：敏捷意识工程实践实践社区,Scrum实践中的困难、挑战与三级助力,32,Scrum第一级助力敏捷意识,Scrum实践中的困难、挑战与三级助力,33,敏捷意识,在敏捷角色中，最大的问题是,Scrum实践中的困难、挑战与三级助力,34,只要告诉我做什么，我就会做它！Eg.给我需求文档，我来设计。Eg.给我设计文档，我来测试。Eg.文档有误，导致我工作失败。Eg.开发代码质量不高，所以测试工作延期。,PO,TeamRD,Master,TeamQA,TeamUE,敏捷意识,敏捷最大、最持久的困难是敏捷意识的建立和形成。敏捷的基本意识的基础：(1)我是团队的
13、一员，我们为交付物负责。(2)反馈并调整。(3)自组织，自优化。,Scrum实践中的困难、挑战与三级助力,35,敏捷意识,自组织不等于随意组合：自组织能力是敏捷方法论的根本。最好的架构、需求和设计出自自组织团队。自组织团队，需要考虑多样性、持久性和平衡性(专业、等级、领域知识)。 = + +,Scrum实践中的困难、挑战与三级助力,36,自组织团队,容器(边界条件),差异,交流,调整,放大/减小,变换方式,建设者,重读敏捷宣言,我们认为：个体和交互 胜过 过程和工具。运作的软件 胜过 面面俱到的文档。客户合作 胜过 合同谈判响应变化 胜过 遵循计划虽然右项也具有价值，但是我们认为左项具有更大的价值。,Scrum实践中的困难、挑战与三级助力,37,一个实际案例,一个同学记录的经验图,Scrum实践中的困难、挑战与三级助力,38,UC提交QA延期,X日,Y日,现象：UC交付内容遗漏，重新提交(rank.so缺失)。 QA打回，邮件正式付诸质量。开发人员异议。经验： (1)硬性 交付done定义 。 反馈+持续改进。 (2)软性 不是相互给压，而是相互给力的团队默契。 团队，双赢。,size,另一个实际案例,Scrum ChinaQA角色与团队讨论,Scrum实践中的困难、挑战与三级助力,39,建立敏捷意识,改变，由意识开始。改变，必须由内而外。这是一扇从里向外开的门。,
