[链接]谈谈软件的价值
Jeff Xiong
全文：http://www.infoq.com/cn/articles/Agile-Unleashes-Software-Value
--
Jeff Xiong
Editor of InfoQ China: http://www.infoq.com/cn/
Contributor of CruiseControl.rb: http://cruisecontrolrb.thoughtworks.com/
collin000
"最后，客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握，他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起，使得
这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件，而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。"
遇到这种客户那是最好了，可惜感觉现在大部分客户还是后一种做法，甚至是很多的开发人员和需求分析人员也都支持后一种做法！！！
Jeff Xiong
当这两条都为false时，很少有客户不要迭代。
张文
collin000
就算相信这会提高效率也未必会去做！
因为在很多时候，使用敏捷开发，会动别人的奶酪！
Kingfish (Wang Yu)
有多少人是为了企业利益在努力呢？又有多少人是为了自己或者某个部门的利益在努力呢？
关键让大领导知道：方法很多
Jeff Xiong
个人而言，我更愿意考虑的是：如果这些客户突然有一天变成了"理想的客户"，我有能力为他们把项目做好吗？
各位抱怨客户不理想的同志，不妨扪心自问一下，如果客户突然就变得很理想了，你就能保证做得很好吗？
Kingfish (Wang Yu)
collin000
很可能没有特别明确的客户需求，这种情况会导致一个问题：我们做出来的功能需要直到整个产品测试甚至是上线的时候，才能确定这个功能是否真的起到相应的
作用。我所在的组就是这种情况，费了不少力气作出来的东西不实用，再从头改！郁闷至极！
其实这个产品也是迭代式开发，我经理对时间的把握还是比较准的，但对于客户需求的把握不到位。去问产品部的mm，也没有什么好的结果，因为她们也不是最
终用户。
collin000
俺们开发人员还是专注开发吧！
Donald
在 07-3-29，collin000<coll...@gmail.com> 写道：
> 呵呵，我可也是鼎立支持！
> 俺们开发人员还是专注开发吧！
>
> >
>
--
Donald
-------------------------------------
上善若水，水善利万物而不争，处众人之所恶，故几于道。居善地，心善渊，与善人，言善信，政善治，事善能，动善时。夫惟不争，故无尤。
－－ 老子 《道德经》
collin000
On 3月29日, 下午3时42分, Donald <flying...@gmail.com> wrote:
> 产品部怎么会有MM？产品部的意义值得重新考虑啊
>
> 在 07-3-29，collin000<collin...@gmail.com> 写道：
冰云
定位等具体工作。这样BA可以了解到产品的目标受众，可以通过对这批人建立Persona，使用交互设计、用户测试等手段保证产品的可用性。。。不过这
都是设想，TW目前还没这样的产品，谁有机会可以试试看
Jeff Xiong
Michael Chen
Getting Real那本书里面描述了这种场景。实际上，37Singal公司的产品都是这样的。开发人员不仅仅写代码，还活跃在社区，解答疑难，直接面对用户。这种情况下，传统的所谓售前、售后等这些角色没有了，只有一个环节，一个团队。
这种方式目前见得最多的是开源项目，如吉吉叉参与的CC.rb，这可能是大家潜意识觉得程序员与程序员交流比较容易。但这种模式一旦成为某一种真正的商业手段，他表现出来的是信任与更直接更快的交付。看看37singal的成功就知道了。
另外，我一直在关注金山的剑网3。这个号称史上国产最强3D处理引擎，吸引了像我这样一直有武侠情节的玩家。基本上隔一段时间我就上去。你知道那里谁最引人注目吗？一个名为3D工程师的剑网3开发人员。
On 3/29/07, Jeff Xiong <gigi...@gmail.com> wrote:
--
Michael Chen
--------------------------------
Blog: http://michael.nona.name
MSN: jzch...@hotmail.com
femto gary
第一，大家做得不都是这种web项目,
第二，这种support,未必人人满意，比方说对于zhuaxia,
我原来确实觉得zhuaxia不错的,而且zhuaxia也有如
Getting Real那本书里头的blog,不过问题是,当我
满怀热情地提了几次建议以后,yes,最初回复确实
很好，感谢云云，我们会尽快把这个功能加进去的。
然后就是等了n天,都没啥反映。然后看到加了一堆
乱七八糟的,getting in my way的功能。
不能不对zhuaxia #@R%#@%#$%@#,
然后对这种方式不报信任态度。
--
Best Regards
femto http://hi.baidu.com/femto
冰云
解产品需求的方法，不仅仅是针对传统企业应用或小规模用户群应用的问题，还可延伸到对于创新的互联网项目，尤其是web2项目的需求发展研究。这也是俺
从当BA以来一直想做的一件事：在还没有用户群，或到处都是用户的情况下，如何创新一个应用，并达到良好的可用性
On 3月29日, 下午7时38分, "Michael Chen" <mechil...@gmail.com> wrote:
> limo:
>
> Getting Real那本书里面描述了这种场景。实际上，37Singal公司的产品都是这样的。开发人员不仅仅写代码，还活跃在社区，解答疑难，直接面对用户。这种情况下，传统的所谓售前、售后等这些角色没有了，只有一个环节，一个团队。
>
> 这种方式目前见得最多的是开源项目，如吉吉叉参与的CC.rb，这可能是大家潜意识觉得程序员与程序员交流比较容易。但这种模式一旦成为某一种真正的商业手段，他表现出来的是信任与更直接更快的交付。看看37singal的成功就知道了。
>
> 另外，我一直在关注金山的剑网3。这个号称史上国产最强3D处理引擎，吸引了像我这样一直有武侠情节的玩家。基本上隔一段时间我就上去。你知道那里谁最引人注目吗？一个名为3D工程师的剑网3开发人员。
>
> On 3/29/07, Jeff Xiong <gigix1...@gmail.com> wrote:
>
>
>
> > CruiseControl.rb
>
> > On 3/29/07, 冰云 <icecl...@gmail.com> wrote:
>
> > 关于产品研发的需求问题，目前我有些不成熟的想法（因为没机会实践）。主要是设想让BA和marketing人员更紧密的合作，直接让BA参与包括市场
>
> > 定位等具体工作。这样BA可以了解到产品的目标受众，可以通过对这批人建立Persona，使用交互设计、用户测试等手段保证产品的可用性。。。不过这
> > > 都是设想，TW目前还没这样的产品，谁有机会可以试试看
>
> > > On 3月29日, 下午3时29分, "collin000" < collin...@gmail.com> wrote:
> > > > 还有一种情况是做产品，而非项目。
>
> > 很可能没有特别明确的客户需求，这种情况会导致一个问题：我们做出来的功能需要直到整个产品测试甚至是上线的时候，才能确定这个功能是否真的起到相应的
> > > > 作用。我所在的组就是这种情况，费了不少力气作出来的东西不实用，再从头改！郁闷至极！
>
> > 其实这个产品也是迭代式开发，我经理对时间的把握还是比较准的，但对于客户需求的把握不到位。去问产品部的mm，也没有什么好的结果，因为她们也不是最
> > > > 终用户。
>
> > >http://www.infoq.com/cn/
> > > Contributor of CruiseControl.rb:
> >http://cruisecontrolrb.thoughtworks.com/
>
> --
> Michael Chen
> --------------------------------
> Blog:http://michael.nona.name
> MSN: jzche...@hotmail.com
Michael Chen
网游都在此列。zhuaxia的例子恰好说明方式很好，吸引了像你这样的专业用户。但看起来他们的团队看起来更看重自己的想法，呵呵，双刃剑呀。
On 3/29/07, 冰云 <icec...@gmail.com> wrote:
MSN: jzch...@hotmail.com
咖啡屋的鼠标
些产品往往不是为了解决实际问题，反而是去追求噱头，每一个功能的创建就是为了眩为了看着牛B，充满着谎言，已经违背了敏捷开发的本质要求。做坏是正常
的，做好了那叫奇迹。
至于用户群，我的理解，有共同需求的人就应该是用户群了，分散与聚合不过是一个物理变化，满足他们共同的需求就是产品的目的。所以不存在到处是用户的情
况，如果感觉到了这种情况，那么不是分析的不到位就是先入为主的思维在作怪。
On Mar 29, 8:21 pm, "Michael Chen" <mechil...@gmail.com> wrote:
> 没错，在不同的开发领域有不同的反馈（或者称用户参与）方式。但我假定我们做的都是那种需要大量用户参与的项目，web2,
> 网游都在此列。zhuaxia的例子恰好说明方式很好，吸引了像你这样的专业用户。但看起来他们的团队看起来更看重自己的想法，呵呵，双刃剑呀。
>
> On 3/29/07, 冰云 <icecl...@gmail.com> wrote:
>
>
>
>
>
> > cc.rb的主要问题是，我们开发团队本身就是cc的用户。因此我们对业务相当熟悉，不会有猜测用户需求的问题。所以cc系列都不够典型。我所设想的了
> > 解产品需求的方法，不仅仅是针对传统企业应用或小规模用户群应用的问题，还可延伸到对于创新的互联网项目，尤其是web2项目的需求发展研究。这也是俺
> > 从当BA以来一直想做的一件事：在还没有用户群，或到处都是用户的情况下，如何创新一个应用，并达到良好的可用性
>
> > On 3月29日, 下午7时38分, "Michael Chen" <mechil...@gmail.com> wrote:
> > > limo:
>
> > > Getting Real那本书里面描述了这种场景。实际上，37Singal公司的产品都是这样的。开发人员不仅仅写代码，还活跃在社区，解答疑难，直接面对用户。这种情况下-，传统的所谓售前、售后等这些角色没有了，只有一个环节，一个团队。
>
> > > 这种方式目前见得最多的是开源项目，如吉吉叉参与的CC.rb，这可能是大家潜意识觉得程序员与程序员交流比较容易。但这种模式一旦成为某一种真正的商业手段，-他表现出来的是信任与更直接更快的交付。看看37singal的成功就知道了。
>
> > > 另外，我一直在关注金山的剑网3。这个号称史上国产最强3D处理引擎，吸引了像我这样一直有武侠情节的玩家。基本上隔一段时间我就上去。你知道那里谁最引人注目-吗？一个名为3D工程师的剑网3开发人员。
>
> > > On 3/29/07, Jeff Xiong <gigix1...@gmail.com> wrote:
>
> > > > CruiseControl.rb
>
> > > > On 3/29/07, 冰云 <icecl...@gmail.com> wrote:
>
> > > > 关于产品研发的需求问题，目前我有些不成熟的想法（因为没机会实践）。主要是设想让BA和marketing人员更紧密的合作，直接让BA参与包括市场
>
> > > > 定位等具体工作。这样BA可以了解到产品的目标受众，可以通过对这批人建立Persona，使用交互设计、用户测试等手段保证产品的可用性。。。不过这
> > > > > 都是设想，TW目前还没这样的产品，谁有机会可以试试看
>
> > > > > On 3月29日, 下午3时29分, "collin000" < collin...@gmail.com> wrote:
> > > > > > 还有一种情况是做产品，而非项目。
>
> > > > 很可能没有特别明确的客户需求，这种情况会导致一个问题：我们做出来的功能需要直到整个产品测试甚至是上线的时候，才能确定这个功能是否真的起到相应的
> > > > > > 作用。我所在的组就是这种情况，费了不少力气作出来的东西不实用，再从头改！郁闷至极！
>
> > > > 其实这个产品也是迭代式开发，我经理对时间的把握还是比较准的，但对于客户需求的把握不到位。去问产品部的mm，也没有什么好的结果，因为她们也不是最
> > > > > > 终用户。
>
> > > > >http://www.infoq.com/cn/
> > > > > Contributor of CruiseControl.rb:
> > > >http://cruisecontrolrb.thoughtworks.com/
>
> > > --
> > > Michael Chen
> > > --------------------------------
> > > Blog:http://michael.nona.name
> > > MSN: jzche...@hotmail.com
>
> --
> Michael Chen
> --------------------------------
> Blog:http://michael.nona.name
> MSN: jzche...@hotmail.com- Hide quoted text -
>
> - Show quoted text -
collin000
一个产品如果满足多数人的需求，那也可以称之为一个好的产品了。
On 3月30日, 上午9时37分, "咖啡屋的鼠标" <tj19...@gmail.com> wrote:
> 做产品的时候，客户就在团队中，已经符合敏捷了。唯一造成需求不明的问题是战略问题，因为国内的国企、政府都倾向于买产品，所以软件公司就做产品，而这
> 些产品往往不是为了解决实际问题，反而是去追求噱头，每一个功能的创建就是为了眩为了看着牛B，充满着谎言，已经违背了敏捷开发的本质要求。做坏是正常
> 的，做好了那叫奇迹。
> 至于用户群，我的理解，有共同需求的人就应该是用户群了，分散与聚合不过是一个物理变化，满足他们共同的需求就是产品的目的。所以不存在到处是用户的情
> 况，如果感觉到了这种情况，那么不是分析的不到位就是先入为主的思维在作怪。
>
> On Mar 29, 8:21 pm, "Michael Chen" <mechil...@gmail.com> wrote:
>
>
>
> > 没错，在不同的开发领域有不同的反馈（或者称用户参与）方式。但我假定我们做的都是那种需要大量用户参与的项目，web2,
> > 网游都在此列。zhuaxia的例子恰好说明方式很好，吸引了像你这样的专业用户。但看起来他们的团队看起来更看重自己的想法，呵呵，双刃剑呀。
>
> > On 3/29/07, 冰云 <icecl...@gmail.com> wrote:
>
> > > cc.rb的主要问题是，我们开发团队本身就是cc的用户。因此我们对业务相当熟悉，不会有猜测用户需求的问题。所以cc系列都不够典型。我所设想的了
> > > 解产品需求的方法，不仅仅是针对传统企业应用或小规模用户群应用的问题，还可延伸到对于创新的互联网项目，尤其是web2项目的需求发展研究。这也是俺
> > > 从当BA以来一直想做的一件事：在还没有用户群，或到处都是用户的情况下，如何创新一个应用，并达到良好的可用性
>
> > > On 3月29日, 下午7时38分, "Michael Chen" <mechil...@gmail.com> wrote:
> > > > limo:
>
> > > > Getting Real那本书里面描述了这种场景。实际上，37Singal公司的产品都是这样的。开发人员不仅仅写代码，还活跃在社区，解答疑难，直接面对用户。这种情况下--，传统的所谓售前、售后等这些角色没有了，只有一个环节，一个团队。
>
> > > > 这种方式目前见得最多的是开源项目，如吉吉叉参与的CC.rb，这可能是大家潜意识觉得程序员与程序员交流比较容易。但这种模式一旦成为某一种真正的商业手段，--他表现出来的是信任与更直接更快的交付。看看37singal的成功就知道了。
>
> > > > 另外，我一直在关注金山的剑网3。这个号称史上国产最强3D处理引擎，吸引了像我这样一直有武侠情节的玩家。基本上隔一段时间我就上去。你知道那里谁最引人注目--吗？一个名为3D工程师的剑网3开发人员。
> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
jessi...@gmail.com
jessi...@gmail.com
我的看法是就算是做产品，agile的指导实践一样也是原则：
1.持续交付可用小版本
做产品也一样，即便需求是固定的，但谁能保证产品在1/2年的开发周期中，不会在传递中丢失尼？只有持续、尽早地验证、并适时调整，才能让
我们相对地始终围绕正确的方向。而且现在世界变化这么快，做任何产品，即使是神州火箭，只是框架需求是相对固定的，但细节需求又存在着多少变化呢？
2.有效沟通
做任何事情，只要是依靠团队力量做事情，沟通再怎么做都显得不充分、有效。做产品的团队规模更大，接口更多，如果不能有效、充分沟通，可以
想象后果有多么严重了。
3. 简单思维
Just Keep It Simple ,and Stupid. 这条KISS原则，在我看来，应该是一个人生哲学了，放之四海而皆
准。
4.持续反馈、改进
这就不多说了，也是在任何领域通用的实践指导。
5.以人为中心
这条是大家都在说的，但确是最难做到的。我认为这也是敏捷团队和非敏捷团队的本质区别。 让产品更有竞争力、成本更低、设计更完美、更实用，要
持续交付、有效沟通、简单思维，哪个不需要人来解决呢，只有产品团队中的每个人做到自发、自觉把事情做到最适用，才是根本的解决办法。
以我们现在观察到的通讯类产品开发过程来看，作产品的甚至比做项目的更需要实践agile，产品的投入是多大啊，往往超过1年的开发周
期，300人月，可惜的是，300人月投进去，等产品出来的时候已经不满足市场需求了，或者成本太大无法获取收益了。
On 3月31日, 下午3时10分, "jessica....@gmail.com" <jessica....@gmail.com>
wrote: