文章

Scrumcn_scrum

Scrum vs 持续部署

/分类： /编辑：

产品开发需要持续性

Scrum的基本思想就是给团队一个安全的和没有变更的环境，让团队可以集中在计划好的开发任务上。一般来说，团队为两周左右的一个Sprint做好计划，然后在Sprint当中不应该被打断，直到当前Sprint结束。这样的流程能够避免了“新的==重要的”的情况发生，能够保证当前的事情能够完成，也能够避免大家认为新的想法就一定比一个月前提出的想法要重要得多的问题。要在产品特性开发上获得成功，就需要稳定的特性优先级。 Read more →

scrumcn_work

“未完成工作”没那么糟糕

/分类： /编辑：

我偶尔会听到一些比较冒失的言论—在sprint结束时还遗留了未完成的工作是非常糟糕的，应该严格禁止。 我能理解未完成工作的危险性，也从不反对敏捷宣言中关于可工作软件的价值观，但是，我还是要说这个言论是错的。 真正危险的不是未完成的工作，而是未完成工作的不断累积。 Read more →

ScrumMaster – 指派还是团队选择？

/分类： /编辑：

一个新Scrum团队对ScrumMaster的选择会影响到团队Scrum实施的成败。选错了人，团队就会一方面试图变得自组织、另一面却又受制于命令控制型的经理，从而进退两难。选对了人，他符合新ScrumMaster的技能、满足团队初期需求，则团队在实施Scrum上有了一个梦幻般的开端。 Read more →

Scrum团队中的架构师

/分类： /编辑：

 很多架构师在努力了很多年才得到这个威严的头衔“架构师”。他们确实应该为他们的知识、经历和能针对技术和业务挑战提出一流的解决方案的能力而骄傲。我发现很多架构师在面临采用Scrum时提出的担忧可以归纳为下面2类：

•大家仍会按照我告诉他们的架构去做实现吗？

•我如何能在没有一个提前设计架构的阶段后保证我们构建了一个架构不错的产品？

Read more →

将用户故事分解为任务

/分类： /编辑：

将用户故事分解为任务没有什么捷径，许多的开发者在他们的工作当中也一直在做类似的事情-将需求分解为任务。由于放到Sprint当中的用户故事的规模已经比较小了，所以有些人认为已经没有必要在进行分解。那么为何还要对用户故事进行任务的分解呢？

尽管用户故事的确可以小到作为工作的单位，但是将他分解为更小的任务，通常跟符合项目的需要，主要表现在如下三个方面：
Read more →

Sprint ≠ 小型瀑布

/分类： /编辑：

当别人告诉我“Sprint是一个小型瀑布”时，我马上回应“不是”。我经常这样做，因为我经常听到刚接触敏捷的人这样说，甚至也听到有些已经在项目中运用敏捷开发方法的团队也这样说。在这篇文章中，我们用5个推论来证实Sprint不是一个小型的瀑布。它们是：持续的设计、开发、集成和测试；跨职能团队成员； Sprint期间不允许变更；时间盒；严格定义的开发节奏。 Read more →

使每日站会的价值最大化

/分类： /编辑：

在最近过去的几年中，我在许多不同的每日站会中担任过参与者和协助者的角色。众所周知，每日站会的真正价值在于团队有能力不断地为当前的sprint周期的“承诺”而努力。每日站会并不是状态汇报，现在团队成员经常很容易陷入提供状态相关信息的这样一种模式。近期虽然我正在使用一种最老的每日站会的方法，但我认为一个成熟的团队可以从不同的程度来花费15分钟做这些事情，与此同时他也继续在进化使用敏捷/Scrum。
Read more →

把客户融入进来

/分类： /编辑：

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

Read more →