Scrum介绍系列4--- Sprint 计划会议

Sprint 计划会议是保证整个Scrum顺利进行的重要一环之一！如何开好，非常关键！

Sprint 计划会议在每一Sprint 的启始阶段进行。在Sprint 计划会议的第一部分，产品所有者和Scrum 开发团队（在ScrumMaster 的协助下）共同评审Product Backlog，讨论Backlog 中各项目的目标和背景，并提供Scrum 开发团队深入了解产品所有者想法的机会。在会议的第二部分，Scrum 开发团队从Product Backlog 中挑选项目并承诺在Sprint 的末期完成任务，从ProductBacklog 的顶端开始（换而言之，从对产品所有者具有最高优先权的项目开始）并按列表顺序依次工作。这是Scrum 的重要实践之一：开发团队决定承诺完成工作量的多少，而不是由产品所有者安排工作量。这就使任务的交付更可靠；第一，因为开发团队承诺工作量，而不是其他人代替其“承诺”工作量；第二，开发团队自己决定所需要的工作量，而不是其他人决定工作量“应该”是多少。产品的所有者对于开发团队承诺任务多少没有控制权，他或她只知道开发团队负责的项目是由Product Backlog 中按顺序从上至下进行的——换而言之，是从他或她选择的最重要的项目开始。开发团队可以从列表底层选择项目提前完成，如果其对于整个开发具有意义（比如，提升和快速完成较低优先权的项目，作为完成较高优先权项目的一部分）。


Sprint 计划会议通常会持续几个小时——开发团队对于承诺完成的任务作出认真地抉择，这些责任要求通过仔细地考虑以达到成功的目标。团队将从估算每一成员拥有的完 成Sprint 相关工作的时间开始——换句话说，是团队成员平均的工作时间减去他们花费在检修bug 和其他必要的维护工作，参加各种会议，回复电子邮件，午休等的时间。大多数人会有4 到6 个小时每个工作日可以完成Sprint 相关的工作。（图示3）

当可利用时间确定下来，开发团队会从Product Backlog 的顶端第一项开始工作——换句话说，从产品所有者的最高优先权项开始——团队共同工作，将其分配为小块任务，并记录在SprintBacklog 中（图示4）。当任务确定后，团队成员可以自愿承担任务，在考虑任务间依赖关系和次序的情况下，给每一项任务估算时间，并保证每一个人的工作量合理。在此流程中将会和产品所有者有往复交流，阐明要点，核实交易，将较大型Backlog 分割成小块，并保证开发团队真正全面了解开发的需求。开发团队将按Product Backlog 序列继续计划，直至消耗所有可利用时间。在会议的末期，开发团队将提供所有任务的列表，并写明每一项工作由谁完成和他们的估算时间（一般以小时计算或每天的一小部分）。许多开发团队也使用可视任务跟踪工具，利用墙体面积大小的任务板，任务（写在便签上）在Sprint 中跨越栏目，“未开始”，“在进行”，“需校验”，和“已完成”。



Scrum 的重要支柱之一是当Scrum 开发团队确认承诺任务后，产品所有者在此Sprint 期间不可以添加新的需求。这就意味着即使在Sprint 中途，产品所有者想要添加新要求，他或她在下一新的Sprint 开始前不可能作出任何变更的决定。如果一个外部情况出现致使项目优先级的变化，意味着如果开发团队按原计划工作将会是浪费时间，产品所有者此时可以结束该Sprint；意味着开发团队停止一切工作，重新开始Sprint 计划会议等等。此种决断会产生很大的影响,除非在非常特别情况下，不会采用这种方式。

保证开发团队在Sprint 中目标不被变换有着正面影响。首先，开发团队确信在工作开始时的承诺是不会变化，这样会集中开发团队的注意力。第二，这样也可以培养产品所有者在安排Product Backlog 中项目的优先权时，适时作出正确的抉择。他们知道任务的承诺是在整个Sprint 中不可变更的，使其在决定从哪一项目开始工作更为细心。

作为回报，产品所有者也可以得到两个好处。首先，他或她有充分的信心，开发团队对所承诺任务强烈负责，并随着时间推移，Scrum 开发团队将会做的很好。第二，产品所有者可以在下一Sprint 开始前，提出他或她希望的变动。在这一点上，增加条件，删减条件，更改条件和重新排列优先权都可以被接受。但产品所有者不可以在Sprint 进行中提出任何变更，他或她只是需要等待一个Sprint 的完成时间或更短。不再僵持于是否变化——方向的变更，条件的变更，或只是简单的想法的变更——可能正式此原因，使得产品所有者成为Scrum 拥护者中最热衷的成员。
阅读详细......

敏捷精灵日记15

[敏捷精灵日记]

• 为Sprint中任务给出明确的”DONE” 定义是非常重要的，但即使你遵循这个最佳实践，但最终仍然会有集成问题，会存在Bug, 以及晚期的需求变更。所以，在正式发布前，单独计划1-2个Sprint, 专门做Bug修复，是非常合理的，并不是“反Scrum”的模式。

阅读详细......

Scrum介绍系列3--- 如何启动Scrum

Scrum 的第一步是产品所有者清晰地展示产品的未来景象（vision）。这些是以按需求的优先列表展示的，按客户和商业价值排序，最高价值的项目排在列表顶端。这就是Product Backlog,它存在（并发展）于产品的整个生命周期（图示2）。Product Backlog 包括许多的不同项目，例如功能（“使用户可以把所选书籍放入购物车”），开发需求（“重新改进处理流程模块，使其可以升级”），探索式的工作（“研究关于加速信用卡确认过程的方法”），和已知的bugs（“判断并修复定单流程中的错误”）。

Product Backlog 是由产品所有者随时更新，以反映客户需求的变化，竞争对手的发布，新的想法和见识，出现的技术障碍等等。



在项目开发的任何时候，Product Backlog 是唯一具有权威性的“需要完成的所有任务”的概况。只可以存在唯一一个Product Backlog；这就意味着产品所有者需要在所有的工作范围中作出优先项的决策。

Product Backlog 中的项目在规模上会相差甚远；有些大的项目通常在Sprint 计划会议上被划分为许多较小的项目，而小的项目有些会被合并为一。关于Scrum 的误解之一是它会阻止你记录详细的规范说明；而现实中，这是由产品所有者和开发团队共同决定详细资料的多少，这些从其中一个Product Backlog 到另一个有可能存在不同。一般的建议是，在所需的最少的空间中说明最重要的事情——换而言之，不需要描述某一项目的所有可能的详细资料，只需要阐述清楚产品被认为是完成品所具备的要求。在Product Backlog 列表中越底端的是更大和粗略的项目；当它们接近被开发时，产品所有者会添加更多的详细资料。
阅读详细......

Scrum介绍系列2--- Scrum 中的角色

在Scrum 中有三个基本的角色：产品所有者，开发团队成员和ScrumMaster。

产品所有者（Product Owner）负责收集相关于产品的所有信息——从客户或产品的终端使用者，开发团队成员和项目管理者中获取——并将信息转化为产品的形式。在一些情况下，产品所有者正是客户本人；在另一些情况下，客户可能是有不同需求的成百上千的人。产品所有者这一角色在许多企业中是由产品经理或产品市场经理担任。

开发团队成员构建客户将会购买的产品：软件，网站，或者是任何一种产品。Scrum 团队通常包括五到十个成员，尽管团队大到15 个成员和小到3 个成员也有很好的收效。团队应该包括所有交付工作所需的专门人员——例如，一个软件项目的开发团队包括程序员，界面设计师，检测员，市场人员和研究人员。开发团队不仅构建产品，他们也向产品所有者提供让产品尽善尽美的建议和想法。开发项目包括15 个或以上的人员时，通常会被划分为若干的Scrum 团队，每一团队注重于产品开发的不同方面，并相互紧密的协作。团队成员同时可以参与其他项目开发，这样比只限制开发团队致力于Scrum 更能提高生产效率。团队内部成员也可以在不同Sprint 中变化，但是这样会减少整个团队的生产效率。

ScrumMaster 的任务是以任何方式帮助整个团队取得成功。ScrumMaster 不是团队中的经理；他或她是服务于整个团队，帮助团队铲除壁垒而取得成功。协助团队会议，并支持Scrum 的实践。在一些团队中会有某一人专心致力于担任ScrumMaster，而另一些团队可以是其中一个成员兼职担任（此人会适当减少日常工作量）。一个好的ScrumMaster 可以有不同的背景和学科：项目管理，工程技术，设计，检测。ScrumMaster 和产品所有者不应是同一人；有时，ScrumMaster 可能会号召拒绝产品所有者（例如，他们有时会在某一Sprint 中期试图加入新的条件）的要求。不同于项目经理，ScrumMaster 不会指示和分配工作——他们只是协助流程的实施，推动团队自我组织和管理。

除以上三个角色之外，还有其他对于项目成功作出重要贡献的人员：可能其中最重要的是经理。他们的角色在Scrum 中的发展, 他们仍保持了相当重要的位置——他们支持开发团队使用Scrum，他们为整个项目的开发提供知识，技术和各种必要的协助。在Scrum 中，这些人转化了以前“保姆”式的角色（布置任务，收取进程报告，和其他一些谨小慎微的管理方式），取而代之的是承担起更多的“指导“作用（指导职业发展，在职辅导培训，扮演魔鬼的代言人，协助铲除障碍，帮助解决问题，提供创新的建议和指导团队成员的技能发展）。为了能更好地实现这一变化，经理们需要改进他们的管理方式方法；比如，运用苏格拉底哲学提问方式来帮助开发团队找寻问题的解决办法，而不是简单地决定解决方法并分配给开发团队。
阅读详细......

敏捷精灵日记14

[敏捷精灵日记]

1. 无论一个测试人员有没有发现Bug，都不能说明他有没有好好工作。测试人员的职责更多的应该是‘保证质量’（quality assurance），而不是“控制质量”（quality control）。一个好的测试人员应该是在问题出现之前，防止其成为Bug。
2. 对于一个敏捷团队而言，再单纯以测试人员发现的Bug数量，作为衡量其绩效的唯一标准，是非常没有意义的。
3. 如果有一个核心测试集，能够覆盖用户如何使用一个产品的常用情形，会更有价值。对所有用户使用情形都做自动化测试是没有必要的。

阅读详细......

Scrum介绍系列1--- 基础知识

Scrum 是迭代的，增量型的流程。
Scrum 构造的产品迭代周期为Sprints, 工作的迭代时间一般为一到四周。Sprints 是有固定的周期——结束于固定明确的日期，无论该工作完成与否，从不延长。
在每一Sprint 的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，并承诺在Sprint 的末期完成这些项目。
每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示图表。在Sprint 的末期，团队将对这一阶段工作结果作一展示并取得相关的反馈，为下一Sprint 做好准备。

Scrum 强调生产可以使用的产品，意指在Sprint 的末期产品的“完成”；在软件方面，是指编码已经被检测并可以随时交付使用。
阅读详细......

Scrum方法Agile (敏捷) 开发和 vs 传统的软件开发

传统的软件开发

各类大中小型企业所运用的传统软件构建方法，即是众人在很多变体，但其典型性是在开发初期制定详细的计划，计，并且一切详细资料都记录在案。任务已设计制定，并工具和Microsoft Project 项目管理软件。开发团队预计开发而得出的。当项目管理者(stakeholder)全面审核开发计划并团队成员完成他们所专长的部分工作，即刻转交给其他成工作都已完成，成品将会转交给产品质量控制部门，在这的全面检测。在整个流程中，所有相对于原始计划的分歧成品与原始设计保持一致。

此种模式有优点但也有不足之处。它的最大的优点是非常记录下来，按照计划实施，保持各项事务尽可能的有组织参与,人对于此种工作方式并不适合。

比如：此种方式要求所有的建议和想法都要在开发周期的可以被容入开发计划之中。但是众所周知，好的想法和建开发最启始阶段，在开发中期，有时可以在产品交付使用许变化的产生，那么将会遏制创新的产生。在使用“瀑布新将不是好的征兆，而是对整个产品开发产生的危机。

瀑布型开发方式特别注重将事件记录在案，以此作为传递重要信息的首要方法。因此最合理的假定是如果我可以把我的想法尽可能都记录下来，这样将会使信息更可靠的传输到团队每一个
成员的头脑中；另外，因为所有东西都记录在案，这将是我完成任务的最实际的证据。但是实
际上，在大多数情况下，没人会读这些100 页左右的详细规格要求资料。同样，如果有人读取
该资料，那么将会产生许多的误解。记录的资料只是我头脑中想法的抽象提取；当你阅读此资
料时，你将会产生另一个抽象的概念，此时与我的真正想法已经相距甚远了。所以严重误解的
产生也就不足为奇了。

当人参与时,还有一种情况会发生——“实际应用中产生的灵感”——在第一次实际应用产品
时，你可能会立刻产生20 种方法以使产品更加完美的灵感。但是遗憾的是，这些非常有价值的
想法通常会在产品开发的末期产生，这时创新是最困难和最具有分裂性的——换句话说，是做
正确抉择最昂贵的时刻。

人的预知未来的能力是有限的。比如，某场比赛的最终结果是出人意料的。不可预测的技术问题的突然出现，会强制开发方向的转变。此外，人们往往非常欠缺对于未来作出长远计划的能
力——今天猜测未来八个月中每周你如何工作将如幻觉般渺茫，这正是Gantt (根特)图表的衰败
表现。

另外，瀑布型方式将会促使团队成员在交接工作时产生敌对的关系。“他要求我构建在规范要
求中不存在的东西。”“她经常改变主意。”“我不可能对我不能控制的东西负任何的责任。”这些指引我们对瀑布方式的另一思考——在此种方式中工作毫无兴趣可言。事实上，进一步说，瀑布型方式是造成产品开发人员苦恼的根源，并且最终产品将不会体现出他们的创造力，技能和开发创造者的激情。人不是机器人，此种将人认为是机器人的流程将会造成人们工作激情的丧失。

一个僵硬的，拒绝变革的流程也会造成低劣产品的产生。客户可能会得到根据他们第一需求所生产的产品，但是在产品在形成阶段时还是客户真正需要的吗？在开发之前收集所有的需求并
将它们嵌入毫无改变可言的顽石般的计划中，此产品将被宣告只会和最起始的想法保持一致，
而不是开发团队在实践中不断发现可能性而使其尽善尽美。

许多使用瀑布型方式的团队不断的体验到了它的缺陷，但是它看起来是一个极其付有逻辑性的方式，所以第一的自然反应就是对内部工作的谴责：“如果我们尝试更好的使用它，它将会发
挥作用”——如果我们计划的更详尽，记录更详细，更严格的拒绝任何变革，一切将会很顺利
地进行。遗憾的是，许多开发团队只得到的相反的效果：他们越竭尽全力尝试此方法，得到的
结果越差！

Agile (敏捷) 开发和Scrum

Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况, 以便取得更好效果的信念上。Agile 强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。
Agile 注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile 注重快速
迭代，并且其中结合尽可能多的客户反馈。在学习了解Agile 的时候，经常会有这样的公认——感觉非常像回到了开发启始的阶段，我们曾经”做过”。

Scrum 是众多快速发展的Agile 方式之一。Scrum 是在十多年前由Ken Schwaber 和Jeff
Sutherland 博士共同提出的，现在此方式已被众多大中小型企业使用，其中包括Yahoo! ,
Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE Medical, CapitalOne 和 US Federal Reserve. 许多使用Scrum 的团队取得了重大的改进，其中更有个别在生产效率和职业道德方面得到了彻底地改革。对于产品开发者——许多曾受到“管理层每月的一时狂热”的伤害——这
是非常重要的。Scrum 是简单的，强有力的，并立足于常识之中的。



阅读详细......