谈禅论道第四期：敏捷如何应对变化的需求-短周期迭代 - 项目管理

谈禅论道第四期于2011年1月13日12：30 - 14：00顺利举行，andy老师就敏捷如何应对变化的需求给大家做了精彩的分享，andy老师对scrum在中国的实施有很多自己独到的经验和观点，请细细品味。

聊天记录:

2011-1-13 12:29:46 青岛-王春生<chunsheng.wang@qq.com>

谈禅论坛第四期，正式开始。:)

2011-1-13 12:30:13 青岛-王春生<chunsheng.wang@qq.com>
本期我们荣幸的邀请到敏捷专家袁斌老师来和大家互动。袁斌（Andy Yuan）先生，是工学硕士，MBA，Scrum、AUP、Agile modeling、XP、Kanban等的实践者。迅思威尔咨询总监。10余年中就职于全球性公司从事软件和产品的开发。曾任Anoto产品中国区开发总监和Mino中国区软件开发总监，利用Scrum成功实现产品快速交付，在电信行业、外包团队、互联网产品的敏捷开发，Scrum团队建设，Scrum在小型、大型团队的应用等方面积累了丰富的经验。

2011-1-13 12:30:41 青岛-王春生<chunsheng.wang@qq.com>
呵呵，本期交流的话题是：敏捷如何应对变化的需求-短周期迭代

2011-1-13 12:31:07 袁斌<agiledo@hotmail.com>
大家好，叫我andy，或者老袁，都是OK的

2011-1-13 12:31:22 袁斌<agiledo@hotmail.com>
工作照了，呵呵

2011-1-13 12:31:23 青岛-王春生<chunsheng.wang@qq.com>
形式是这样：哈哈，先有袁老师给大家分享他的心得体会。

2011-1-13 12:31:44 青岛-王春生<chunsheng.wang@qq.com>
然后是互动环节。:)，下面有请袁老师。

2011-1-13 12:32:04 袁斌<agiledo@hotmail.com>
那我们开始了

2011-1-13 12:32:41 袁斌<agiledo@hotmail.com>
主要的内容都在我发的那个pdf文件中

2011-1-13 12:32:57 袁斌<agiledo@hotmail.com>
我现在对每一页做相应的说明

2011-1-13 12:33:08 袁斌<agiledo@hotmail.com>
任何问题，可以随时交流

2011-1-13 12:33:16 袁斌<agiledo@hotmail.com>
第一页说明需求为什么会变化，例如互联网产品，游戏产品，需求是和市场反馈反复交互而得，也有人说：游戏不是做出来的，是改出来的，获得市场反馈的频率和更早的时间对产品至关重要右下角的图，说明我们需要更关注business value更高的需求，否则会影响我们的开发成本，系统维护以及关键的上市时间。我们经常加班是否在为那些不为客户重视的可有可无的功能？

2011-1-13 12:34:00 袁斌<agiledo@hotmail.com>
大家有这个文档吧：敏捷如何应对变化的需求-短周期迭代-禅道.pdf

2011-1-13 12:34:13 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:35:38 青岛-叶文涛(709808807)
有了

2011-1-13 12:34:52 袁斌<agiledo@hotmail.com>
第二页举例，有12个需求要完成，时间为6个月，按照传统的瀑布方法有一些问题，开始编码的时候被要求增加两个需求，同时被告知R5可以不做了（或者在二期），客户参加测试阶段说R9要改一些，后发布的时间到了，但有两个需求测试的bug处于发散状态，无法发布. 发散状态，是指改了一个bug，引发了两个bug要紧的是，在第三个月，发现竞争对手有动作，我们需要提前发布一些功能，以提前占领市场，但此时我们无法在第三个月发布一个产品，因为我们还没有做任何测试。

2011-1-13 12:35:17 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:37:17 袁斌<agiledo@hotmail.com>
第三页是说明敏捷的方式如何短周期迭代发布，以解决第二页的问题左边一列还是初的需求左边第二列是按照优先级排序后的需求列表R2'是在第一个迭代周期结束时，客户要求将R2改成R2'，即R2的需求有一些变化，R9同理红色是为了表示在第一次按照business value排列优先级的需求优先级的改变蓝色是第二次迭代时需求优先级排列后的改变绿色是第三次迭代是需求的排列变化

2011-1-13 12:37:41 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:39:32 袁斌<agiledo@hotmail.com>
从第二次迭代开始，每一次迭代的交付物都是可以上线的软件每一次迭代，可以在1~4周选择这个是迭代周期，如果测试成本比较大，或者第一次用敏捷，建议4周为迭代周期因为迭代的交付物是100%完成的，即测试是没有问题的可以看到，在第二次迭代结束后，我们可以交付R1,R2'，R9'Ra，Rc5个需求的产品此时我们对其他需求没有编码第二个迭代中包含了优先级高的需求，同时还有用户改变的需求，重要的是，如果在第二个月需要上线，我们也可以做到

2011-1-13 12:41:30 深圳-李剑(574799707)
第二个迭代中包含了优先级高的需求？

2011-1-13 12:41:41 袁斌<agiledo@hotmail.com>
第三个迭代，用户或者产品经理要求增加2个需求（R10,R11)，这两个需求是至关重要的，可能是竞争对手的压力，也可能是政策压力OK，其他的需求先不考量，就做这两个以上的迭代开发内容选择一个是需求优先级排列后的列表一个是开发团队的工作能力，这两个是参考因素

2011-1-13 12:42:18 袁斌<agiledo@hotmail.com>
to 李剑，是的，每一次迭代都是包含优先级高的需求

2011-1-13 12:42:36 青岛-王春生<chunsheng.wang@qq.com>
对的。每个迭代都是当下优先级高的需求。:)

2011-1-13 12:43:15 袁斌<agiledo@hotmail.com>
可以看到，第二次迭代开始，product backlog是重新排序的

2011-1-13 12:43:38 袁斌<agiledo@hotmail.com>
Ra的优先级提高了

2011-1-13 12:45:36 袁斌<agiledo@hotmail.com>
第三次迭代，R5需求删除了

2011-1-13 12:45:31 北京-许进义(14917275)
刚才那幅图没完全理解，第一次迭代包含的需求从哪里看出来？

2011-1-13 12:45:52 袁斌<agiledo@hotmail.com>
好在我们没有effort在R5上

2011-1-13 12:46:13 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:46:19 青岛-王春生<chunsheng.wang@qq.com>
我的理解，应该是这个吧。

2011-1-13 12:46:22 北京-W(13808432)
春生，将袁老师的讲解和应征的PPT关联起来吧

2011-1-13 12:46:22 袁斌<agiledo@hotmail.com>
是的

2011-1-13 12:46:47 袁斌<agiledo@hotmail.com>
第一次迭代，需求列表已经做了优先级的排序

2011-1-13 12:46:55 青岛-王春生<chunsheng.wang@qq.com>

左边是原始的需求，右边是第一次排序的结果。

2011-1-13 12:47:07 青岛-王春生<chunsheng.wang@qq.com>
我理解没错吧？:)

2011-1-13 12:48:31 青岛-叶文涛(709808807)
觉得这个形式就好理解了

2011-1-13 12:47:20 北京-许进义(14917275)
哦，这样就明白了，谢谢

2011-1-13 12:47:31 袁斌<agiledo@hotmail.com>
完全正取：）

2011-1-13 12:47:33 青岛-王春生<chunsheng.wang@qq.com>
所以选择了前面三个，作为第一次迭代的需求列表。

2011-1-13 12:47:35 袁斌<agiledo@hotmail.com>
正确

2011-1-13 12:47:52 33(598920549)
那第一次对需求的排序应该非常重要

2011-1-13 12:48:07 袁斌<agiledo@hotmail.com>
迭代开发内容选择一个是需求优先级排列后的列表一个是开发团队的工作能力，这两个是参考因素

2011-1-13 12:48:31 青岛-王春生<chunsheng.wang@qq.com>
排序应该是每次迭代都要做的。:)而且需求列表也是在不断的变化的。

2011-1-13 12:48:32 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:49:03 青岛-王春生<chunsheng.wang@qq.com>
这是第二次迭代开始的时候，左边是新的需求列表，增加了几个新的需求。重新排序，然后选择了r2', r9',ra, rc

2011-1-13 12:48:59 北京-许进义(14917275)
嗯，在一次迭代的过程中，需求以及优先级可能发生变化

2011-1-13 12:50:03 青岛-王春生<chunsheng.wang@qq.com>
这一页应该没有啥问题了吧。andy，继续？:)

2011-1-13 12:50:13 北京-许进义(14917275)
如果在Sprint 1过程中，R1发生了变化，该如何处理？

2011-1-13 12:50:23 袁斌<agiledo@hotmail.com>
第四页，由于4周内要完成可以工作的软件，所以必须尽早的发现bug敏捷希望代码的bug发现尽可能早图中绿色的是敏捷在推荐图表示发现bug的时间和修改bug的成本关系结对编程和持续集成是有效的结对编程褒贬不一我们实践的推荐是：2个人负责两个需求而不是一个人负责一个需求

2011-1-13 12:51:36 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 12:52:19 青岛-王春生<chunsheng.wang@qq.com>
>>>如果在Sprint 1过程中，R1发生了变化，该如何处理？先记下来。一会讨论。:)

2011-1-13 12:52:37 袁斌<agiledo@hotmail.com>
北京-许进义(14917275) 12:50:13如果在Sprint 1过程中，R1发生了变化，该如何处理？如果是小的变化，例如排序原则改一下，是OK的，但如果是业务逻辑发生大的变化，需要重新估算工作量。如果不能在这个sprint内完成，则和PO商议在下一个sprint完成。

2011-1-13 12:53:09 北京-许进义(14917275)
谢谢，请继续

2011-1-13 12:53:22 青岛-王春生<chunsheng.wang@qq.com>
我翻译下绿色：结对编程，持续集成，测试驱动开发，下面三个就不知道了。

2011-1-13 12:54:04 袁斌<agiledo@hotmail.com>
是其他敏捷方法推荐的，例如Agile Modeling等

2011-1-13 12:54:13 袁斌<agiledo@hotmail.com>
其实前两个实用

2011-1-13 12:54:17 北京-许进义(14917275)
关于Model Storming了解不多，能否介绍一下？

2011-1-13 12:54:33 青岛-王春生<chunsheng.wang@qq.com>
客户积极参与？

2011-1-13 12:54:36 袁斌<agiledo@hotmail.com>
TDD的推广还是有很大难度的，在国内应用也不多

2011-1-13 12:55:26 青岛-王春生<chunsheng.wang@qq.com>
是的，tdd的理念太具有挑战性了。

2011-1-13 12:55:24 北京-许进义(14917275)
Stakeholder我理解的是业务人员，实际使用系统的人或他的领导，

2011-1-13 12:56:21 青岛-王春生<chunsheng.wang@qq.com>
stakeholder是利益相关者.应该可以对应到敏捷宣言里面的客户合作。[表情]

2011-1-13 12:56:28 袁斌<agiledo@hotmail.com>

2011-1-13 12:56:24 北京-许进义(14917275)
从我所在的银行核心系统项目来看，传统的开发成本比TDD一点都不少，但是推广TDD确实有很大难度

2011-1-13 12:56:42 袁斌<agiledo@hotmail.com>
一些stakeholder的例子

2011-1-13 12:57:13 北京-许进义(14917275)
跟UML里面的定义是一致的？

2011-1-13 12:57:28 青岛-王春生<chunsheng.wang@qq.com>
呵呵，学习了。

2011-1-13 12:57:51 袁斌<agiledo@hotmail.com>
没有本质区别，都是项目干系人

2011-1-13 12:57:56 青岛-王春生<chunsheng.wang@qq.com>
andy, unitesting是否可以单独列出来？

2011-1-13 13:01:00 青岛-叶文涛(709808807)
是不是bug及时发现后，针对bug所涉及的利益相关权重进行优先修复啊

2011-1-13 12:59:56 袁斌<agiledo@hotmail.com>
unittesting是非常常用的一种做法，在实际中UT用的很多

2011-1-13 13:00:39 青岛-王春生<chunsheng.wang@qq.com>
通过敏捷的一些实践，尽可能早的发现bug，这样解决的成本就会很低。accepting tetstingsystem testingpreview or 后面的那个单词认不出来了。这几个阶段里面发现的bug，成本就会大大增加。

2011-1-13 13:00:44 青岛-王春生<chunsheng.wang@qq.com>
这是我的理解。hoho

2011-1-13 13:01:36 袁斌<agiledo@hotmail.com>
bug是分优先级的，一些critical的bug一定要先处理，有时候minor的bug放在以后的版本再处理也是可以的

2011-1-13 13:02:04 北京-许进义(14917275)
传统的开发流程中，往往是critical的是难发现，也是后才发现的

2011-1-13 13:02:35 南京-张小狂(54518545)
对于管理类应用系统，领导的需求变化，不够明确，要求比较多，要求快速应对，有时感觉不知所措了

2011-1-13 13:03:44 南京-张小狂(54518545)
对于敏捷开发，TDD,需要测试与架构设计师，业务人员共同构建业务框架，然后由开发人员向里面塞代码

2011-1-13 13:04:16 袁斌<agiledo@hotmail.com>
to 张小狂，先做一个版本，包含领导总念叨的几个需求，让领导先用一下，引导他的思路，试试

2011-1-13 13:04:16 南京-张小狂(54518545)
由测试、业务人员判断输入与输出的符合性

2011-1-13 13:04:46 青岛-王春生<chunsheng.wang@qq.com>
to小狂，咱们先继续。一会可以展开讨论。:)

2011-1-13 13:04:59 青岛-王春生<chunsheng.wang@qq.com>
andy,继续后一页？

2011-1-13 13:05:08 袁斌<agiledo@hotmail.com>
第五页，是敏捷理论和国内现状冲突的解决方案PO和团队之间的沟通不主动，需求理解的不同导致迭代结束时无法交付符合需要的软件原因分析：Scrum建议在每一个迭代结束前有一次交付演示，团队向Product Owner（以下简称PO）演示此次交付的功能，由PO决定交付是否满足需求。PO和团队在开发周期内的主动沟通是交付满足需求的一个重要前提条件，而在国内项目组中双方的主动沟通意愿都不是很强烈，这是导致需求理解不一致的重要原因，而一次演示会让这个风险在迭代结束时才被发现。解决方案：完成一个需求即向PO演示，判断交付和需求的切合度，并同时分析其它需求的理解PO和团队是否有不同之处，及时改进。解决方案的好处是增加演示的频率来“强迫”沟通需求的意愿，逐步形成较好的沟通习惯，同时尽早发现被忽略的需求细节。

2011-1-13 13:06:00 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 13:08:15 袁斌<agiledo@hotmail.com>
我要描述的内容就这些了， free talking...

2011-1-13 13:08:22 北京-许进义(14917275)
实际项目中很多PO不一定能完全明确需求，在有客户业务人员参与的情况下，PO的范围是不是也可以包含客户的业务人员？即每次演示都邀请客户业务人员参加？

2011-1-13 13:08:39 青岛-王春生<chunsheng.wang@qq.com>
呵呵，大家估计都攒着好多问题，来吧！

2011-1-13 13:09:10 北京-许进义(14917275)
包括客户的业务人员，也需要在引导下才能说出真实的需求；这时的演示，就是一种引导，是不是可以这样理解？

2011-1-13 13:09:38 袁斌<agiledo@hotmail.com>
实践中PO往往是弱的一环，所以“每次演示都邀请客户业务人员参加”，太可以了

2011-1-13 13:09:51 北京-许进义(14917275)
O(∩_∩)O

2011-1-13 13:10:24 袁斌<agiledo@hotmail.com>
很多时候，“Scrum master”和业务分析人员也会和PO一些分析需求

2011-1-13 13:10:19 北京-许进义(14917275)
原来大牛也觉得PO缺... ...

2011-1-13 13:10:35 青岛-王春生<chunsheng.wang@qq.com>
演示其实很多人都可以参加，但po就只能是就是那个角色吧。

2011-1-13 13:10:51 青岛-王春生<chunsheng.wang@qq.com>
po应当来整理放方方面面的反馈，形成story 列表。

2011-1-13 13:11:08 袁斌<agiledo@hotmail.com>
PO有时候会有一个组，共同决策，特别在新的行业产品。例如移动互联网，变化很快

2011-1-13 13:11:20 北京-许进义(14917275)
嗯，这下明确了，

2011-1-13 13:11:39 青岛-王春生<chunsheng.wang@qq.com>
恩，很好的方案。

2011-1-13 13:12:19 青岛-王春生<chunsheng.wang@qq.com>
大家有问题，赶紧问[表情]

2011-1-13 13:12:15 北京-许进义(14917275)
与产品经理这一角色的区别？

2011-1-13 13:12:38 袁斌<agiledo@hotmail.com>
“这时的演示，就是一种引导，”，可以这样理解，客户看到实际的系统后思路才会更清晰

2011-1-13 13:12:54 袁斌<agiledo@hotmail.com>
同时在这个时刻，也容易改变需求

2011-1-13 13:13:39 北京-许进义(14917275)
嗯，项目中发生过几次这样的情况；这时开发人员就会感觉业务人员说了不算，当初明明说的不是这个意思，业务人员就觉得他就是这个意思，是开发人员理解错了，

2011-1-13 13:13:49 袁斌<agiledo@hotmail.com>
让“改变需求”的事情发生越早，风险和成本越小

2011-1-13 13:15:27 项目管理(397528046)
大家好

2011-1-13 13:15:34 项目管理(397528046)
请问开始讨论了么？

2011-1-13 13:15:30 北京-许进义(14917275)
通过以上问题，对PO的理解更深刻了，谢谢Andy。是不是可以开始下一个问题？

2011-1-13 13:15:52 袁斌<agiledo@hotmail.com>

2011-1-13 13:16:15 袁斌<agiledo@hotmail.com>
这是PO和传统产品经理的一些区别

2011-1-13 13:16:59 沈阳-海岸
[表情] 为什么这些资料都是英文的。

2011-1-13 13:17:03 袁斌<agiledo@hotmail.com>
包含了一些个人理解，和大家分享，讨论

2011-1-13 13:17:14 项目管理(397528046)
我刚进来没有看到之前的内容

2011-1-13 13:17:28 项目管理(397528046)
不知道讨论的进程是怎样的

2011-1-13 13:17:21 北京-许进义(14917275)
嗯，这个还需要多理解一下，

2011-1-13 13:18:37 青岛-叶文涛(709808807)
可以用中文点一下重点么，袁老师？

2011-1-13 13:18:06 青岛-王春生<chunsheng.wang@qq.com>
1. 传统的要担任多个角色，scrum里面的 PO单一角色。

2011-1-13 13:18:11 袁斌<agiledo@hotmail.com>
哦，我做的培训资料是英文的，主要是因为有一些外企的客户，我自己偷懒了

2011-1-13 13:18:30 袁斌<agiledo@hotmail.com>
没有做中文的:)

2011-1-13 13:18:31 青岛-王春生<chunsheng.wang@qq.com>
2. 传统的和开发团队脱离，scrum里面和sm和团队紧密合作沟通。

2011-1-13 13:18:51 青岛-王春生<chunsheng.wang@qq.com>
3. 不理解。hoho

2011-1-13 13:18:45 北京-许进义(14917275)
个人英语也不好，但是我赞同使用英文

2011-1-13 13:19:16 大连-Flashing(908222)
SM需要coding吗

2011-1-13 13:19:30 青岛-王春生<chunsheng.wang@qq.com>
4. 传统的需求非常详细，而且很做冻结，scrum里面的需求完善是一个持续的过程。

2011-1-13 13:19:55 袁斌<agiledo@hotmail.com>
3. 传统的是在产品开始之前做非常多的市场调查，产品计划很详尽

2011-1-13 13:20:14 项目管理(397528046)
关于Scrum，我一直有一个很困惑的问题，就是如何有效的编写product backlog？我的理解中，需求是通过product backlog来描述的，但是对于一个具体项目的需求，如何清晰有效的描述呢？

2011-1-13 13:20:14 青岛-王春生<chunsheng.wang@qq.com>
5. 传统的反馈很晚，而scrum则很早。持续的进行。

2011-1-13 13:21:23 ㊣(28937095)
scrum和CMMI的区别主要在那里？

2011-1-13 13:21:33 北京-许进义(14917275)
Scrum的product backlog对于习惯传统需求文档的人来说，感觉很简略，担心不能准确覆盖

2011-1-13 13:21:59 项目管理(397528046)
我同意需求分析是一个需要持续完善的过程

2011-1-13 13:22:02 袁斌<agiledo@hotmail.com>
Product backlog，在scrum中没有说明必须用user story

2011-1-13 13:22:18 袁斌<agiledo@hotmail.com>
user case也可以用的

2011-1-13 13:22:41 项目管理(397528046)
但是对于一个项目而言有很多需求是已知的很明确的

2011-1-13 13:22:43 ㊣(28937095)
Scrum的product backlog 不单担心覆盖，还觉得没有个系统的体现！

2011-1-13 13:23:20 项目管理(397528046)
user case只能覆盖一部分需求

2011-1-13 13:23:20 袁斌<agiledo@hotmail.com>
user story更适合和客户交流需求，和在sprint planning中交流

2011-1-13 13:23:27 北京-许进义(14917275)
product backlog系统的体现，就在演示的demo上，以及wiki

2011-1-13 13:24:31 项目管理(397528046)
此外，按照Scrum的方法，对于需求进行分解跟踪就不现实了

2011-1-13 13:25:22 袁斌<agiledo@hotmail.com>
项目管理(397528046) 13:24:31此外，按照Scrum的方法，对于需求进行分解跟踪就不现实了可以详细一些吗？

2011-1-13 13:25:41 青岛-王春生<chunsheng.wang@qq.com>
他这儿说的需求，我想应该是一个很大的东西。

2011-1-13 13:25:50 项目管理(397528046)
我的理解是，如果不能把需求有效的分解为单一的原子功能，就不能实现从需求到设计到实现和测试的一系列跟踪行为

2011-1-13 13:26:42 北京-许进义(14917275)
敏捷中“原子功能”对应的应该是task，需求的跟踪是类似wiki这样的形式，不知道我的理解对不对

2011-1-13 13:27:26 项目管理(397528046)
我这儿所说的需求，指的就是某一个项目完整的客户要求

2011-1-13 13:27:27 青岛-王春生<chunsheng.wang@qq.com>
原子功能，我理解应该是user story，task是实现。

2011-1-13 13:27:46 北京-许进义(14917275)
噢，对，不应该是task

2011-1-13 13:28:15 项目管理(397528046)
如果原子功能是user story的话那么一个story会不会太过于复杂？

2011-1-13 13:28:19 青岛-王春生<chunsheng.wang@qq.com>
客户的要求，应该要整理细分成user story。

2011-1-13 13:28:19 北京-许进义(14917275)
完整的客户要求，就是一个大的story，需要拆分成多个小的story

2011-1-13 13:28:34 青岛-王春生<chunsheng.wang@qq.com>
user story都是很小的。

2011-1-13 13:28:44 青岛-王春生<chunsheng.wang@qq.com>
完整的客户需求，不是story，是一个产品。:)

2011-1-13 13:28:58 上海-王剑峰(85822082)
对于一个项目而言有很多需求是已知的很明确的成熟度达到这个水平，不用scrum了

2011-1-13 13:29:28 项目管理(397528046)
需求是已知的并非跟成熟度有关

2011-1-13 13:29:54 上海-王剑峰(85822082)
敏捷就是要应对变化的

2011-1-13 13:30:06 青岛-王春生<chunsheng.wang@qq.com>
adny，评判一下。hoho

2011-1-13 13:30:07 袁斌<agiledo@hotmail.com>
scrum确实很适用于产品类的开发，需求是未知的或者需求在经常变化

2011-1-13 13:30:12 重庆-正(28937095)
想问下，user story中需要描述界面的样式吗？以及对界面的操作？

2011-1-13 13:30:19 上海-王剑峰(85822082)
是在需求不明确的的基础上提出的解决方案

2011-1-13 13:30:26 项目管理(397528046)
比如对于大多数信息管理系统总所周知都会有诸如登录、信息维护等功能

2011-1-13 13:30:26 广州-冯智(288592)
需求明不明确跟成熟度没关阿
(通过iPhone QQ发送，详情请访问： http://apple.qq.com/ )

2011-1-13 13:30:32 北京-许进义(14917275)
敏捷是关注需求的变化，

2011-1-13 13:30:46 青岛-王春生<chunsheng.wang@qq.com>
to项目管理，有确定的，也肯定有很多不确定的。

2011-1-13 13:31:03 上海-王剑峰(85822082)
你需求都明确细化了，很稳定，那还敏捷啥意思呢

2011-1-13 13:31:06 青岛-王春生<chunsheng.wang@qq.com>
你说的登录，维护，应该是功能模块，而不是user story

2011-1-13 13:31:24 青岛-王春生<chunsheng.wang@qq.com>
比如登录，是否需要验证码？是否需要记录登录状态？

2011-1-13 13:31:26 袁斌<agiledo@hotmail.com>
对于项目类的开发，如果客户的IT部门不强大，或者客户很强势，他们很多时候喜欢瀑布开发

2011-1-13 13:31:33 北京-许进义(14917275)
对，赞同

2011-1-13 13:31:46 重庆-正(28937095)
对，是的

2011-1-13 13:31:49 袁斌<agiledo@hotmail.com>
即给你两个月做需求调研，然后就不要烦我了

2011-1-13 13:31:56 项目管理(397528046)
那么user story应该比功能模块的范围更小么？

2011-1-13 13:31:59 淄博-跃然(150243423)
传统的项目管理里面的里程碑的定义在这里有没有，或者相对应的东西？

2011-1-13 13:32:14 青岛-王春生<chunsheng.wang@qq.com>
user story是比较小的东东。我的理解。呵呵。

2011-1-13 13:32:09 北京-许进义(14917275)
story是从用户的角度来阐述功能模块，

2011-1-13 13:32:23 上海-王剑峰(85822082)
Andy敏捷顾问<agiledo@hotmail.com> 1:31:49 PM即给你两个月做需求调研，然后就不要烦我了，九个月后悲剧重演

2011-1-13 13:32:26 重庆-正(28937095)
而且需求调研完了还要出一本固定的文档

2011-1-13 13:32:31 青岛-王春生<chunsheng.wang@qq.com>
比如，我希望可以记录登录状态，可以作为一个user story

2011-1-13 13:32:39 项目管理(397528046)
比如一个关于登录的story是否可以是这样

2011-1-13 13:32:56 青岛-王春生<chunsheng.wang@qq.com>
登录这个功能模块，可以有很多个user story出来。

2011-1-13 13:33:00 北京-许进义(14917275)
“作为管理员，我要登录系统，进行系统管理”

2011-1-13 13:33:25 北京-许进义(14917275)
“作为业务人员，我要登录系统，进行业务处理”

2011-1-13 13:33:41 重庆-正(28937095)
北京-许进义(14917275) 13:33:00“作为管理员，我要登录系统，进行系统管理”这也太模糊了吧

2011-1-13 13:33:53 项目管理(397528046)
操作人员输入用户名称和用户密码，以及验证码，系统验证输入的信息，如果正确则允许登录系统

2011-1-13 13:33:56 上海-王剑峰(85822082)

2011-1-13 13:33:55 北京-许进义(14917275)
呵呵，例子，不同的场景再细化

2011-1-13 13:34:04 上海-王剑峰(85822082)
就是这个杯具

2011-1-13 13:34:19 袁斌<agiledo@hotmail.com>
这个图很经典

2011-1-13 13:34:42 项目管理(397528046)
经典的图往往只是提出问题不能解决问题

2011-1-13 13:34:53 上海-王剑峰(85822082)
这就是瀑布的结果

2011-1-13 13:35:00 上海-王剑峰(85822082)
scrum就是解决这个的

2011-1-13 13:34:55 北京-许进义(14917275)
敏捷就是在绑好绳子的时候，跟客户确认，是不是这样

2011-1-13 13:35:15 袁斌<agiledo@hotmail.com>
“作为管理员，我要登录系统，进行系统管理”需要有acceptance test的描述

2011-1-13 13:35:31 青岛-王春生<chunsheng.wang@qq.com>
>>>操作人员输入用户名称和用户密码，以及验证码，系统验证输入的信息，如果正确则允许登录系统我的意见是还可以再进行拆分。

2011-1-13 13:35:23 北京-许进义(14917275)
哦，学习了

2011-1-13 13:35:33 上海-王剑峰(85822082)
还缺business value

2011-1-13 13:35:45 青岛-王春生<chunsheng.wang@qq.com>
验证码可以单独拿出来，作为一个story

2011-1-13 13:35:57 项目管理(397528046)
是了

2011-1-13 13:36:24 项目管理(397528046)
但这样的话单单一个登录模块就可以写出很多个story

2011-1-13 13:36:33 项目管理(397528046)
那么

2011-1-13 13:36:33 上海-王剑峰(85822082)
多怕什么

2011-1-13 13:36:33 袁斌<agiledo@hotmail.com>

2011-1-13 13:36:43 上海-王剑峰(85822082)
story越小越好

2011-1-13 13:36:55 袁斌<agiledo@hotmail.com>
这个图包含一个story应该包含的因素

2011-1-13 13:37:15 项目管理(397528046)
仅仅把项目中已知需求的story写出来就会要很多功夫的

2011-1-13 13:37:16 上海-王剑峰(85822082)
三个sprint做一个story那就不敏捷了

2011-1-13 13:37:50 北京-许进义(14917275)
how to demo就是acceptance test ?

2011-1-13 13:38:09 袁斌<agiledo@hotmail.com>
是的

2011-1-13 13:38:23 项目管理(397528046)
按这个图上列出的stroy的因素来看，一个story的范围绝不会很小

2011-1-13 13:38:54 项目管理(397528046)
login、deposit、check

2011-1-13 13:39:06 袁斌<agiledo@hotmail.com>
story是要拆分的，以在一个sprint内可以实现

2011-1-13 13:39:11 项目管理(397528046)
你的这个图我研究过

2011-1-13 13:39:23 上海-王剑峰(85822082)
是大是小关键在于business value

2011-1-13 13:39:26 南京-张小狂(54518545)
拆分的度很难把握

2011-1-13 13:39:37 青岛-王春生<chunsheng.wang@qq.com>
to 项目管理，你的理解呵呵，有问题

2011-1-13 13:39:45 重庆-正(28937095)
to 项目管理解释一下

2011-1-13 13:39:50 青岛-王春生<chunsheng.wang@qq.com>
我的观点，简单的一点，就越细越好。

2011-1-13 13:39:59 项目管理(397528046)
它是一个story，但实际是若干story的一个集成应用

2011-1-13 13:40:03 南京-张小狂(54518545)
除了业务价值，还要考虑技术实现，资源等

2011-1-13 13:40:15 上海-王剑峰(85822082)
如果一个story的business value说不清楚，那这个story的大小就有问题

2011-1-13 13:40:15 南京-张小狂
也不是越细越好

2011-1-13 13:40:25 重庆-正
晕了！！！

2011-1-13 13:40:18 北京-许进义
之前Andy提到的，项目组的工作能力

2011-1-13 13:40:37 项目管理(397528046)
to 春生我对于scrum的理解确实存在问题

2011-1-13 13:40:41 南京-张小狂(54518545)
business value是一个关键的维度

2011-1-13 13:40:44 上海-王剑峰(85822082)
比如验证码，为什么（春生说）要单分出来

2011-1-13 13:40:59 项目管理(397528046)
之前很积极但是在项目组实际应用时遇到了很多问题

2011-1-13 13:41:04 南京-张小狂(54518545)
但实际情况，受多个维度制约

2011-1-13 13:41:07 上海-王剑峰
因为他的business value和登录的business value是两个

2011-1-13 13:41:34 青岛-王春生<chunsheng.wang@qq.com>
刚才andy里面的how to demo里面的login是另外的story

2011-1-13 13:41:42 沈阳-海岸
敏捷只算一个概念，尝试一种新的模式，存在学习成本应属正常。

2011-1-13 13:41:43 上海-王剑峰(85822082)
所以春生的理解是对的，叫项目管理那位先去改名吧

2011-1-13 13:41:52 青岛-王春生<chunsheng.wang@qq.com>
不能何在一起。

2011-1-13 13:41:58 项目管理(397528046)
怎么改名？

2011-1-13 13:42:15 南京-张小狂(54518545)
to andy&春生，敏捷后如何系统，跟踪文档，知识积累与传承

2011-1-13 13:42:50 项目管理(397528046)

我知道地方我问得是名字的规则

2011-1-13 13:42:58 青岛-王春生<chunsheng.wang@qq.com>
地方-姓名。

2011-1-13 13:43:00 青岛-王春生<chunsheng.wang@qq.com>
hoho

2011-1-13 13:42:55 北京-许进义(14917275)
看看我们的没发现？

2011-1-13 13:43:09 西安－杨帆(397528046)
ok

2011-1-13 13:43:59 北京-许进义(14917275)
请问Andy，敏捷开发是不是必须与敏捷的激励配套？

2011-1-13 13:44:17 袁斌<agiledo@hotmail.com>
我总结了一下，大家对敏捷中的需求管理非常感兴趣，我建议在下一次讨论的时候作为一个主题，我自己也可以准备一些资料和大家分享

2011-1-13 13:44:22 西安－杨帆(397528046)
我的问题就在于一开始编写product backlog时难以下手

2011-1-13 13:44:39 青岛-王春生<chunsheng.wang@qq.com>
andy刚才的那个story，只是一个存款的功能，将来可以提款，登录，这些应当是其他的story点。:)

2011-1-13 13:44:53 重庆-正(28937095)
to andy，翻译一下，便于理解

2011-1-13 13:45:07 青岛-王春生<chunsheng.wang@qq.com>
呵呵，有的东西，还是英文的比较原汁原味。

2011-1-13 13:45:10 西安－杨帆(397528046)
到底一条backlog的粒度应该分解到什么程度

2011-1-13 13:45:35 重庆-正(28937095)
英文理解也有歧义啊

2011-1-13 13:45:39 青岛-王春生<chunsheng.wang@qq.com>
andy，那个衡量的工时大概是多少来着？

2011-1-13 13:46:14 袁斌<agiledo@hotmail.com>
这里用的是ID（Ideal Day），即10个理想日

2011-1-13 13:46:27 青岛-王春生<chunsheng.wang@qq.com>
每个需求都有一个估计的点的。如果这个需求的点太大，就应该要继续拆分。

2011-1-13 13:46:29 袁斌<agiledo@hotmail.com>
也有人会用story point

2011-1-13 13:46:32 西安－杨帆(397528046)
此外刚才我还提及到需求跟踪不知道在Scrum中是如何有效的跟踪需求的

2011-1-13 13:46:57 西安－杨帆(397528046)
需求的估计的点？这个如何判断大小？

2011-1-13 13:47:12 北京-许进义(14917275)
story point,人天或者人小时，

2011-1-13 13:47:45 青岛-王春生<chunsheng.wang@qq.com>
to andy, 10个理想日，是不是太大了？

2011-1-13 13:47:42 重庆-正(28937095)
to 王春生，禅道里面工时的统计没体现出来

2011-1-13 13:47:54 西安－杨帆(397528046)
对于上述那个deposit的story 它的需求的点是大还是小？

2011-1-13 13:48:00 青岛-王春生<chunsheng.wang@qq.com>
需求跟踪，用禅道啊。:)

2011-1-13 13:48:25 袁斌<agiledo@hotmail.com>
春生，所以这个story是需要拆分的，我展示的是一个较大的story

2011-1-13 13:48:47 西安－杨帆(397528046)
跟工具没有关系我认为关键上是分解需求需求如果不能被有效分解就无法跟踪啊

2011-1-13 13:48:44 北京-许进义(14917275)

2011-1-13 13:49:52 西安－杨帆(397528046)
说实话我觉得这个北京团队的backlog 每一条都很虚

2011-1-13 13:50:01 重庆-正(28937095)
嗯我也觉得

2011-1-13 13:50:29 重庆-正(28937095)
基本上没法执行

2011-1-13 13:50:47 西安－杨帆(397528046)
如果作为backlog 谁能估计出他是需要几个sprint来完成或者一个sprint能完成几个呢？

2011-1-13 13:51:06 青岛-王春生<chunsheng.wang@qq.com>
作为产品人员，我希望需求可以增加一个owner字段，这样可以明确的标识这个需求的负责人是谁。

2011-1-13 13:51:05 袁斌<agiledo@hotmail.com>
这个backlog，是隐藏了故事背后的“acceptance test”吧：）

2011-1-13 13:50:56 北京-许进义(14917275)
backlog需要拆分成多个story,

2011-1-13 13:51:11 青岛-王春生<chunsheng.wang@qq.com>
看看禅道的需求。

2011-1-13 13:51:43 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 13:51:55 上海-王剑峰(85822082)
西安-扬帆还没入门呢

2011-1-13 13:52:10 青岛-王春生<chunsheng.wang@qq.com>

2011-1-13 13:52:17 西安－杨帆(397528046)
我有没有入门无关紧要

2011-1-13 13:52:23 上海-王剑峰(85822082)
建议付费请andy给你先上一课

2011-1-13 13:52:40 青岛-王春生<chunsheng.wang@qq.com>
是，我觉得主要的问题是你的观念。

2011-1-13 13:52:51 青岛-王春生<chunsheng.wang@qq.com>
建议你用脑图软件来分解需求。

2011-1-13 13:52:55 上海-王剑峰(85822082)
否则这不是交流，是灌水

2011-1-13 13:52:47 北京-许进义(14917275)
有问题，才更需要我们的讨论

2011-1-13 13:53:17 西安－杨帆(397528046)
春生展示的几个story是可执行的

2011-1-13 13:53:40 西安－杨帆(397528046)
但如果按照春生这样的来做就会回到另外一个问题

2011-1-13 13:54:07 西安－杨帆(397528046)
stroy过于细化一个功能模块就会有很多story

2011-1-13 13:54:18 袁斌<agiledo@hotmail.com>
这样，关于变化的需求如何管理，我找一个图和大家分享

2011-1-13 13:54:41 北京-许进义(14917275)
嗯，确实需要一个单独的主题来讨论这部分

2011-1-13 13:55:02 青岛-王春生<chunsheng.wang@qq.com>
>>>stroy过于细化一个功能模块就会有很多story这怕啥？本来就应该要细分出来的。你这个时候不细分，早晚有一天要还账.

2011-1-13 13:56:46 袁斌<agiledo@hotmail.com>

2011-1-13 13:56:51 西安－杨帆(397528046)
你能否把禅道关于登录方面的story发上来看看么？

2011-1-13 13:56:53 北京-许进义(14917275)
去www.zentao.net

2011-1-13 13:57:21 青岛-王春生<chunsheng.wang@qq.com>
先不急，先听andy解释下这个图。

2011-1-13 13:57:12 北京-许进义(14917275)
春生的需求都是在公网的，[表情]

2011-1-13 13:57:29 袁斌<agiledo@hotmail.com>
这是scrum如何管理变化的需求，即product backlog如何管理的一个模型

2011-1-13 13:58:49 西安－杨帆(397528046)
好的先听讲解我下来拜读下春生的需求

2011-1-13 13:58:39 北京-许进义(14917275)
按照优先级划分需求，每次迭代完成优先级高的；

2011-1-13 13:59:41 沈阳-海岸
andy老师，如果一个项目进行80%，做完的功能模块，基本都处于一个“接近可测试”的状态。现在进度开始缓慢，就是时间和精力似乎用下去了，但是项目的进展始终达不到目标。针对这个问题，您有什么好建议吗。 [表情]

2011-1-13 14:00:29 青岛-王春生<chunsheng.wang@qq.com>
建议就是实施scrum。hoho，请andy老师给你们做做内训。[表情]

2011-1-13 14:00:39 沈阳-海岸
挺入门，也挺现实的一个问题…

2011-1-13 14:00:37 北京-许进义(14917275)
同意春生...

2011-1-13 14:00:53 袁斌<agiledo@hotmail.com>
时间还剩多少？

2011-1-13 14:01:02 袁斌<agiledo@hotmail.com>
海岸

2011-1-13 14:01:19 青岛-王春生<chunsheng.wang@qq.com>
已经到时间了。:)感觉还意犹未尽呢。

2011-1-13 14:01:19 袁斌<agiledo@hotmail.com>
20%的时间剩余？

2011-1-13 14:01:24 北京-许进义(14917275)
才上路...

2011-1-13 14:01:59 袁斌<agiledo@hotmail.com>
海岸，我的一个建议

2011-1-13 14:02:31 袁斌<agiledo@hotmail.com>
如果下一个项目，先把需求按照耦合程度分组

2011-1-13 14:02:58 袁斌<agiledo@hotmail.com>
然后集中团队力量先做优先级高的

2011-1-13 14:03:06 袁斌<agiledo@hotmail.com>
保证测试完成

2011-1-13 14:03:25 袁斌<agiledo@hotmail.com>
这样团队有持续的成就感

2011-1-13 14:04:08 袁斌<agiledo@hotmail.com>
项目的风险也低，退一步说，就算10个功能完成了9个，也比10个功能有5个完成90%但不能交付强

2011-1-13 14:04:24 青岛-王春生<chunsheng.wang@qq.com>
经典！

2011-1-13 14:04:21 北京-许进义(14917275)
[表情]

2011-1-13 14:04:45 沈阳-海岸
是的，andy老师的建议也是我在这个项目中慢慢学到的东西。

2011-1-13 14:04:57 沈阳-海岸
下一个项目应该会成熟许多，目前项目还有两个月时间。

2011-1-13 14:05:06 青岛-王春生<chunsheng.wang@qq.com>
伤其十指，不如断其一指。够狠吧！

2011-1-13 14:05:51 沈阳-海岸
理论时间是够的，但是我觉得现在处于一个泥潭状态。如果拔不出来，再有两年时间也不够。 [表情]

2011-1-13 14:05:40 北京-许进义(14917275)

时间到了，我的问题还没来得及问... ...

2011-1-13 14:06:18 沈阳-海岸
呃，感谢andy老师的总结，我居然在刚好在结束的时间线上。

2011-1-13 14:06:50 袁斌<agiledo@hotmail.com>
针对目前这个项目，已经这样了，如果进展不大，不如和老板建议一些可以刺激团队的东西，激励一下团队，呵呵

2011-1-13 14:07:44 青岛-王春生<chunsheng.wang@qq.com>
呵呵，andy老师时间也很紧。咱们今天就到这儿吧。感谢andy老师精彩专业的分享！[表情]

2011-1-13 14:07:46 沈阳-海岸
嗯，也许我应该重新整理一次需求，然后把力量重新拉拢到主干上来。

2011-1-13 14:07:51 沈阳-海岸
谢谢andy老师。

2011-1-13 14:07:54 北京-许进义(14917275)
谢谢！

2011-1-13 14:08:19 青岛-王春生<chunsheng.wang@qq.com>
[表情]

2011-1-13 14:10:07 青岛-叶文涛(709808807)
谢谢老师

2011-1-13 14:09:14 西安－杨帆(397528046)
谢谢

2011-1-13 14:09:44 西安－杨帆(397528046)
如果有可能我建议可以组织一次关于需求管理方面的讨论

2011-1-13 14:10:50 Shirley(17980507)
好主意