轻松scrum之旅---敏捷开发故事

简要介绍

《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后，成功向敏捷开发转型的故事。
作者通过4个迭代开发过程，展现了主人公是如何从一个敏捷开发的新手逐步成长为一个资深的Scrum Master的过程；通过这4个迭代开发过程，作者由浅入深的逐步介绍了在Scrum在实施过程中遇到的一个个问题，并通过主人公与一个Scrum专家的邮件交互向我们提供解决办法。同时，还恰如其分的在文章中适当的对敏捷开发的各种概念、实践工具等进行了介绍，让我们能及时了解相关的Scrum知识，而不会感到突然。
这本书非常适合那些想学习Scrum却又无从下手的同学，而且对刚刚实施Scrum的团队来说，也非常具有借鉴意义！
这边书我一口气读完，使我对Scrum实践有了更加深入认识，也促使我回过头来对我们的敏捷过程进行更深入的思考，让我收益颇深！
世上充满无数的选择和努力，但对于成功，选择大于努力。

根据书中内容，总结一下Scrum开发基本的知识：

David的敏捷开发培训–什么是敏捷开发

回家的启发：

stakeholders，我们所有的目标是为了实现利益相关者的利益
sustainable pace，保持一个可以持续的进度，决不能太累
自我管理的团队

敏捷价值观

个体和交互重于过程和工具
可以工作的软件重于面面俱到的文档
客户协作重于合同谈判
随时响应变化重于遵循计划

核心思想

适应变化和以人为本

其他

1, 敏捷开发方法是面向人的而非面向过程
2, 敏捷开发方法是“主动适应”而不是“预先设定的”

敏捷开发的理念

信任开发团队，信任每一个人

敏捷开发中的管理

非命令式，战略指导和服务性质；敏捷开发中，管理者对团队的管理表现在挑选合适的人、为团队创造一个开发自由的工作环境、经常性的反馈、为团队建立评估和奖励机制、当团队有方向性错误时能及早发现并纠正、容忍错误的发生等。

两个故事

买土豆的故事
“鸡”和“猪”的故事

敏捷开发的软素质

A very good team player
Excellent communication skills
Open minded, pro-active, and self-motivated

敏捷开发过程比较

XP
RUP
Lean

Scrum总体结构

任务板
敏捷项目管理工具

在项目的开始制定一个有效的沟通计划至关重要！
产品Backlog、Sprint Backlog、User Story
User Story：作为<某个角色>，我可以<做什么>，已完成<什么目的>。

Scrum三种角色

Product Owner、Scrum Master、Scrum团队成员

1 Product Owner：
需要确定产品的功能和完成时间，并对产品的收益负责，要根据市场需求确定产品功能的优先级。在每个sprint开始之前，Product Owner可以修改功能需求和优先级。而且PO有权决定接受或者否决各个Sprint的工作成果。
Prouduct Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人员来担任，主要工作是根据市场需求确定产品功能，将其列入Product Backlog中斌未这些功能确定优先级。
Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。
在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog， 以及增加某些功能需求、删除某些功能需求、修改优先级等，但这些行为只能在各个Sprint之间进行。

2 Scrum Master：
负责监督整个Scrum项目进程，调整项目计划；确保开发团队成员的能力能够胜任产品的开发；促进团队中不同角色的团队成员充分交流和沟通，并为项目的进行扫除障碍；保证开发团队不受外力的干扰和阻扰；掌握产品的开发进度，参与每日Scrum会议、Sprint计划会议和Sprint平时会议。

3 Scrum成员：
要求Scrum团队是跨职能的，应该包含开发、测试、美工即文档人员。

Sprint计划会议：

时间：一般4-8小时，
参与人员：PO、SM、Scrum团队成员和其他对产品感兴趣的人员，PO从产品Backlog中挑选高优先级的任务，并与Scrum团队成员一起决定这个Sprint中需要完成多少功能。Scrum团队将这些任务分解成小的功能模块。Scrum团队成员详细讨论如何才能按需求完成这些功能模块，并估计完成每个功能模块所需要的大概时间。
确定sprint最后演示的时间和每个story演示的方式

每日scrum会议

每日Scrum会议是Scrum的精髓，最简单又最复杂，如何有效的召开，需要不断的改进和摸索；
一般15分钟，3个问题:
1)昨天我完成了什么工作？
2)今天我打算做什么？
3)我在工作中遇到了什么障碍？
通过每日Scrum会议，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。SM除了倾听团队成员的发言外，还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作顺利进行的障碍。即使有的问题SM没有能力解决，他也应该找到团队中的或其他团队中的成员来帮组快速地解决问题。另外，还有两点需要注意：其一，这是团队成员之间的交流，也是相互的承诺，并不是向老板汇报工作进度的；其二，这也不是一个专门用于解决各种问题的会议，团队成员在工作中遇到的问题可以在会上提出来，而又能力解决这些问题的人可以在会后帮助他们解决问题。

Burndown Chart

是常用的衡量团队进度的可视化攻击。敏捷开发可以给项目提供更多的可视性。

Sprint评审会议：

Sprint结束时召开，一般2小时左右，非正式的会议，可以邀请高层参加，气氛要活跃点，避免变成严肃的报告会。
要避免过多的谈论技术细节，要重点关注最后的成果。
注意任务完成（Done）的定义，

Sprint回顾会议：

参加人员：PO、Scrum团队成员、Scrum Master
宗旨：Scrum团队如何在下一个Sprint中做的更好
重要性：第二重要的事件（最重要的是Sprint计划会议），因为它是让Scrum团队成员成长和进步的最好机会。如果不开回顾会议，不久以后，你就会发现，你的团队在不断地犯着同样的错误。
会议内容：
会议中需要讨论有哪些好的建议或方法应该被采纳，在这个Sprint中有什么做法不可取，有哪些做法效果很好，应该继续下去。
Sprint结束后，Scrum团队成员回顾刚刚结束的Sprint，对其进行总结和反思，使整个团队能持续成长。
Sprint回顾会议的形式可以比较随意，主要做到以下几个方面：
SM首先给大家看Sprint Blacklog，总结这个Sprint。然后，团队成员讨论在这个Sprint中发生的一些比较重要的事件。与会人员轮流发言，每个人都有机会发表自己的意见：他认为哪些方面做的好、哪些方面需要改进、应该如何改进等。此外还要对比Sprint Backlog中各个Story的估计值于它们的实际完成时间，如果差距太大，就应该好好分析出现这种情况的原因。
在Sprint回顾会议结束之前，Scrum Master要总结会上的讨论成果，即“如何才能在下个Sprint中做得更好”。
总之，Sprint回顾会议的宗旨就是：Scrum团队如何在下一个Sprint中做得更好！

Wiki是个不错的敏捷项目文档管理工具

计划扑克：

扑克背后的敏捷思想是团队里没有绝对的权威，每个人都有可取之处，要避免少数服从多数。

Sprint目标：

Sprint Goal是个鼓舞士气的好工具。

代理Scrum Master给我的启示：

真正的Scrum Master要能够排除开发人员和产品负责人之间的障碍，确保Scrum达成目标，实现投资回报最大化，确保团队进度，确保团队状态具有高度的可视性，激发团队创造力，提高团队开发水平，采用各种优秀的工程实践，提高生产力等。

其他知识点

两个Sprint之间的缓冲时间，可以起到承上启下的作用。

Team Pulse Survey统计结果的各项实际上告诉我们应该如何成为一个成熟的Scrum团队

Scrum要求在一个Sprint中团队成员高度稳定

持续集成是敏捷开发中核心的工程实践，它是敏捷产出“可以工作的软件”（Working Sofeware）的有利保障。