敏捷开发方法与实践交流

敏捷开发方法与实践交流张邱溪2011年4月了解敏捷（为什么要使用敏捷方法?）实践Scrum（什么是Scrum？我们Scrum了么？）问题探讨（寻找属于我们的敏捷之道）提纲项目成功率统计即使软件交付了，也不意味着成功了why？软件开发项目中的复杂性复杂混乱复杂的复杂的简单的需求远离清晰接近清晰接近明确远离明确技术传统软件工程的做法架一座通往按时交付的桥搭一个棚子来拒绝需求拒绝改变一个小漫画你的项目最近如何啊？糟透了，一团乱麻就像十五个喝醉的猴子在玩一个拼图游戏你的项目进展怎样了？很好，进展正常问题隐藏如果不能改变它，那就去适应它！敏捷宣言–个体和交互胜过过程和工具–可以工作的软件胜过面面俱到的文档–客户合作胜过合同谈判–响应变化胜过遵循计划虽然右项也有价值，但是敏捷开发认为左项具有更大的价值！也就是说：自组织团队与客户紧密协作，通过高度迭代、增量式的软件开发过程响应变化，并在每次迭代结束时交付经过编码与测试的有价值的软件胜过与客户确定合同后在初期制定并遵循基于活动的完整计划，在重型过程和工具指导下，通过完成大量文档进行知识传递，最后交付需求敏捷原则l1、我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。l2、即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。l3、经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。l4、在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。l5、围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。l6、在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。l7、工作的软件是首要的进度度量标准。l8、敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。l9、不断地关注优秀的技能和好的设计会增强敏捷能力。l10、简单是最根本的。l11、最好的构架、需求和设计出于自组织团队。l12、每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。敏捷关注什么敏捷带给我们什么产品上市时间平均减少了69％成本降低了57％工作量降低了62%致命缺陷平均减少了80％普通缺陷减少了60％。员工士气提升责任感增加协调与合作促进...…对一系列敏捷项目的分析结果表明了解敏捷（为什么要使用敏捷方法?）问题探讨（寻找属于我们的敏捷之道）提纲实践Scrum（什么是Scrum？我们Scrum了么？）Scrum的起源Scrum的样子ProductBacklog(PBI)来自最终用户、客户、团队或其它干系人的需求输入ProductOwnerTeamScrumMaster1-4周SprintBacklog(SBI)选择下一个Sprint承诺的内容Sprint计划会议周期和目标不变可交付产品增量日站立会议回顾会议审核会议Scrum的特征•敏捷过程之一•自组织的团队•迭代开发•信息可见性•一份产品需求清单•没有任何工程实践说明•强调营造一个敏捷环境，并不断改善Scrum的五个价值观尊重Respect承诺Commitment开放Openness专注Focused勇气Courage越来越多的企业开始用Scrum深入ScrumScrum的3-3-5工件仪式ProductOwner(PO)l定义产品的Feature(功能/特性)l负责产品的利润(投资回报)l根据市场及业务价值对产品特性排定优先级l对发布日期和内容进行决策l需要时，每一个迭代调整产品特性和优先级l接收或者不接受工作的结果谁是合适的ProductOwner？没有ProductOwner可以么？案例&问题分析1传统的产品经理、专业的需求分析师可以是PO的人选，但是要完成角色的转变，担负起PO应有的职责，尤其是为用户和客户负责。一个ScrumTeam不能没有PO，否则软件的业务价值将无从谈起。ProductOwner对团队说他不能够参加这次的Sprint计划会议，因为要和一个合作伙伴公司的上层打一场重要的高尔夫球。他不介意团队计划独自进行会议。这样做可以么？案例&问题分析2不可以，因为Sprint计划会议中，需要制定Sprint的目标，向Scrum团队宣贯ProductBacklog，解答团队在UserStory评估和任务拆分时遇到的业务问题，而这些都是离不开PO的参与的。团队(Team)l建议通常5-9人l跨职能(团队、个人两个角度)l成员最好是全职的l团队是自组织的，理想是没有职称之分l迭代之间，成员构成才做变更原先的TeamLeader、架构师、界面设计、专职测试职位还有存在的价值么？案例&问题分析3理想的Scrum团队，除了ScrumMaster、ProductOwner和Team外，再没有别的职称之分了，Team中的成员是跨职能的，每个人都可以是架构师、设计师和测试人员。ScrumMasterl面向项目代表管理层l负责Scrum价值观和过程的实现l移除障碍l确保团队的生产能力和全速前进l促使所有角色和职能人员间的密切合作l保护团队免于外部干扰l服务式的领导谁是合适的ScrumMaster？ScrumMaster可以取消么？案例&问题分析4ScrumMaster倾向于从原先的开发团队中选择，比如TeamLeader，或者是对敏捷有较多认识，较大兴趣的任何TeamMember，也可以是传统的项目经理。这是一个需要思想和职责较大转换的角色。ScrumMaster原则上不可以取消，除非Scrum团队达到一个理想的自组织程度，而不再需要敏捷教练的指导。ScrumMaster需要有技术背景么？案例&问题分析5Scrum框架中并没有要求ScrumMaster必须拥有技术背景，ScrumMaster的职责中更多也是体现协调能力、沟通能力。但是显然，拥有较深的技术背景对发现问题和解决问题，以及与技术出身的开发团队达成融洽方面更有帮助。特别是Scrum团队在技术方面比较欠缺，面临着很多技术问题时。否则，如果一个技术成熟的团队，技术背景就不是那么重要了。一个项目中，一个9个人的Scrum开发团队中所有成员好像都在非常忙碌于实现他们对这个Sprint的承诺。而ScrumMaster好像比较空闲，没太多事情可以担心似的。有一位成员向ScrumMaster建议，要不你也在SprintBacklog上找些开发的活干一下，和我们一期交付产品特性？案例&问题分析6对于9个人规模的Scrum开发团队，要发现隐藏的问题、解决出现的问题，协调团队、避免干扰等等事务工作量是巨大的。如果ScrumMaster真的无所事事，要么就是这个Master没有尽职，要么就是团队自发组织的成熟度已经非常高。如果是后者，可以考虑有没有必要继续保留ScrumMaster的角色，否则的话，可以看看后面一页一个6年经验的Master所列举敏捷教练应做的工作内容，我们做到了么，做好了么？ScrumMaster应该干些啥？做敏捷这个环境的建设者和守卫者保持Scrum正常运转PO、团队、干系人力量平衡保护团队免受干扰团队的润滑剂协调与组织帮助聚焦帮助达成Sprint目标与PO协调工作帮助PO、团队、管理层和组织不断学习与进步排除障碍增加透明度鼓励和确保自我组织帮助大家提高自助能力大力支持内部授权提高沟通效率和有效性发现隐藏问题并努力解决帮助团队经验积累解决ScrumMaster与PO可以合二为一由一个人承担么？案例&问题分析7一般情况不可以，因为ScrumMaster与PO从职责上来讲是有着一定冲突的，PO代表的是最终用户与客户的意愿，要对用户负责，理想情况下，PO就是客户的一员。而ScrumMaster是团队的保护者，避免干扰，保证Sprint的顺利。特殊情况下，如果能把这两个角色都把握的很好，能很好的切换，且能够把两个角色的职责都做的很好，可以同一个人担当，但是不建议。角色仪式Scrum的3-3-5产品Backlog(ProductBacklog)l需求-项目想要交付的工作清单l一份合格的产品Backlog应该：ü已排序(按优先级)ü有价值的(业务价值)ü带估算的(需要投入多少工作量)lPO负责优先级排序l在Sprint计划会议前PO可以调整排序用户故事的内容用户故事的推荐写法用户故事的特性用户故事例子史诗故事EpicVS可以实施的故事形式有团队人员抱怨说，用了用户故事后，需求描述变简单了，开发的时候根本不知道细节，该做成什么样，造成做完的功能不满足要求。是用户故事不合适么？案例&问题分析8用户故事有三方面的体现，也就是常说的3C：卡片、交谈和确认。如果只看到卡片，那么用确实是非常简单和概略的，但是更多的，了解用户故事的详细情况是通过不断的交流和沟通，并通过较快得迭代落地实现的。这些内容是由PO所提供的。SprintBacklogl每个人认领Sprint中的任务ü工作不是分配下去的l每天更新剩余工作的估算l任何团队成员都可以添加、删除或者更改SprintBackloglSprint中的工作会涌现l如果工作不清楚，定义一个大工作量的SprintBacklog事项，留到以后再分解l当我们更加了解我们的工作时，更新剩余的工作创建SprintBacklogl从产品Backlog中选择在新的迭代中承诺完成的事项l识别工作任务并估算工作量l群策群力，不是ScrumMaster一个人在做l进行概要性的设计Sprint进行当中，SprintBacklog可以发生变化么？案例&问题分析9可以，因为SprintBacklog是一个个的任务Task，而随着开发进程的深入，有可能一些初期不明确的Task会浮出水面，或者一些冗余的Task可以丢弃。燃尽图(BurndownCharts)l每天更新l跟踪剩余工作量l不同的方式l跟踪任务层剩余工作量l跟踪完成情况团队的速率(Velocity)l团队速率描述及预测我们一个迭代能完成多少工作l你的团队迭代速率是多少？l最理想的是历史数据l开始时(第一个Sprint)更多是一个估算l当一个Sprint完成，就有了历史数据l使用真正的完成l使用相对工作量案例&问题分析10小时Task故事点燃尽图燃烧的是什么？相比而言，Task数比剩余小时数要好，最能体现交付进度的则是故事点数。当然也可以采用结合的方式。案例&问题分析11一个团队的燃尽图看起来很完美，可是快到Sprint结束时，团队还没有交付任何可用的UserStory，Why？另外一个团队，虽然也按照交付了东西，可是用户现场反馈问题太多，根本没法上线。又出现了什么问题？案例&问题分析12第一个团队的燃尽图纵坐标不是剩余时间就是剩余任务点，而这些都不代表UserStory的真正完成，比如Sprint中承诺实现10个UserStory，每个Story都只剩下最后的测试任务了，好像燃尽图接近尾声，实际任何Story都没交付。第二个团队则是没有定义出什么是真正合理的“Done”，团队认为简单的测试就是交付了，实际上离“可用”还差的很远。Scrum的3-3-5角色仪式角色工件SprintlScrum项目通过一个接着一个的Sprint来推进l通常每个Sprint长度为2-4周，最长不超过一个月l使用一个固定的Sprint长度，带来节奏感l在Sprint中，涵盖产品的设计、编码、测试l根据能够承诺一个Sprint跨度不做变更来计划长度l严格的时间箱，成功or失败的标准案例&问题分析13一位团队成员告诉ScrumMaster说ProductOwner刚刚来请求她在当前的Sprint中加入一个产品Backlog事项。目前，这个Sprint大概进行了1/3。在一个还未完成的Sprint阶段中，是不允许加入产品Backlog的。如果因为市场原因，必须调整纳入该Sprint的产品Backlog，则可以取消当前Sprint。重新进行一轮。另外，如果Sprint承诺的Backlog提前完成，且时间较长，可以考虑增加合适大小的产品Backlog。能否取消一个Sprint？案例&问题分析14可以！如果