交付客户与用户故事

在敏捷十二原则中，第一条原则是以客户为主体而提出的： “我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。”

• “满足客户”强调以 客户的意见、态度为产品交付标准； 
• “尽早”强调 产品开发过程中的时间成本，保证产品质量的前提下以更加迅速、快捷的标准进行产品交付；
• “持续交付”强调 团队与客户之间的沟通及互动，这是产品研发过程中的催化剂以及粘合剂。

因此，在针对与客户的交互、沟通中，敏捷开发将客户的要求、个体的发展、团队的协作结合起来，纳为所应当遵循的第一原则。《敏捷宣言》的参与者之一Dave Thomas就强调，开发过程应崇尚“实效敏捷”，以务实、实效的精神关注并带给客户真正的价值。

雪鸟会议过后，国内外信息传播速度飞快。尤其是在近几年，在国内一些媒体的推动、企业的实践下，很多人对敏捷已经有了较为深刻的认识，越来越多的团队开始进行敏捷转型。

因此， 敏捷由一种小众词汇，逐渐成为主流思想。敏捷作为一种方法论，它可以应用在不同的领域，包括金融、电信、证券和互联网，也包括传统的能源行业，只是互相之间需求程度不太一样。相比而言，电信、金融等接触新鲜事物较快的行业发展也较为迅速，但石油等传统能源行业接受新鲜事物较慢，因此发展速度也相对缓慢。

总之，敏捷主要应用于技术开发领域，但在这一领域，各个公司、团队在落实敏捷的过程中，大多都走了弯路。

敏捷并非单纯是一套工作规范，也不只是一个辅助工具。 它真正强调的是开发过程中的群智涌现、高效的团队协作以及与客户的沟通交流。在此我们首先关注客户要求，做到使客户满意。

在实际的实践过程中，敏捷开发团队选择整个团队拟定一些实践方式，如用哪些工具、质量目标、客户需求、每天的核心工作时间等等，将流程记录下来。在共同目标的带动下，会促使团队内每个人主动自我反思、自我提高，事情就好办多了。一旦这些条款需要更新，会在下次会议中提出，达到大家一致同意后，再进行更新。当团队加入新人的时候，他们会得到最新最规范的内容。

在这样的前提下，团队确定用户故事，才能更好地为客户进行产品开发。

用户故事应遵循的原则：

• 用户故事遵循 独立性原则：

用户故事之间要有空间，保持他们的独立性。独立性使得在进行产品计划制定的时候，团队思路更加清晰，也便于团队在开发过程中进行跟踪、测试以及迭代交付。

• 用户故事遵循 可协商原则：

用户需求是在开发过程中，团队与用户不断进行交流、碰撞而逐渐完善、细化的。用户故事不可修改，最终会导致产品无用化，而一个用户故事带有了太多的细节，实际上限制了用户、团队的想法和沟通。

• 用户故事遵循 有价值原则：

每个故事必须对客户具有价值（无论是用户、购买方还是公司内部角色）。用户故事对于最终的用户是有价值的，因此应该站在用户的角度去编写，而不应该仅仅把它当做任务看待。

• 用户故事遵循 可评估原则：

在计划会议中，团队要对用户故事进行一个估计，使团队在任务开始前能够对用户故事有一个大致了解。

• 用户故事遵循 小单元原则：

一个好的故事在工作量上要尽量是一个小周期，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

• 用户故事遵循 可测试原则：

一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。