摘要：这是用户故事系列的第九篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九） 产品负责人常常被描述成在计划会前准备好用户故事，在计划会上讲解并帮助开发团队估算后就万事大吉，只等月底接收“可工作软件”的样子，其实如果真的这样，很容易出问题。需求精化这是发生在迭代周期中间的常规活动，产品负责人会与团队密切接触（确切说如果能经常坐在一起更好），在每个故事开发的前夜或中间，将之前讲解过的用户故事更详细地描述一番（有时候是在看到开发一半的半成品后做一些细化或更正）。一般认为产品负责人在开发的中间来打扰开发组工作是不令人欢迎的行为，那这两者之间到底区别何在呢？在以后将会编写的一个《敏捷开发产品管理》 阅读全文

摘要：这是用户故事系列的第八篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九） 要想不在评审会上得到“惊喜”，Product Owner最好提前约定好用户故事的验收标准，而且每个用户故事可能各不相同。面向客户价值设定验收标准简单说，就是客户看到说“完成了”，才算完成了。从这一点上说，用户眼中的“可工作软件”和我们认为“可以运行，自动化测试了的，没有缺陷的”软件还是有差别的。用户拿到软件，是要使用从而获得价值的，这常常需要多个功能联合运行，前后数据完整一致才可以做到。在“敏捷产品管理”系列中，还会更加深入地探讨这个话题。下面的例子，很好地表明了客户眼中的完成标准，它是EA（电子艺界，世界最大 阅读全文

摘要：这是用户故事系列的第七篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）用户故事和MVC没有关系，因为MVC是实现方法，因此在思考用户故事的时候，不要一下就想到实现方法，很容易把故事写坏。但是MVC和用户故事有很大的关系，如果用户故事写好了，做MVC的时候，一定要记得参考用户故事。本人在C++的年代用过MVC，但那个时候MVC还只是一种编程思想，说用了也行，说没用也行。但到了C#之后，就出现了正牌的自称是MVC的东西（现在最新版本是MVC3），本人也在用。Java世界也有MVC的概念，但是没有见识过，下文中所描述的MVC，若没有特殊说明，均指Asp.net MVC；但相信对Java中 阅读全文

摘要：这是用户故事系列的第六篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）一条需求敢跳出来，基本上就能被化成一条用户故事，看完一二三四五，上山打老虎都不怕，这个似乎已经不太难了。难的是，项目或产品的第一天，给一张白纸：“请列出有哪些故事”。那个时候其实不是大脑空空，而是有千言万语就是说不出。前年做另外一件事情的时候偶然得到一种方法，去年到今年用在一个敏捷项目上，果然很舒服地列出了大量故事，后来的开发过程证实它们都满足独立交付、可测试、耦合低等特点，属于好故事之列。引子这件事情其实在之前的博客中已经多次提到了，就是软件项目的造价管理。注意这里提到的是项目，而非产品研发。项目就是那种一手交 阅读全文

摘要：这是敏捷开发用户故事系列的第五篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）引子在之一、之二、之三中，我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式，还提到应该如何描述用户故事，才能更好地反映客户价值。下面请尝试一下描述这两个故事：1. 如果把“保存按钮”统一放在页面上端而非下面，有些屏幕上侧控件的修改，就无需滚屏即可保存。2. 所有自定义字段，统一改为4000长度的nvarchar。第一个勉强可以写为：“作为一个用户，可以方便地点击上端的保存按钮，以便在某些控件修改的时候无需滚屏即可保存”，但是这个故事颗粒度显得过小，开发可能只需要1小时，而在客户眼中，也不应 阅读全文

摘要：这是敏捷开发用户故事系列的第四篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）优先级排序听起来是一个很简单的工作，一个字段无外乎“重要/一般……”，调整一下然后按排序，就出来了。但其实里边有不少名堂：谁应该负责排序工作？谁最终拍板？研发因素要不要考虑？需求依赖关系导致的顺序如何处理？持续交付的考虑？商业决策的考虑？以下知识与经验，来自于多个来源，主要是部分网上资料、实际项目的访谈，并在自己现在正在做的一个项目中得到验证。具体应用时，应灵活掌握。谁负责排序？Product Owner负责。在产品研发环境中，一般是产品经理；在项目开发环境中，一般是项目经理。作为产品或项目的掌舵人，这个 阅读全文

摘要：这是敏捷开发用户故事系列的第三篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）用户建模的目的，是为了更好地分析用户行为和用户价值，并因此获得商机。用户建模四部曲有一次培训中，分组建模的时候，一位学员就自言自语地说了一句话：“真的啊……我好像不知道谁会使用我的产品……”这其实是一种常见的现象。比如前文所说的敏捷开发管理软件，如果想把一个用户故事描述为“作为一个用户，可以登录“我的空间”，以查看我我在的所有项目的进展以及自己的任务”，就会遇到这个麻烦。所谓领导，肯定想浅层次低能看到多少项目，就看到多少项目，而且最好能汇总一下显示；作为普通程序员，则肯定不止是想知道自己在哪些项目中有任务 阅读全文

摘要：这是敏捷开发用户故事系列的第二篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。“作为一个……，可以……，以（以便）……”不同于一般专注于功能的需求条目描述方法，三个……把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。下面就三个部分分别举出一个例子。网络游戏的排行榜功能“作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。”这个功能可以激发玩家的“斗志”，鼓励购买道具，是个不错的想法，但实现起来却有技术问题：服务器中的玩家太多了，实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名 阅读全文

摘要：这是敏捷开发用户故事系列的第一篇。（之一，之二，之三，之四，之五，之六，之七，之八，之九）全系列将涉及何为用户故事，面向客户价值编写故事，用户建模，产品待开发项的分类，故事颗粒度，故事的组织结构，等等若干问题，力求将此中问题尽量解决干净。本系列文章假设正在编写一个“敏捷开发管理软件”，因为来阅读的都是做敏捷开发的，又都是做软件的，会更熟悉一些。用户故事三要素：角色，功能，价值按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。角色角色切记不要总是写“作为一个用户”，而是要把用户区别 阅读全文