hanqunfeng的专栏

1.产品BackLog2.对于BackLog的估算3.燃尽图--burndown4.了解团队的生产率5.掌握scrum众多的基础实践Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短，有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的...

我们采用jira来做bug跟踪系统，同时会将backlog与拆分的任务维护在jira上。我们每一次sprint都会经历需求确认，开发，测试，部署上线的完整流程。如果在到达发布日期时仍有没有修复的bug该如何处理呢？一般来说应该对每一个bug进行分析，如果不属于严重bug，则可以结束当前的sprint，否则当前的sprint宣告失败，需要重新进行评估。如果在下一次sprint中包...

我们怎样让别人了解我们的sprint呢？我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。可以使用wiki记录下当前的sprint信息，然后使用邮件告知相关人员。sprint信息应该至少包含如下信息:...

任务板分为四列：第一列：尚未开始的backlog及其任务，每个任务要有预估并制定负责人；第二列：已经开始的backlog及其任务；第三列：已经完成的backlog及其任务；第四列：燃尽图和未计划任务及可编入任务。未计划任务：在计划中没有包含的任务，有可能是在分解backlog时没有分解完全，也有可能是一些突发任务，亦或是技术任务。这部分在做回顾时要重点讨论发生的原因，因为它...

通用方程为1个有效的人-天=6个有效的人-小时。为什么不用人-小时，原因在于：人-小时的粒度太细了，它会导致太多小到1-2个小时的任务出现，然后就会引发微观管理。最后发现实际上每个人还是按照人-天的方式来思考，只是在填写数据时把它乘6就得到了人-小时。“嗯……这个任务要花一天。哦对，我要写小时数，那我就写6小时好了。”两种不同的单位会导致混乱。“这个估算的单...

1.怎样布置团队房间？最好独立，封闭，不受外界干扰，总之要使团队感到舒服。任务板：每日进行更新设计板：用于团队讨论设计流程2.团队为何要坐在一起？便于交流，交流很重要。“一起”意味着：• 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。• 互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。• 隔离：如果你们整个...

例会应该控制在10分钟以内，做到这一点，只需在例会中问三个问题：1.昨天做了什么？2.今天计划做什么？3.有什么困难或是否需要他人协助？例会中除了以上三个问题外，scrum master还要做如下的事情：1.更新任务板（根据以上三个问题）2.处理迟到的家伙3.处理“我不知道今天干什么”的情况2和3没有固定的答案，可以根据团队的实际情况进行制定，比如2可以罚款，3可以增加任务...

应该让团队中的每个成员都进行演示，即便他这次说的不好，那么下一次，他一定会提前准备好的，这对他主动地理解业务是很有帮助的。一次做得不错的演示，即使看上去很一般，也会带来深远影响。团队的成果得到认可。他们会感觉很好。其他人可以了解你的团队在做些什么。演示可以吸引相关干系人的注意，并得到重要反馈。演示是（或者说应该是）一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。...

坚持要做回顾，在有关回顾的种种一切中，最重要的就是确保回顾能够进行。回顾是Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！如果没有回顾，你就会发现团队在不断重犯同样的错误。我们如何组织回顾？• 根据要讨论的内容范围，设定时间为1至3个小时。• 参与者：产品负责人，整个团队还有我自己。• 我们换到一个封闭的房间中，或者...

回顾中发现的问题示例：1.“我们应花更多时间，把故事拆分成更小的条目和任务”这个问题很普遍。每天的例会上，都会有人说“我真的不知道今天该干什么”。所以在每一个例会之后，你都要花些时间来找出具体任务。通常这些事情提前做会更有效率。典型动作：无。团队很可能会在下一个sprint计划会议上自己解决掉这个问题。如果它重复出现的话，就延长sprint计划会议的时间。2.“太...

技术故事：或者叫做非功能性条目，或者你想叫它什么都行。是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。比如系统的公共组件，代码重构等等，这些并不能给项目负责人带来之际的可交付物，但会对项目的稳定性和提高效率有很大的作用，这些技术故事往往容易被项目负责人所忽视，因为他们更注重实际上看得到摸得着的东西。作为一个技术经理，必须要保证系统的开发...

优先级1：sprint目标和演示日期。这是启动sprint最起码应该有的东西。团队有一个目标，一个结束日期，然后就可以马上根据产品backlog开始工作。没错，这是不像话，你应该认真考虑一下明天再开个新的sprint 计划会议。不过如果确实需要马上启动sprint，不妨先这么着吧。认真说来，只有这么点儿信息就开始sprint，我还从来没有试过。优先级2：经过团队认可、要添加到这个sprin...

“任务”和“故事”的区别是什么呢？嗯，这个问题问得不错。区别很简单。故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。故事如果太大就应该进行拆分，力求保证故事的大小在2至8个人-天之间。否则不好控制。例子：故事拆分为多个故事故事拆分为任务我们会看到一些很有趣的现象：• 新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。...

先来看一个时间表：Sprint 计划会议：• 13:00 – 17:00 （每小时休息10分钟）• 13:00 – 13:30。产品负责人对sprint目标进行总体介绍，概括产品backlog。定下演示的时间地点。• 13:30 – 15:00。团队估算时间，在必要的情况下拆分backlog条目。产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的backlog条目都要填写...

1.范围（scope）2.重要性（importance）3.估算（estimate）范围（scope）和重要性（importance）由产品负责人设置。估算（estimate）由团队设置。在sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化。质量：质量分为外部质量和内部质量• 外部质量是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属...

sprint应该多长才好？嗯，时间短就好。公司会因此而变得“敏捷”，有利于随机应变。短的sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错误方向上花的时间更少=学习和改进的速度更快，众多好处接踵而来。但是，时间长的sprint也不错。团队可以有更多时间充分准备、解决发生的问题、继续达成sprint目标，你也不会被接二连三的sprint 计划会议、演示等等压得不堪重负。产品负...

出于某些原因，制定sprint目标确实很困难。但我发现即使是像挤牙膏一样把它挤出来，那也是值得的。半死不活的目标也比啥都没有强。这个目标可以是“挣更多的钱”，或者“完成优先级排到最前面的三个故事”，或“打动CEO”，或“把系统做的足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。它必须用业务术语表达，而不是技术词汇，让团队以外的人也能够理解。Spr...

1.一般来说使用故事点（story points）来作为估算的依据，一个故事点就是一个理想的人/天；2.由开发团队对每个backlog条目进行预估，比如backlogA需要3个story points，backlogB需要4个story points，等等；3.由项目负责人制定每个backlog的优先级，并排序；4.由开发团队从中选择能够完成的backlog加入到sprint back...

在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。那么该如何实际操作呢？推荐使用索引卡，把它们贴在墙上或摆放在桌子上。示例如下：这种用户体验比计算机和投影仪好得多。原因是： 大家站起来四处走动=> 他们可以更长时间地保持清醒，并留心会议进展。 他们有更多的个人参与感（而不是只...

单独用一篇文章介绍足以说明它的重要性。一定要在完成sprint计划会议前定义好每个故事的完成含义，并在项目团队中达成共识。比如说测试通过，或者部署上线，总之要有一个完成的定义。...

估算是一项团队活动——通常每个成员都会参与所有故事的估算。为啥要每个人都参加？ 在计划的时候，我们一般都还不知道到底谁会来实现哪个故事的哪个部分。 每个故事一般有好几个人参与，也包括不同类型的专长（用户界面设计、编程、测试、等等）。 团队成员必须要对故事内容有一定的理解才能进行估算。要求每个人都做估算，我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础，也...

在明确故事内容时一定要向产品负责人如何进行演示，因为这很可能会决定你开发的方式，也间接的影响到了你对故事的时间估算。例1：团队和产品负责人都对sprint计划很满意，打算结束会议。这时Scrum master问了一个问题，“等一下，还有个‘添加用户’的故事没有估算时间呢，把它解决了吧！”几轮计划纸牌以后，团队意见达成一致，认为这个故事需要20个故事点；产品负责人却站了起来，说话因为生气也走了调...

sprint之间的休整时刻是指上一个sprint结束到下一个sprint开始之间的时间。保证不在同一天举行sprint回顾和下一个sprint计划会议。在启动新的sprint之前，每个人都应该至少度过一个不需要考虑sprint的夜晚。...