文章

谁将抵触Scrum转型

/分类： /编辑：

在1969年《Harvard Business Review》的一篇文章中，Paul Lawrence提到变革“既有技术上的变革也有社会关系的变革。技术方面的变革由日常工作中可衡量的变化组成。而社会关系的变革将影响到企业内已经形成的各种关系。”当我们面对抵触的时候，我们倾向于强调技术上的变革带来的好处。毕竟，我们已经说服了自己，所以我们很容易假设现在所有要做的就是说服别人。我们会认为，只要列出对变革有利的完美知识论据，人们的抵触将会消失。Lawrence反对这种错误的逻辑，“有时，我们可能希望技术上的变革的正确性是它的可接受性的唯一决定因素，但事实上，社会关系的变革才决定了抵触是否存在。”（1969，7） Read more →

小团队试点，还是全面转型

/分类： /编辑：

按照惯例，向Scrum或者任何一个敏捷过程转型，长期以来，通常的建议是以一个试点项目作为开始，从中吸取经验教训，然后在企业范围推广。这个方法就是我们经常使用的小团队试点（start-small）模式，使用这个模式时，企业往往选择一到三个有代表性的团队，每个团队人数控制在五到九个，让这些团队取得成功，然后以此为基础推广Scrum。 Read more →

他山之石，不可攻玉

/分类： /编辑：

在一次行业聚会上，又一次遇到了李剑,和他开玩笑：
……
我：你翻译的这本书（《硝烟弥漫中的Scrum和XP 》）害了好多人。
李剑：呵呵， 我知道，我道歉。@# ￥ # ￥ %… ，很多人把这个当成了敏捷…
我：哈哈… ，关键它太流行了。你现在成敏捷的罪人了，你竟然一下子送给了我们公司   5本。
李剑： @#￥ # ￥ % …… Read more →

自上而下的Scrum实施

/分类： /编辑：

Scrum存在的头14年里，Scrum的实施主要是自下而上进行的。也就是说，一个开发团队可能开始使用了Scrum。它的客户会在一个月末就能看到可工作的软件。这个客户会欣喜若狂，以至于告诉她的伙伴经理。那个伙伴经理会问他的开发团队为什么不使用Scrum？这个团队于是也开始转变到Scrum。一个团队接一个团队，一个客户接一个客户，整个组织将使用Scrum改变自己并变得敏捷。就是这样开始了改变。
Read more →

Mike的Scrum实施日记 – 这个故事太大了

/分类： /编辑：

今天是第一个Sprint计划日，早上10点，所有的人都准时来到了会议室。
“好了，大家都知道今天我们要干什么。” 我开始了会议，“请每个人拿一副估算扑克。”
每个人都从我手里拿了一幅扑克，开始在手里把玩，一个个好像都是Show Hand高手。
“请Product Owner先把她希望在这次Sprint中开发的用户故事说明一下。” 我按照会议的流程开始了第一项内容。 Read more →

Mike的Scrum实施日记 – 一切从零开始

/分类： /编辑：

 又一个项目要开始试用Scrum了。
这个项目前期已经讨论了很长的时间，为什么选择Scrum？主要原因就是新的产品特性的一些具体的细节一直确定不下来，老美那边的产品经理们一直争论不休，又拿不出个具体的方案。而按照现行的流程，一定要需求确定后，产品设计组才能给出具体而详细的设计文档（包括产品功能的流程，UI的设计等等），然后，开发人员才能在此基础上做软件设计和开发，唉。。。，很标准的瀑布开发流程。所以，现在开发团队就在那里干瞪眼等着，Manager们也只能讨论，讨论，在讨论。。。。。。
Read more →

Scrum实践中遇到的问题

/分类： /编辑：

影响scrum不能正常实施的因素

scrum的失败或者效果不理想通常由以下因素造成：

  1. 对未知结果的恐惧心理。出于习惯，大多数人更愿意事先得到一个固定的最终发布日期和一个承诺的结果，哪怕到了日期无法得到结果再延期。我们常常都需要这样的心理安慰，宁愿把苦头放在后面而不愿正视软件开发的规律。
  2. 在sprint过程中加入新需求的诱惑。很难很难抵御这样的诱惑，scrum第一杀手。
  3. 不愿意调整目标而任意延长sprint的时间。不知不觉你就又回到了老路上。
  4. 急于看到结果而压缩sprint的时间。能得到一定的效果，但总体上消耗的更多的资源。我们曾经一度这样做，每周末完成一个可以审查的结果，很有效，但很累人，在整合上花了太多的力气。

Read more →