——框架背后的原则及实施过程不良症状分析费下

1、Scrum框框架架及及其其背背后后的的原原则则（下下） 框框架架背背后后的的原原则则及及实实施施过过程程不不良良症症状状分分析析本文在上半部分以伪代码的形式讲述了 Scrum 的基本框架，图（一）是对该框架的总结。如此简单的框架如何能提升组织的能力？做到什么才能保障 Scrum 实施的成功，并从中受益？理解和贯彻 Scrum 框架背后的原则是关键。相关相关厂商厂商内容内容Web App 应用开发者大会报名（应用开发者大会报名（5.17 成都成都 免费报名中！）免费报名中！）Scrum 认证培训及敏捷教练认证培训及敏捷教练UPerform 优普丰优普丰Adobe Flash Builder 4 简体中文正式版高速下载简体中文正式版高速下载图（一）图（一）Scrum 总体框架总体框架 PPT 格式大图下载链接格式大图下载链接为了说明这些原则与 Scrum 框架的对应关系，在图（一）中我们以 Scrum 框架为索引，列出了相对应的原则(见图中蓝色框)，它们分别是：1. 产品开发过程相关的原则o 高度透明o 不断反馈调整2. 团队组织相关的原则o 多功能o 自组织3. 持续改进相关的原则o 将

2、改进嵌入开发过程o 不断暴露和解决问题以下我们将分别对这三个方面原则进行讨论，并就每个方面分析 Scrum 实施过程中的不良症状。产产品品开开发发过过程程Scrum 是一个经验性(empirical)的过程，透明（transparent）、检验(inspect)和调整(adapt)是它的三个支柱。Scrum 的产品开发过程是高度透明和不断反馈调整的自适应过程。需要特别强调的是，与传统开发过程相比，Scrum 引入了一个根本性变化 在每个固定长在每个固定长度的迭代周期（度的迭代周期（spirnt）产出潜在可交付的产品增量（）产出潜在可交付的产品增量（potential shippable product incremental - PSPI）。这是透明、检验和调整的基础，能否做到这一点是 Scrum 实施成功与否的试金石。Scrum产产品品开开发发过过程程应应该该做做到到高高度度透透明明透明是团队合作信任，以及对产品开发过程进行检验、调整的前提。为了做到真正的透明，Scrum 开发过程中影响到最终结果的各个方面都应该是可见和可信的。在 Scrum 实施过程中要做到：a) 遵循共同的框架遵

3、循共同的框架共同的迭代和增量开发框架为开发过程的透明提供了统一的基准，Scrum 框架下的制品（Artifacts）是高度透明： Product backlog 反映了用户需求，以及它们的开发工作量、优先级和当前状态； Sprint backlog 反映了 sprint 的目标、工作任务和当前状态； 发布燃尽图反映了项目的整体工作进展状态； Sprint 燃尽图反映了当前 sprint 的进展状态Scrum 的四个标准活动（event） sprint 计划会议、每日 Scrum 会议、sprint 评审和sprint 回顾进一步促进了透明。b) 信息真实可信信息真实可信透明的信息为 PO 和团队提供了决策依据，信息可信与否直接影响决策质量的高低。敏捷开发的透明性内建于开发活动当中，保证了其真实可靠。这些信息，即时从版本层面、迭代层面和日常工作层面，反映项目的最新状态。信息的可信还体现在，对相同信息的一致理解。例如，当声明一个需求已经完成时，PO 的预期应该和团队的理解应该是一致的，这就是完成标准定义（Defintion of Done - DoD），它必须清晰明确，并被严格遵循。c)

4、以最高效的方式及时沟通信息以最高效的方式及时沟通信息良好的沟通促进透明。团队坐在一起，面对面的交流是最高效的沟通方式；有效的会议组织能改善计划、评审以及回顾活动的效果；一个良好的可视化工作空间（如白板墙等），可以促进信息的发布和交流，具体可参见借助信息化工作空间实现高效的团队自我管理。总之，采取一切可能的手段改善团队内部以及团队对外的沟通。d) 持续交付带来最可靠的透明持续交付带来最可靠的透明向客户交付产品，可以让团队得到最直接和真实的反馈，可运行的软件不会撒谎。受产品特性和团队成熟度的限制，并不是所有的团队一开始就能做到每个 sprint 向客户交付软件。但团队应努力让迭代的结果更接近交付的标准，并力争更频繁的实际交付，每一次交付都是对产品开发成果和团队过程能力的检验，。Scrum开开发发过过程程中中应应该该不不断断反反馈馈调调整整在传统开发过程中，团队根据目标制定计划，而后严格按照计划执行以达成目标，这是所谓定义性的开发过程。然而计划可能不合理，执行过程可能出现偏差，这都会使结果偏离预设的目标。即使计划被完美的执行，目标本身也会发生迁移，实际的业务目标和最初的设想总会有差距。如图（

5、二）所示，定义性的开发过程对于软件开发这样复杂的活动并不适用。图（二）定义性的开发过程图（二）定义性的开发过程Scrum 倡导“经验性”的开发过程。如图（三）所示，在开发过程中团队不断检查和汲取反馈，调整下一步的行动，动态达成目标。经验性的开发过程让团队在复杂的市场和技术环境中更好的把握和实现业务目标，取得竞争优势。为实现有效的调整和反馈，组织要做到：图（三）经验性的开发过程图（三）经验性的开发过程a) 周期性的检验和调整周期性的检验和调整Scrum 框架中包含多个检验和调整的反馈循环。每日 Scrum 会议上团队检验工作进展，和sprint 目标进行比较，调整接下来的工作以更好地达成目标；Sprint 评审会议上，团队演示软件，获取业务人员和客户的反馈，及时调整产品的方向以及开发计划。通过不断的检验和调整，团队和客户持续修正产品开发方向和计划，更好的实现商务目标。b) 业务人员更紧密的参与开发过程业务人员更紧密的参与开发过程不管业务人员还是用户，都不可能在项目一开始就准确无误地把握产品方向和定义完整的需求，它们需要在开发过程中不断的被修订、调整和完善。如果，业务人员不参与到开发过程当

6、中去，在项目结束时就可能会出现“团队开发的产品和业务人员的定义不符”，或者“团队开发的与当初业务人员所定义相符，但却不是业务人员和市场需要的产品了”。业务人员参与开发过程，一方面团队能够及时获得对产品目标和需求的澄清和确认，确保双方的理解一致；另一方面，通过参与开发过程，业务人员更准确地理解客户需、把握产品目标，并做出及时的调整。针针对对开开发发过过程程的的不不良良症症状状分分析析excel 版本下载团团队队组组织织通过 Scrum 开发过程的实施，组织更快的交付价值，更灵活的适应变化。同时，Scrum 的实施对团队组织提出了新的要求。典型的 Scrum 团队应该是多功能和自组织的。团团队队应应该该是是多多功功能能的的多功能是指团队具备为客户提供端到端服务的全部技能，对于 Scrum 团队这意味着有能力完成从需求分析到交付产品的所有工作。如果团队为了完成一个工作要严重依赖其它部门，就无法实现真正的短迭代交付；同时，因为团队仅凭自身的努力无法获取期望的结果，就会缺乏对目标的认同和责无旁贷的责任感，也会缺乏改进的动力。为了做到团队的多功能，组织需要：a) 创建跨职能和跨组件的团队创建跨职能

7、和跨组件的团队跨职能指团队具备承担系统分析、架构、设计、开发和测试等工作的全过程能力；跨组件指团队具备完成开发工作所需各个组件的知识，如 UI，中间件，底层驱动等。b) 拓展团队成员的知识技能拓展团队成员的知识技能需要指出的是，多功能的团队并非指团队中的每一个人都具备所有技能，这在操作上是不实际的。Scrum 对团队成员的技能要求倾向于通才型的专家（Generalizing specialist）。团队成员具备通用软件开发知识、业务领域知识、和自己的业务专长，同时应积极寻求拓展自己的技能。这有助于成员产生更全面的思考，促进团队的协作，以及消除开发过程资源的瓶颈和等待，增加开发过程中的灵活性等。c) 团队应长期存在团队应长期存在一个团队从成立到高效运作需要一个过程，能力的拓展、团队的磨合、技术实践的优化、基础设施的完善都需要时间。通常建议 Scrum 团队尽可能长期存在，而不是随着特定项目或开发版本成立和解散，长期存在的团队才有长期的承诺，形成对目标的认同和坚持，并激发不断改进的动力。Scrum团团队队应应该该自自组组织织的的自组织团队是指，由团队而不是管理者决定“怎么做”。Scrum

8、团队被赋予并承诺组织目标，计划、执行和监控的职责则属于团队。因决策权力的充分下放，自组织团队能够对现状做出准确和及时的响应，并最大程度发挥团队成员能动性。但，简单地对一个团队说：“从今天开始，你们就自组织吧”，不会带来期望的结果。自组织的团队的形成需要：a) 有意义和挑战的目标有意义和挑战的目标有意义的目标可以协调团队成员努力方向，增加团队的凝聚力。一个通过努力可以达成的目标可以激发团队的激情和能动性。b) 自主完成目标的潜在能力自主完成目标的潜在能力团队有了目标，还要有与之匹配的潜在能力配置。多功能团队是自组织的前提，团队的长期性则保障了能力拓展和提升的可持续性。c) 明确的边界明确的边界团队的自组织需要特定的边界。没有边界约束的自组织，很难确保其在执行上与组织目标的一致。Sprint 周期是时间边界；Product Backlog 是范围的边界；DoD 是质量的边界。边界的存在让自组织更有序的发生，边界既是对团队的约束，也是对外界干扰的约束。有了边界的约束，可以建立外面的人对团队的信心和安全感；团队则在边界之内充分自主。d) 良好的组织环境支持良好的组织环境支持组织环境之与团队，就

9、像土壤之与种子。团队的自组织离不开良好组织环境的支持。面向团队而非个人的奖励和认可机制、面向结果而非过程的绩效体系、简单扁平的组织结构、以及充分的授权机制，都为团队自组织提供了良好的土壤。针针对对团团队队组组织织的的常常见见不不良良症症状状分分析析持持续续改改进进对开发过程本身的持续改进是 Scrum 的一部分，Scrum 实施能更好地暴露组织中存在的问题，解决这些问题是 Scrum 成功实施的保障，也是组织能力提升的关键。将将改改进进融融入入开开发发过过程程检验和调整针对的不仅是产品，团队还应经常对开发过程本身进行检验和调整，持续改进是Scrum 框架的有机组成部分。如图（四）所示，下面的实线框内是对所开发产品的检验与调整，这一持续循环的目的是使最终的产品更好的符合实际目标；上面的虚线框内是对开发过程的检验与调整，其目的在于不断提高团队的过程能力，和长期交付的能力。图（四）图（四）Scrum 中的两个调整与检验循环中的两个调整与检验循环影响过程能力的要素很多，如团队协作方式、开发流程、技术实践、基础设施等。每个 sprint的回顾会议都应对以上要素进行反思和调整，为保证 sprint 回顾及其后续活动的有效，团队要做到：a) 让团队成员，积极参与改进的过程让团队成员，积极参与改进的过程“retrospective prime directive”是回顾会议的基本指导原则，它明确的指出，回顾是为了改进开发过程，而不是针对任何个人。一个被少数人主导的回顾会议，很难达到期望的效果，创造一个安全开放的氛围，让每一个人都积极参与改进过程，是确保其有效的前提。尝试不同的形式来组织回顾会议的进程，也有助于提高成员参与的积极性，Agile Retrospective 一书提供了丰富的回顾会议的组织形式。b) 每次聚焦有限的改进项目每次聚焦有限的改进项目一次改变太多的东西是不现实的，会导致分析不够深入彻底，执行的效果打折。每次聚焦一到两点，集中力量，积累小的改进成果。c) 找到深层次的原因找到深层次的原因就问题解决问题是不够的，多问几个为什么，挖掘问题背后的本质原因，这样的改进才是彻底和长久的。d) 产生具体可执行的行动方案产生具体可执行的行动方案光发现和分析问题还不行，要制定切实可行的方案。方案必须是具体和可执行的，可以落实到人，而不是仅停留

《——框架背后的原则及实施过程不良症状分析费下》由会员xzh****18分享，可在线阅读，更多相关《——框架背后的原则及实施过程不良症状分析费下》请在金锄头文库上搜索。