敏捷开发全景视图（流程、方法和最佳实践）
•
40 likes•8,731 views
The Whole Picture of Agile Development -- Process Frameworks, Methodologies and Best Practices
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to 敏捷开发全景视图（流程、方法和最佳实践）
Similar to 敏捷开发全景视图（流程、方法和最佳实践） (20)
More from Weijun Zhong
敏捷开发全景视图（流程、方法和最佳实践）
- 2. • 现任： – 北京车网互联科技有限公司 （资深架构师） • 历任： – 卓望科技股份有限公司（飞信系统架构师） – 诺基亚西门子科技股份有限公司（开发工程师&Team Leader） – 中国电信（网络运行管理工程师） • 专注于： – 研发管理、产品流程 – 系统架构、敏捷开发、需求分析、领域驱动开发 • 兴趣领域： – 企业架构方法、团队管理 关于作者
- 3. 目 录 Contents 敏捷 vs 传统 敏捷开发流程框架 敏捷方法和最佳实践 思考与答疑
- 4. 敏捷 vs 传统
- 5. IT项目管理方法的发展历史 1960 1970 1980 1990 2000 2010 SDLC WATERFALL RAD PMBOK ITIL PRINCE Zachman DSDM RUP XP PRINCE2 CRYSTAL SCRUM AGILE MANIFESTO FEA TOGAF 8.0 LEAN KANBAN
- 8. 传统软件开发模式存在的问题 • 传统软件件开发过程的常见症结 – 交付周期长；害怕需求变更；中间过程不可控；测试周期被 一缩再缩；最终结果差强人意 – 与“唯快不破”的互联网经济格格不入
- 9. • 敏捷软件开发模式 – 由传统迭代式软件开发模式发展而来，Time-Boxed – 抛开传统软件开发模式的繁文缛节，强调产品价值、团队协作、客户参 与、先期验证、简化流程、拥抱变化 – 总结吸收成功软件项目研发的最佳实践；与现代管理思想相辅相成 – 前期有学习成本，后期会获益匪浅 敏捷软件开发模式 Source: Forrester Research, Inc.
- 11. 敏捷开发带来的好处 TOP 5 reported benefits: Improved quality (56%) More opportunities for mid- course corrections (56%) Overall improved customer and business satisfaction (38%) Better business-IT alignment (37%) Improved time to market (32%) A lot more than velocity 质量改善 利于中途修正 总体改善客户和业务的满意度 商业需求与IT实施更加匹配 更快投入市场 Source: 2013 Forrester Research, Inc.
- 12. 敏捷开发宣言 • Manifesto for Agile Software Development – Individuals and interactions over processes and tools 人和交互 重于 过程和工具 – Working software over comprehensive documentation 可以工作的软件 重于 面面俱到的文档 – Customer collaboration over contract negotiation 客户合作 重于 合同谈判 – Responding to change over following a plan 随时应对变化 重于 遵循计划 • 虽然右边也有其价值，但我们认为左项更加重要
- 13. 敏捷原则 (Agile Principles) 1. Satisfy the Customer 2. Welcome Change 3. Deliver Frequently 4. Work as a Team 5. Motivate People 6. Communicate Face-to- Face 7. Measure Working Software 8. Maintain Constant Pace 9. Excel at Quality 10.Keep it Simple 11.Evolve Designs 12.Reflect Regularly
- 14. 敏捷开发价值观 • 专注：由于我们在一段时间内只专注于少数几件事情，所以我们 可以很好地合作并获得优质的产出。我们能够更快地交付有价值 的事项。 • 公开：在团队合作中，大家都会表达我们做得如何，以及遇到的 障碍。我们发现将担忧说出来是一件好事，因为只有这样才能让 这些担忧及时得到解决。 • 尊重：因为我们在一起工作，分享和成功失败，这有助于培养并 加深互相之间的尊重，并帮助彼此成为值得尊重的人。 • 承诺：由于对自己的命运有更大的掌握，我们会有更坚强的信念 获得成功。 • 勇气：因为我们不得单打独斗，我们能够感受到支持，而且掌握 更多的资源。这一切赋予我们勇气去迎接更大的挑战。
- 15. 从传统到敏捷：思维的转变 形而上者谓之道，形而下者谓之器。 形而上者起于学、行于理、止于道，形而下者起于教、行于法、止于术。 • 从重视“流程”到重视“原则” – 道本器末，不忘初心 – 做正确的事比正确地做事更重要 • 如何看待流程、方法、最佳实践在敏捷开发中的作用 – 无其器则无其道，器和道一样重要 – 上善若水，原则的“刚性”和流程的“柔性”
- 16. 从传统到敏捷：认识误区
- 19. 敏捷开发流程框架
- 20. 产品研发：一个持续的过程 Management is doing things right; leadership is doing the right things. (Peter Drucker)
- 22. Scrum框架：简介 • Scrum – 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在 这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称 为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的 Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个 按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品 Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经 过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个 迭代结束时，Scrum团队将递交潜在可交付的产品增量。Scrum起源于软件开发 项目，但它适用于任何复杂的或是创新性的项目。 • 要素： – 周期：Product Release<=Time-Boxed Sprint<=Daily Continous Delivery – 团队：Product Owner，Scrum Master，Dev Team(Cross-Functional) – 工件：Product Backlog，Sprint Backlog，Product Increment – 活动：Sprint Planning Meeting/Review Meeting/Retrospective Meeting，Daily Scrum Meeting，Product Backlog Refinement – 度量：Burndown图、Burnup图、Velocity
- 23. Scrum（一） ：迭代周期框架 • 迭代周期框架： – Product Release<=Time-Boxed Sprint<=Daily Continous Delivery • 业务战略传递： – Strategy=>Portfolio=>Product=>Release=>Sprint=>Daily Working What？ How？
- 24. Scrum（二）：团队 Build The Right Thing Build The Thing Right Build It Fast Scrum Team • Achievement-oriented • Customer-oriented • Committed • Motivated • Self-organized • Empowered • Skilled
- 25. Scrum团队：团队文化 共赢的文化 • 团队成功 • 个人发展 • 立足现实 • 挑战极限
- 27. Scrum团队：Product Owner职责 • 主要负责确定产品的功能和达到要求的标准，指定软件的 发布日期和交付的内容，同时有权利接受或拒绝开发团队 的工作成果 • PO在Scrum中承担了多项职责 – 产品经理：愿景和方向，结果负责 – 需求分析：业务分析和需求分析 – 需求管理：维护、终止和变更 – 项目管理：优先级排序和项目状态跟踪 – 质量保障：检查产品结果 – 客户代表：产品体验/接受拒绝 • PO对外承担了与产品干系人交流沟通的职责 – 老板、客户和用户、营销和销售、…
- 29. Scrum团队： PO能力要求 • 业务分析能力（Business Analysis） • 工程技术能力（Engineering） • 领导和协调能力（Leadership & Coordination） http://www.slideshare.net/mcottmeyer/how-to-own-a-really-big-complex-product-v3
- 30. Business Analysis Capabilities Helping organizations develop the capabilities to achieve Enterprise Agility Understand Needs of the Customer Develop Product Strategy Manage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product Strategy Solution Requirements Develop Product Launch Product Operate and Support Product Define Product Backlog Establish Product Vision Define Product Roadmap Plan Launch Engage Stakeholders Planning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process Adherence Identify and Remove Impediments Ensure Internal Communication Maintain Work Environment Develop Team Support Operations Provide Customer Support Support Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer Solution Deploy Product Integration Testing Learn from Outside Sources Commit To Agility Manage Risks Provide Job Training Everyone Environment Perform Maintenance and Customizations Product Development http://www.slideshare.net/mcottmeyer/how-to-own-a-really-big-complex-product-v3
- 31. Engineering Capabilities Helping organizations develop the capabilities to achieve Enterprise Agility Understand Needs of the Customer Develop Product Strategy Manage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product Strategy Solution Requirements Develop Product Launch Product Operate and Support Product Define Product Backlog Establish Product Vision Define Product Roadmap Plan Launch Engage Stakeholders Planning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process Adherence Identify and Remove Impediments Ensure Internal Communication Maintain Work Environment Develop Team Support Operations Provide Customer Support Support Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer Solution Deploy Product Integration Testing Learn from Outside Sources Commit To Agility Manage Risks Provide Job Training Everyone Environment Perform Maintenance and Customizations Product Development http://www.slideshare.net/mcottmeyer/how-to-own-a-really-big-complex-product-v3
- 32. Leadership & Coordination Capabilities Helping organizations develop the capabilities to achieve Enterprise Agility Understand Needs of the Customer Develop Product Strategy Manage Product Portfolio Achieve Customer Acceptance Define Business Requirements Product Strategy Solution Requirements Develop Product Launch Product Operate and Support Product Define Product Backlog Establish Product Vision Define Product Roadmap Plan Launch Engage Stakeholders Planning Coordinate Launch Establish Development Environment Manage Suppliers Ensure Process Adherence Identify and Remove Impediments Ensure Internal Communication Maintain Work Environment Develop Team Support Operations Provide Customer Support Support Implementation Coordinate Work Maintain Architecture Understand Requirements Maintain Product Quality Design and Engineer Solution Deploy Product Integration Testing Learn from Outside Sources Commit To Agility Manage Risks Provide Job Training Everyone Environment Perform Maintenance and Customizations Product Development http://www.slideshare.net/mcottmeyer/how-to-own-a-really-big-complex-product-v3
- 33. Scrum团队： Scrum Master职责 https://www.scrumalliance.org/community/articles/2014/may/what-it-is-that-a-scrum-master-does-all-day-long • 主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在 客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
- 34. Scrum团队： Scrum Master能力要求 • 出色的沟通和决策能力 – 能及时、清楚、明确地传播信息； – 知道什么时候做出决定，不必要再做分析； – 平衡短期和长期目标，快速在团队和Product Owner之间达成一个共同的愿景； • 促进团队合作的能力 – 能够促进和培养团队合作的能力，能够诊断、理解和帮助团队的日常变化； – 持续衡量团队工作状况，并推动必要的行动，以改进团队的工作； • 鼓舞和激励能力 – 促进团队活力，鼓舞、表扬和奖励团队中做得最好的人，宣扬突出的行为、技能和成就； – 伟大的工作态度，总是寻找方法来改变工作，而不是认同为什么做出改变是不可能的； • 抗压能力 – 在压力环境下仍能保持镇定，出色工作 • 解决冲突能力 – 促进建设性的辩论，使得产生更好的决策和共同愿景 – 建设性地解决分歧和冲突，知道什么时候让其他人也参与进来 – 在所有交往中，体现出情感成熟度（周到、客观、正直、可靠） – 即使在他/她不同意的时候，也会支持哪些已经做出的决定 • 敏捷开发实践能力 – Backlog跟踪，burndown图，会议组织，计划能力，进度跟踪，风险管理，组织变革、团队成长，敏捷开发实 践，持续集成/交付/部署，... 参考：https://www.scrumalliance.org/community/articles/2007/april/the-right-skill-set-the-right-mind-set-the-right
- 35. Scrum团队： Scrum Master特质 • 专注并细心 – 确保团队行为始终与验收标准和项目目标（愿景）保持一致； – 通过良好的组织方法分配工作任务，减少失误； • 团队合作者 – 勇于承担任何能够帮助团队的任务，并以身作责（比如，团队决定加班来完成Sprint目标，Scrum Master应该和团队在一起） • 善于解决问题的能力 – 是一个能快速获取信息去解决问题的老手； – 帮助团队识别冲突的优先级，并表达并逐级向上反应不能快速的问题； • 值得信赖 – 信守承诺，说到做到 • 亲近 – 平易近人，风度翩翩 • 高度的决心和毅力 – 这是成功的关键性因素。因为，对于推动队员思维模式的转变是非常困难的，更不用提整个组织的转变了，特别是在看到组织内部有失败案例的时候； – 你必须有足够的耐心来帮助团队一步一步地转变，因为要想看到积极的趋势是会花很多时间和精力的。在出现“信任危机”的时候（非常可能出现）， 你必须要有足够的耐心来说服他人、影响他人； • 既要理解标准化的Scrum模式，又要根据自己组织的固有特点来实际地运用它 – 这是成功的决定性因素。因为没有任何两家公司是相同的； – 这也要求你要比较温和的推进转变。记住：欲速则不达； – Scrum Master需要制定一个比较长远的推进计划，然后步步为营，直到团队自己找到基于Scrum框架和思维模式的最佳工作方法； • 准备好挑战他人并接受他人的挑战 – 向管理层寻求帮助固然有用，但通常比较困难。因此在适当的时候记得去挑战你的老板。很多成功的变革通常是由下至上发起的，不要一味地依赖老 板的指示； – 若在实施过程中受到外界的挑战和动摇，一定要对自己、对团队、对组织有坚定的信心。如果外界的动摇具有10分的摧毁力，那么你自己的动摇则具 有100分； • 持续改进自我的愿望 – 这点不仅适用于团队成员，更是适用于Scrum Master自身。因为通过自我的持续改进，你才能有效的影响团队成员，让大家积极的凝聚在一起，直到 找到最高效的工作方法这一终极目标。
- 36. Scrum团队： Dev Team职责 • 主要负责软件产品在Scrum规定流程下进行开发工作，人数控 制在5~10人左右，每个成员可能负责不同的技术方面，但要求 每个成员必须要有很强的自我管理能力，同时具有一定的表达 能力；成员可以采用任何工作方式，只要能达到Sprint的目标。 • 主要职责 – 定义（分解）工作任务 – 评估工作量 – 开发产品 – 确保质量 – 完善过程
- 38. Scrum团队： Dev Team(2) 特性团队 Component Team Feature Team VS. http://www.craiglarman.com/content/feature-teams/feature-teams.htm Component Team的组织方式会导致瀑布式的开发流程，以便协调团队 间的工作任务。 Feature Team组织方式的成功依赖于团队能力，以及团队对于重构、 持续集成、自动化测试等敏捷开发工具和实践的使用。
- 40. SCRUM（三）：SCRUM工件 • SCRUM工件 – 核心工件：Product Backlog，Sprint Backlog， Shippable Product Increment； – 其它工件：Dependencies / Blocker list；
- 41. SCRUM工件：Product Backlog • Product Backlog是条目化/量化的用户需求，它将需求文档中需要实际 开发的需求（包括功能性和非功能性需求）条目化地表达出来。 – Product Owner维护，用场景描述的用户需求(Story)列表 – 经过优先级排序和工作量评估的 – 优先级越高的条目，User Story描述粒度越细 – 反映了业务的计划
- 42. SCRUM工件：PB(1)Items My primary rule for including any item in the product backlog is that the work must be something the product owner can understand and can reasonably prioritize against features. So if you do choose to include PBIs of type technical work, you will need to make the value of the item clear to the product owner. http://www.innolution.com/blog/demystifying-product-backlog- concepts
- 43. SCRUM工件：PB(2)User Story描述 As a <USER ROLE>, I want a <FUNCTIONALITY> So that I can get <BUSINESS VALUE>. 基于目标和场景驱 动，体现业务价值
- 44. SCRUM工件：PB(3)User Story 粒度 按照业务优先 级次序，将大 粒度的用户故 事拆解为小粒 度的用户故事， 并依次经过评 估后安排进入 Release计划 和Sprint计划
- 46. SCRUM工件：PB(5)User Story评估 • 用户故事INVEST模式 – Independent: 减少依赖，便于计划 – Negotiable: 通过协作添加细节 – Valuable: 对客户有价值 – Estimable: 太大或太模糊的用户故事，无法评估 – Small: 可以在由一个团队在一周内完成 – Testable: 有好的验收原则 • 评估用户故事的大小 – Story Points – Anchor Story，相对值评估 – 斐波那契数列和扑克牌游戏 – 贴墙技术 • 衡量团队Velocity – 用4~6个Sprint来确定速率
- 47. SCRUM工件：PB(6) 非功能性需求描述 • Nonfunctional requirements represent important system-level constraints that affect the design and testing of most or all items in the product backlog. Nonfunctional requirements are used to specify various characteristics such as system performance, accuracy, portability, reusability, maintainability, interoperability, capacity, platform fan-out, and so on. • 以User Story方式描述NFR，有助于理解部分技术决策背后的原因，如： – As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on. – As the CTO, I want the system to use our existing orders database rather than create a new one, so that we don't have one more database to maintain. – As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I don't get frustrated and find another site to use. – As someone who speaks a Latin-based language, I might want to run your software someday. – As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time. • 参考http://scaledagileframework.com/nonfunctional-requirements/
- 48. SCRUM工件： Sprint Backlog ― 确保考虑到工作中所有细节：编码、 测试、代码评审、会议、学习新技术、 编写文档… ― Sprint tasks需要评估到小时 ― 如果任务需时超过一天，尝试分割成 几个小任务 ― 如果团队认为Sprint Backlog项目过多 或过少，和产品负责人一起调整问题 数量 ― 团队确认Sprint目标 ― 如果工作不清晰，可以先建一个粗粒 度的Sprint Backlog，然后再分解 ― 所有任务项都分配给团队成员 ― 每日更新剩余工作评估 ― 团队成员对任务的DoD(Definition of “Done”)应该有共同的理解 ― 只计算全力以赴完成所需要的时间， 剩下的…交给燃尽(Burndown)图解决 • Sprint Backlog是Scrum团队在Sprint Planning会议中确认的待办任务列表，映射到传 统项目管理理论中就是WBS，而且是典型的采用面向交付物的任务分解方法得到的 WBS。
- 49. SCRUM工件： Impediments List(1) http://www.gettingagile.com/2011/01/24/organizational-impediment-management-early-risk-detection-for-agile/ • Impediments（障碍）是指任何阻止团队有效工作的事或物。 – 部分障碍可以由团队自己解决，其中一些障碍的跟踪最好能对全团队可见。 – 部分障碍超出团队能够解决的范围，需要Scrum Master找出相关的干系人来一起解决 – 也有一些小而重要的障碍，可能是公司组织所固有的，任何一个团队无法独立解决， 需要公司层面企业文化、组织架构的变革来解决，这需要Scrum Master推动管理层完 成。
- 50. SCRUM工件： Impediments List(2) • 10大典型障碍 – 会议规则没能被遵循 – 产品远景和Sprint目标不清晰 – 没有产品负责人负责回答提问 – 产品Backlog未能按商业价值区分优先级 – 并不是所有负责交付产品的人员都是团队里的成员 – Scrum Master还要处理其他任务，不能集中精力 – 团队人数过多（多于7个开发人员） – 团队没有能坐在一起工作的空间 – 团队的Sprint Backlog混乱 • 以障碍Backlog方式管理障碍 – 把所有已知的障碍加入到障碍Backlog的“新事项”栏中 – 按优先级顺序排列“新事项”栏中的障碍问题 – 每当您开始着手解决一个障碍问题时，将它移至“正在处理事项”栏中 – 尽快解决这个障碍 – 障碍得到解决时，将它移到“已完成”事项栏中 – 在Scrum每日例会和Sprint回顾会议中收集新的障碍问题
- 51. Scrum工件：Definition of “Done” • 对于Scrum工件中的条目，团 队一起定义“Done”（“完 成”）的真实内在含义，以免 在评估项目时发生误解和分歧。 • “Done”的几个例子： – Design, coding, unit testing, integrated – Static analysis, refactored – Acceptance tested, deployable https://www.scrumalliance.org/community/articles/2008/september/definition- of-done-a-reference
- 52. Scrum（四）：Scrum活动
- 53. Scrum活动：Release Planning(1) – Who: Scrum Coach, Product Owner, Scrum Team, Scrum Master, Key Stakeholders – When: before release n+1 begins (.5 -2 days) – How / Topic(s): • PO presents the vision, strategy and goals. • PO present key dates and milestones. • PO presents draft of the prioritized backlog. • Discussion to understand user stories. • Review rough estimates + prioritized features. • Agreement on Sprint length (in weeks) and target release dates. • Release Plan is organized by scope (functionality) or time (release every N sprints). • Continual Planning. The initial release plan is a ‘blueprint’ to get started and will be revised. Selected stories for the release Product Vision High level prioritized goals & roadmap Key risks and assumptions Stakeholder consensus Prioritized product backlog Goal: Establish the overall release schedule and determine in what sprint stories will likely be delivered. Product Backlog (priority draft) Release Plan Rough Estimates 产品负责人和团队一起对整个产品Backlog进行评估，提出划分发行版本和Sprint计划的主要依据。
- 55. Scrum活动：Sprint Planning(1) – Who: Scrum Coach, Product Owner, Scrum Team, Scrum Master. – When: before Sprint n+1 begins (2-3 hrs). – How / Topic(s): • PO presents the backlog items in priority order for review. • Stories with failed acceptance tests from prior sprints are added*. • Discuss story creation for defects from prior sprints*. • Review and clarify user stories. • Breakdown larger stories and each story into tasks and acceptance criteria. • Tasks are estimated in hours. • 1 developer and tester assigned to be on point per story. • Process continues until all available hours are used for the sprint. Selected stories for the sprint Sprint Plan Prioritized product backlog Teams capabilities (hours) Key risks and assumptions Stakeholder consensus Goal: Team to plan and agree on backlog items they can complete and confirm the tasks required to support acceptance. Schedule risks / Business conditions Release Plan Prior Velocity Story Effort Estimation
- 56. Scrum活动：Sprint Planning(2) 一个分两阶段议程Spring计划会议的例子： ‒ Sprint计划会议1：产品负责人和团队一起，在先前评估的成果基础上，定出Sprint目标和既定产品Backlog。 ‒ Sprint计划会议2：团队将既定产品Backlog中的每一项细化成多个任务，每个任务完成的时间限定在一天内。
- 57. Scrum活动：Daily Meeting • 每日例会：有助于团队进行自我组织。这是项目团队成员间的一个进度协调会议。会议每天都 在同一时间同一地点举行。时间限定在15分钟内。 • 与会者：团队所有成员，Scrum Master，产品负责人（可选），相关人员（可选） • 三个重要问题： – 上次会议后我完成了什么？ – 到下次会议开始我准备做什么？ – 有什么障碍阻止了我的工作进度？ • 更新Sprint Backlog，包括增减任务项、更新任务进度和状态 • 会议控制： – 如果展开了一个问题的讨论，提醒团队成员们注意把注意力集中在回答关键问题上 – 如果相关人员想发表些言论，礼貌地提醒他，该会议只允许让小组成员讨论。
- 58. Scrum活动：Sprint Review Meeting • 评审会议：在每个Sprint结束后，将这个Sprint的工作成果演示给 Product Owner和其他相关的人员。 – 团队按照Backlog中的问题，逐个地介绍这次Sprint的结果，和演示新功能 – 如果产品负责人想要改变功能，添加一个新问题到产品Backlog中 – 如果对功能有一个新的想法，添加一个新问题到产品Backlog中 – 如果小组报告项目遇到阻碍现在还没能解决，把该障碍加入到障碍Backlog – 团队达成对这次Sprint的结果和整个产品的开发状态的共识
- 59. Scrum活动：Sprint Retro Meeting • 回顾会议：在每个Sprint结束后，对于当前的迭代周期做一个阶段性的总结，包括好的 方面和不好的方面，帮助团队在下一个迭代中扬长避短，对于一个团队的健康发展很 有好处。 – 主要指导原则：不管我们现在发现了什么问题，我们必须懂得并坚信每个人通过他们当时所知的， 他所拥有的技能和可得到的资源，在限定的环境下，都尽其所能做出了最好的成绩 – 在画板上写上“我们的成功经验是什么（Well Done）”、“有什么能够改进（Needs Improvement）” – 针对以上总结，制定团队完善的Action Items（可以合并到Impediments List），指定负责人和完 成时间，Scrum Master带领团队尽可能落实 • 一般可以从以下方面来进行回顾： – 开发团队效率如何 – 开发团队合作如何 – 项目进展曲线是否平稳 – 开发团队前端和后端的分工如何 – 测试团队的缺陷报告率如何 – 开发周期中有没有被严重Block的因素 – 有没有需求方面的不明确导致Rework – 在任务分配方面有没有不均衡，导致个别人太忙或者太闲
- 63. 思考：Scrum流程框架的问题 • 产品上线后的运营，是一种事件驱动的模式，每天都有问 题需要优先处理，不适合开发人员与运营人员合一的小型 公司/小型团队 – 无法事先计划不被打扰的固定周期 – 太短的周期也不行，有的任务会超过一个周期 • UX/UI设计跟程序设计开发的周期搭配问题 • 不同平台（iOS，Android，Web）开发周期搭配问题 • App Store审核时间不一定 • 两周的开发迭代周期公司仍不满意，可不可以更快，做到 极致？
- 64. 流程框架演进：Kanban Board • 最轻量的流程管理方法 • WIP限制（TOC限制理论） – 限制每个状态的最多项 目 • 关注Cycle Time（平均 每个条目的完成时间） • 流程状态（列）可自行 裁剪，适用于大小项目
- 65. Kanban: vs Scrum Scrum Kanban 相同点 都是敏捷开发流程框架(Lean Thinking, Agile )；都是经验性的，团队需要具体情况（过往 经验）进行调整和裁剪；都基于自组织(self-organizing)团队； 不同点 指定了明确的角色 没有明确的角色定义 timeboxed，固定迭代周期 并不要求timeboxed 限制每个迭代的WIP 限制每个工作流状态的WIP 不欢迎在一个迭代内做出变更 并不拒绝 Scrum board在每个迭代之间清空 Kanban board在项目过程中一直有东西 指定要cross-functional的团队 并不要求 规定了“estimation”和“velocity” 并无规定，有很多好的实践
- 68. 更多流程框架比较 （更规范） （更灵活） http://www.infoq.com/minibooks/kanban-scrum-minibook • 每种方法都有一定的局限性 • 不要限制自己只使用某一种工具！
- 69. 流程框架的组合使用示例 Story Backlog Task Backlog In Process Task Done Story Backlog Analysis Design Build Test Deploy Inception Elaboration Construction Transition Tier 1 - Scrum Tier 2 - Kanban Tier 3 - KanbanEpic Feature User Story http://www.slideshare.net/search/slideshow?searchfrom=header&q=Introduction+to+Agile+Planning+and+Project+Management
- 70. 大型项目流程框架：Scrum of Scrums Agenda • Three questions – What has my team done since we last met that might affect other teams? – What will my team do before we meet again that might affect other teams? – What problems are my team having that other teams might be able to help with? • Discussion – Discuss items kept on an Open Issues Backlog
- 72. 敏捷方法和最佳实践
- 73. 敏捷方法和最佳实践概览 战略： - 机会画布方法 - 商业模式画布方法 - 精益画布方法 - 价值主张画布 - 企业架构方法 需求： - 需求捕获技术 - 需求建模技术 - 需求User Story描述方法 - 需求优先级评估方法 - User Story切分技术 - User Story Mapping - UML用例建模技术 反馈： - 数字化评估方法 实现： - 敏捷架构设计方法 - 产品交互体验设计方法 - 模型驱动开发技术 - 持续交付技术 组织： - 组织结构 - 打造领导力驱动型团队 - 研发过程管理规范体系建设
- 74. 战略：机会画布方法 探寻机会的思维 方式： - 移情：理解你 的用户 - 定义：识别问 题 - 构思：头脑风 暴，形成思路 - 原型：用线框 图或代码快速 搭建原型 - 验证：验证并 优化
- 79. 战略：企业架构方法 企业架构和敏捷架构： • 企业架构关注于整个企业 的IT架构规划，而敏捷架 构关注于项目交付层面； • 企业架构是着重于企业的 未来，而敏捷架构是着眼 于项目的当下； • 企业架构是自顶向下的架 构方法，而敏捷架构更偏 向于自下而上的架构方法， 两者相辅相成，可以互为 补充。 可参考架构模型： TMForum - eTOM/SID/TAM/TNA NRF-ARTS
- 80. 需求：需求工程 source - http://paulabrown.net/requirements -engineering-process 敏捷需求管理的目标： • 关注用户价值 • 强调用户参与 • 适应需求变化 • 快速迭代实现
- 81. 需求: 需求捕获 《需求捕获指南》 需求捕获是软件项目的基础部 分，对后继的分析设计及开发 实施有重大影响。如果做的好， 会减少需求变更和返工。此外， 需求捕获过程的质量也将决定 客户对需求的完整性、正确性 的认可。因为这个阶段的困难 性和影响力，按一个理想的模 式来完成需求捕获过程就非常 重要。 需求捕获可定义为：需求捕获 是两个有关团体相互沟通，识 别需要的过程。两个团体通过 这个过程提取、定义需求，来 约束两个团队。需求捕获既涉 及技术问题，也涉及社会交往 问题。 参考：《需求捕获指南》 source - http://requirements.seilevel.com/requirements-elicitation-process-flow 需求捕获的方法： - 访谈 - 小组会议 - 问卷调查 - 其它：现场观摩/文档考古/原系 统研究/分析同类软件产品特性 脑图工具Mindjet Mindmanager 是值得推荐的需求记录和整理 工具
- 82. 需求：需求建模技术方法 基于目标与场景的用例驱动需求分析技术研究 • 由相关的组织和系统利益相关者给出待建系统的业务层目标（只能有一个） • 对业务层目标精化，形成服务层目标（业务层子目标，可以是一个或多个），服务层目标通过服务层场景实现 • 从服务层场景中发掘比服务层更为小粒度的目标，即交互层目标，关注代理（可以是人、机器或系统）之间的交互， 交互层目标由交互层场景实现 • 通过对交互层场景的设置，可以发掘出内部层目标，关注待建系统内部操作的实现，内部层目标由内部层场景实现 http://www.doc88.com/p-3867368555893.html，《基于目标与场景的用例驱动需求分析技术研究》
- 84. 需求：需求优先级评估方法 示例：优先级排序的“Kano分析法” 优先级排序方法： • Kano analysis • Expert opinion • Theme screening • Theme scoring • Relative weighting • Financial analysis 参考： http://www.slideshare. net/mikecohn/prioritizi ng-your-product- backlog-22870228
- 86. 需求：User Story Mapping User Story Mapping： • What to build first • Encouraging iterative development • Scoping the project • Planning the project • Prioritizing and grooming the backlog • Visualizing Project Progress 参考： http://www.slideshare.net /SteveRogalsky/user- story-mapping-in-practice User Activities (Backbone) User Tasks (Walking Skeleton) User Stories
- 87. 需求：UML用例建模技术 改进前的业务序列图 改进后的业务序列图 系统用例 运用用例图和序列图进行用例建模 参考：《软件方法 – 业务建模和需求》by潘加宇
- 88. 实现: 敏捷架构设计方法 鲁棒图分析方法作用： • 健全性检查(Sanity check) • 完整性检查(Completeness check) • 对象识别(Object identification) • 初步设计(Preliminary design) • 有助于实现分层架构模式，衔接 领域驱动设计 http://pst.web.cern.ch/PST/HandBookWorkBook/Handbook/SoftwareEngineering/UCDOM_robustness.html 从最核心用例开始，采用 鲁棒图检查迭代补充完善 系统用例，识别接口需求 (Boundary)，识别领域模 型对象(Entity)，识别控制 层逻辑(Controllers)
- 89. 实现: 产品交互体验设计方法(1) http://www.anniestudio.org/wp-content/uploads/2012/10/lean-ux-page-h-1024x791.jpg
- 90. 实现: 产品交互体验设计方法(2) 线框流程图产品原型设计： 原型评审的沟通顺序应依次为： (1) 目标和场景介绍 (2) 业务流程或交互流程说明 (3) 功能说明或页面说明
- 91. 实现: 模型驱动开发技术 DDD+MDSD工具实例：sculptorgenerator http://sculptorgenerator.org/ 模型驱动开发技术概览： 模型驱动开发优点： • 开发更快速、开发成本更低 • 架构更强壮，提高开发质量，支持有效性验证，出错率更低 • 项目重心放在业务而不是技术，消除业务和IT之间的隔阂 • 有助于优化人力资源使用，解放高阶程序员，使其有更多的机会发挥创造性
- 97. 组织：研发过程管理规范体系建设 研发过程管理规范分布： 研发过程规范的内部结构： http://wenku.baidu.com/view/527ae10e52ea551810a68760.html
- 99. 思考和答疑