关于scrum和xp的第一本书

《硝烟中的Scrum和XP》是严格意义上我完全读完的一本关于scrum和xp的书，在这之前更多的是通过网上博客了解关于敏捷的一些实践。

敏捷宣言发布至今，关于敏捷的争论从未停下，而敏捷在各种千奇百怪的团队中的实践也没有停下，《硝烟中的Scrum和XP》正是这样一本讲述了利用scrum和XP进行敏捷实践的书。

不完全指南 只能参考

这本书并不是一本类似完全指南的书，看完就可以掌握武功秘籍，它更像是一种讲故事，大概就是一个和你一起走路前面的路他曾经也走过的人和你相遇，告诉你前面你可能会遇到一条河，你可以拿块木板搭个桥，给你一点小经验，但是实际上你不想带块笨重的木板，你穿双雨鞋淌水过去也行。
作者遇到的问题可能我们并不会真的遇到，作者没遇到的问题，也许我们会遇到一大堆，正如原书作者所说

    这只是我个人的经历。你不应该完全仿照我的做法。实际上如果换个不同的场景,我也许就会换种实践方式了。

---

在前面，作者无情地揭露了关于敏捷的一个真相——我们不得不根据自己的具体情况来对敏捷的实践进行调整，原话是

    scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。

好比是给迷路的人指了一条到达终点的路，但是又突然告诉你，这条路也许走不通了现在。
接下来，我们就聊聊关于这条路上发生的那些事情吧......

路上，你经常看到这些词

• sprint
  短跑冲刺，可以理解为一个开发周期或者迭代，每一个sprint都会有计划的输入和输出以及限定的时间。

团队在每个sprint里面，从product backlog中选取特定的任务，一起开发，全力冲刺，保证任务按照预期的完成。

• product backlog
  backlog可以理解为待办事项，产品backlog是scrum的核心，也是一切的起源。从根?上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序。

• sprint backlog
  在一个sprint里面需要完成的故事，是根据团队工作进度动态变化的，可以用Jira、Excel，还有挂在墙上的任务板来记录表示。

• story
  故事，也叫backlog条目，它客户想要的东西,并用客户的术语加以描述。每一个story会有一些字段对它进行描述比如storyid，名称，重要性，估算等。

product backlog、sprint backlog的关系可以用下面的图表示

简单理解sprint backlog 就是在某个sprint期间需要完成的story的列表，是product backlog的一个子集。

• burn down chart 燃尽图，用来计算团队的生产率（方法之一），对需要完成的工作的一种可视化表示，直接上图

你可以先看图猜一下表示什么意思，实在没猜出来，就看下面的这段吧。 这张图包?的信息有:

• sprint的第一天,8月1号,团队估算出剩下70个故事点要完成。这实际上就是整个 sprint 的估算生产率。 ?

• 在8月16号,团队估算出还剩下15个故事点的任务要做。 跟表示趋势的虚线相对比,团队的工作状态还是差不多沿 着正轨的。按照这个速度,他们能在 sprint 结束时完成所 有任务。

路上，你需要做出选择

scrum中是以sprint开展工作活动的，在每个sprint中，sprint的定义感觉好像很简单，但是还是会遇到各种让你感觉没那么简单的选择，比如：

• 如何确定每个sprint的长度，为什么这么长？

• 选择哪些故事需要从product backlog拷贝到sprint backlog中来？以及为什么？

• 怎么样一个story算作完成？标准时可变化的吗？

• 如何保证sprint的每个故事能够完成？如果没能完成怎么做？

这本书对这些内容都给出了一个作者自己的答案，有兴趣的朋友可以自己翻书找答案，同时在给出答案的时候，也告诉了读者，其实这个答案并不是唯一的，很多需要根据真实地状况来进行调整。
整本书初次读完之后其实脑袋有点晕，因为每次作者给出一个答案的同时都会再轻轻地说句“这个答案不是万能的哦”，这种感觉总让我感觉自己不能真正了解scrum一样。

走过之后，这是我记下来

记下这些，一是为了也想给之后看到文章的人指个路，二来也想让以后的自己，有机会有证据来否定现在的自己，算是为自己记下走过的路做个标记。btw，我指的路可能也不对哦，欢迎指正。

• 拒绝复杂，拥抱简单 很多时候,只要能清楚地指出问题所在,到了下一个 sprint,问题也许就自行解决了。 在 sprint 中
  引入的每一点变化,都会让团队付出相应的代价;在引入变化之前, 可以先考虑什么都别做,寄希望于问题自动消失(或变小)。

• 每条路都有优点，选择合适的
  以sprint长短为例，短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快

长的sprint=团队可以有更多时间充分准备、解决发生的问题、继续达成sprint目标=不会被接二连三的sprint计划会议、演示等等压得不堪重负
各有好处，重要的不是方法，而是如何选取合适的方法。

这不是一本很细节的文章，只是初次读完《硝烟中的Scrum和XP》头脑中的一个印象，条理性可能不是很强后面会继续更新我对这本书以及scrum和xp的理解，欢迎大家和我闲聊这方面的内容。