文章

敏捷体验设计工作坊模版

/分类： /编辑：

和以往的那种简单粗暴的“头脑风暴”，或者索然无味的“需求评审”不同，敏捷体验设计中的过程永远是开放的，强调在和客户的互动中识别需求，并产出设计，最终对项目交付内容达成共识。过去的五年里，我参与了几十次和客户的设计工作坊，这里把我经常使用的五种设计工作坊形式分享给大家。
Read more →

PMO在scrum中的角色

/分类： /编辑：

参与并支持向Scrum转型的项目管理办公室（Project Management Office，PMO），对于Scrum团队来说，将是一个极大的福音。PMO的成员常将他们看作是一项实践的保护者和支持者，所以PMO能帮助在组织内实施和扩大敏捷实践。但是，当PMO不恰当地参与时，PMO也是抵制的来源，因为它会尝试保护当前的流程，而不是改善它。

PMO大部分人的自然反应是抵制Scrum转型其中一个原因是个人和职业的恐惧。Scrum将传统的项目管理责任分散到ScrumMaster、产品负责人和团队，留给项目经理来思考他们的角色是什么。在大部分Scrum和敏捷著作中PMO的缺失，也增加了PMO成员很自然的担心。

我们将考虑PMO在下面3个方面的贡献和工作：人员、项目和过程。
Read more →

编写文档真的是在浪费时间吗？

/分类： /编辑：

我最近留意到，在敏捷开发中存在着一个广为流传的谣言——“敏捷中没有文档”或者说“编写文档就是浪费时间”。特别是在从瀑布式向敏捷转型的过程中，我们感受到典型敏捷实践给我们带来的好处，例如：短周期的迭代、时间盒、每日站会、回顾会议等等。这也导致了我们希望放弃在应用敏捷之前的一些习惯：编写文档、给代码加注释等等。但是，我们完全不写文档和注释真的是对的吗？ Read more →

敏捷工作方式如何签署合同?

/分类： /编辑：

对于敏捷方法，人们常常提出这样的问题：“如果基于敏捷工作方式，应该如何签署合同？”

传统的瀑布式模型，与公司采购的方式完全契合：先整理出需求，一家供应商提供一个报价（基于他们对需求的阐释和对成本的估计），大家都签署一个法律上的捆绑协议。
Read more →

事物不断变化（流程也需调整）

/分类： /编辑：

Jonathan Kohl是一位咨询顾问、作家和知名博主，他提出了这样的观点：时下团队在工作中身处的或正在构建的技术环境，与过去那些曾诞生了许多通用开发流程的环境已经有了很大不同。他鼓励团队在检查流程时保持清醒和活跃，并让自己做好准备，以能够适应当今他们工作中身处的现实。
Read more →

把客户融入进来

/分类： /编辑：

最近我写了一篇文章，并用反问作为标题：“客户是否已经为敏捷做好准备？”这个想法来源于在软件开发组织已经遵循了瀑布方法学太久的事实，以至于它已经在客户，他们的规划管理办公室和IT部门的灵魂中根深蒂固了。

Read more →

三思而后行

/分类： /编辑：

没有敏捷经验的团队成员经常抵制对项目采用这种框架。或许他们含糊地听过一些敏捷的实践，并且他们自己总结。然后我们越强烈的坚持这个实践，他们就越抵制我们所遭遇的。

这通常发生在我们尝试介绍这个（或任何）实践，而没有给团队时间来理解时间背后的真正原理。一位对敏捷感兴趣的项目经理想在他的下个项目中采用敏捷，就像这样。常用的方法是像团队简单地介绍基本原理，然后立马开始使用这些原理。通过召集工作场所的人，并且和他们交谈，或者尝试开每日站会，这些都是不规范的。
Read more →

敏捷能够用在支持和维护上面吗?

/分类： /编辑：

敏捷已经从一个宣言演变成为一项业界标准。多数的软件厂商都在应用敏捷来解决瀑布式中导致的诸多问题。简而言之，使用固定时间长度的sprint来达成预先设定好的目标以及敏捷所主张的整个实施风格能够解决软件项目中痛处。因此，很多软件开发商都使用敏捷，并且通过做项目计划让他们的客户也参与到敏捷当中来。 Read more →

他山之石，不可攻玉

/分类： /编辑：

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