敏捷整洁之道

读书有感

敏捷整洁之道-回归本源

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.

无论哪个商业组织的掌舵者，基本上都是把自己擅长的赛道上大致确定的长期愿景作为靶心。但是在瞬息万变的商战中，要完成某个具体的目标，就像射击一个移动靶，随时都要应对新情况。因此，对软件开发人员开说，“需求变化”太正常不过了，也难怪业务部门经常抱怨：“交付团队的响应能力太慢了”。

团队应该专注于故事，而不是故事中的任务。完成80%的故事比每个故事都完成了80%要好好的很多。要专注于驱动故事的完成。

注释：当今社会，10个任务，完成8个是比10个任务都完成了80%好的。

那一刻，我学到了软件项目是一场马拉松，不是冲刺，更不是一系列连续冲刺。为了获胜，你必须均匀配速。如果你全速越过障碍物奔跑，那么在抵达终点之前就将耗尽力气。

因此，你的奔跑步伐必须能长时间维持。你必须以“可持续节奏”来奔跑。如果尝试以超过自己可持续的速度奔跑，那么就必须减速和休息才能到达终点，这样一来，你的平均速度将慢于“可持续节奏”。当接近终点线时，如果还剩有能量，你可以冲刺。但是在那之前不能冲刺。

经理们可能会要求你比配速跑的再快点儿。你一定不能遵从这样的想法。你有义务节约自己的资源以确保坚持到最后。

加班工作并不能向雇主展现你的奉献精神。这只能表明你的计划做得很糟糕，你答应了不该答应的截止日期，承诺了不该承诺的事情，你只是一个可被操纵的劳工而非专业人士。

这并不是说所有的加班都是坏事，也不是说永远都不要加班。某些情况下的确只能加班，但是它们不应该成为常态。而且你必须非常清醒地意思到加班的成本可能远远超过省下的时间。

实践是敏捷开发的核心，没有测试驱动开发、重构、简单设计及结对编程的敏捷只是虚有其表，起不到作用。

思想体系是思想和理想的系统。方法论是方法和实践的系统。思想体系定义了作为目标的理想。可以用一种或多种方法来实现那些理想，方法论正是达成目标的手段。在阅读《敏捷宣言》和12条原则时，我们可以清楚地看到其背后的思想体系。敏捷的主要目标是提供业务敏捷性和客户满意度，这是通过紧密协作，迭代开发，短反馈循环和卓越技术来实现的。Scrum,极限编程（XP），动态系统开发方法（DSDM），适应性软件开发（ASD），水晶方法（Crystal）,特性驱动开发（FDD）等敏捷方法都是达到同一目标的不同手段。

吉姆.海史密斯在他的《敏捷项目管理》一书中说：“没有实践的原则只是空壳，而没有原则的实践往往是没有判断力的死记硬背。原则指导实践，实践具像化原则，两者起头并进。” 尽管方法和实践是达到目标的手段，但我们不应忽视他们的重要性。定义专业人士的标准就是他们工作的方法。如果我们的工作方法（方法和实践）与某些原则和价值观不一致，那么我们就不能声称自己拥有这些原则和价值观。优秀的专业人士能够准确地描述他们在特定上下文中的工作方式。他们掌握广泛的实践，并能够根据需要使用它们。

在敏捷和匠艺社区里，有个常见的错误是提倡实践而不是其提供的价值。以测试驱动开发为例。在匠艺社区中最常见的一个提问就是：“我如何说服我的经理/同事/团队去开展测试驱动开发？”这本身就是一个错误的提问，错误之处在于我们还没就问题达成一致就先提供了解决方案。如果人们看不到价值，就不会改变他们的工作方法。

总结：敏捷是将项目切分为迭代的过程。敏捷团队要测量每次迭代的输出，并用测量数据持续地评估时间表。他们按照业务价值排序来实施功能，以便优先实施最有价值的东西。他们尽可能保持高质量，并主要通过变更范围来管理时间表。敏捷是帮助小型软件团队管理小型项目的一个小型行为准则。