怎样实施agile这个东东，agile怎样保证质量的？
110 views
Skip to first unread message
zhuming liu
Jul 26, 2008, 8:56:49 AM7/26/08
to agile...@googlegroups.com
请问几个问题：
1、agile是什么
2、agile规范和实施方法有没有整套指导范本
3、agile是怎样保证交付质量和公司资产积累的
4、agile适用于哪些类型的项目和团队？
5、agile有哪些优点和缺点？
6、agile是不是一种软件工程方法？
Jacky Li
Jul 26, 2008, 8:58:54 AM7/26/08
to agile...@googlegroups.com
鼠标
Jul 26, 2008, 10:21:54 AM7/26/08
to agile...@googlegroups.com
Mo Li
Jul 26, 2008, 1:46:32 PM7/26/08
to agile...@googlegroups.com
答问题1: Jim Highsmith的Agile Project Management中给出的两句话是我个人比较喜欢的对敏捷一词的定义：
Regards,
Li Mo
MSN: icecloud (at) sina.com
BLOG: http://blog.nona.name
1. Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
2. Agility is the ability to balance flexibility and stability.
Regards,
Li Mo
MSN: icecloud (at) sina.com
BLOG: http://blog.nona.name
2008/7/26 zhuming liu <szlzh...@gmail.com>
pipi
Jul 26, 2008, 11:12:34 PM7/26/08
to 敏捷中国
好像回复之后无法显示的？真奇怪
pipi
Jul 27, 2008, 3:13:58 AM7/27/08
to 敏捷中国, lingzh...@ericsson.com, lin...@21cn.com
这段时间做了一些Agile的实践和研究，分享一下我的想法吧
1. Agile是什么
我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
2. agile规范和实施方法有没有整套指导范本
我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
3. agile是怎样保证交付质量和公司资产积累的
关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
的。
这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
值所在即可。
4. agile适用于哪些类型的项目和团队？
我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
5. agile有哪些优点和缺点？
优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
题。
6. agile是不是一种软件工程方法？
我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
1. Agile是什么
我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
2. agile规范和实施方法有没有整套指导范本
我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
3. agile是怎样保证交付质量和公司资产积累的
关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
的。
这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
值所在即可。
4. agile适用于哪些类型的项目和团队？
我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
5. agile有哪些优点和缺点？
优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
题。
6. agile是不是一种软件工程方法？
我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
Jacky Li
Jul 27, 2008, 3:44:12 AM7/27/08
to agile...@googlegroups.com
Mo Li
Jul 27, 2008, 10:54:30 AM7/27/08
to agile...@googlegroups.com
这段时间做了一些Agile的实践和研究，分享一下我的想法吧
1. Agile是什么
我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
如果只说Agile Value/Principle的话，那可以说是一种理念，然而agile的范畴还应当包含以XP, Scrum等组成的方法论。这个等式我认为应该是：Agile = Agile Values/Principles + Agile Methodologies
所以下面No.6中，Agile Methodologies是软件工程方法
2. agile规范和实施方法有没有整套指导范本
我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
我认为应当先从形式开始，然后逐渐总结和改进。某人说，敏捷不敏捷不重要，持续改进才是核心的。 http://www.infoq.com/cn/news/2008/06/martin-agile-scrum
3. agile是怎样保证交付质量和公司资产积累的
关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
的。
这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
热情或者自组织并不是保证质量的充分条件，但持续的沟通和反馈可以尽快的发现质量问题或者提前避免出现质量问题。个人认为，保证交付质量还是要靠具体实施的方法来实现，例如测试和持续集成，而它们则被认为是XP所推崇的实践之一。
关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
值所在即可。
4. agile适用于哪些类型的项目和团队？
我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
5. agile有哪些优点和缺点？
优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
题。
鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？ agile并不是不控制进度，相反，agile方法对进度控制的更精确也更理性。
我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
6. agile是不是一种软件工程方法？
我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
Fred George说，敏捷方法是螺旋模型的一种具体实现。而螺旋模型是软件工程教科书中标准的软件工程方法模型之一。
鼠标
Jul 27, 2008, 11:38:46 AM7/27/08
to agile...@googlegroups.com
徐毅
Jul 27, 2008, 11:41:32 AM7/27/08
to agile...@googlegroups.com
4. agile适用于哪些类型的项目和团队？
我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
5. agile有哪些优点和缺点？
优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
题。
鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？ agile并不是不控制进度，相反，agile方法对进度控制的更精确也更理性。
我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
沟通其实是一个成本很高的活动，不过敏捷接受并非常重视它。Jim Highsmith的书中也提到"Value people, trust them. Mistrust communication. Put practices in place to bridge the difficulties of communication and collaboration between trusted, valuable people."
--
- - - - - - - - - -
Xu Yi, Kaverjody
Certified Scrum Master
Blog : http://damianji.spaces.live.com
- - - - - - - - - -
pipi
Jul 27, 2008, 12:06:14 PM7/27/08
to 敏捷中国, lingzh...@ericsson.com
交流交流，回复见下
On Jul 27, 10:54 pm, "Mo Li" <icecl...@gmail.com> wrote:
> 回复见下
>
> 2008/7/27 pipi <ling...@21cn.com>
么行为也会流于形式了。
>
>
> > 3. agile是怎样保证交付质量和公司资产积累的
>
> > 关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
> > 并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
> > 的。
>
> > 这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
> > Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
>
> > 当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
>
> 热情或者自组织并不是保证质量的充分条件，但持续的沟通和反馈可以尽快的发现质量问题或者提前避免出现质量问题。个人认为，保证交付质量还是要靠具体实施的方法来实现，例如测试和持续集成，而它们则被认为是XP所推崇的实践之一。
>
我想没有任何过程或者实践或者方法的东西可以保证质量（Agile的任何Practice都不行），如果是这样子的话，就不需要一流的软件人才了，找到
一个无敌的方法，然后就可以去招一些普通的开发人员来完成任务了。
但是反过来讲，如果你有顶级的开发人员，但是没有很好的方式来调动他们的积极性和发挥他们的能力，那么这个是PROCESS的问题，这个也是Agile
的核心Principle之一了。
>
>
> > 关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
> > 值所在即可。
>
> > 4. agile适用于哪些类型的项目和团队？
>
> > 我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
>
> 我们目前一个越来越大的团队刚刚拆分成了4个小团队，敏捷的适用性和弱点我的看法如下：http://blog.nona.name/200708256.html
>
>
我不是特别理解你文章阐述的观点，好像没有说Agile的什么弱点。你的结论："敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部
门、公司做事方式的时候。"
这个我觉得做任何事情都是这样子，如果你无法很好的影响周围的人和公司，很多重要的事情都是无法完成的。
>
> > 5. agile有哪些优点和缺点？
>
> > 优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
> > 题。
>
> 鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？
你说的不错（沟通不一定会导致效率问题），但是实际上情况，因为很多中国的开发人员不善于沟通，也不善于在开会时沟通，会议的效率有时候会很低。但是
Agile注重沟通，注定要有比较多的会议，所以会上上的沟通效率是挺重要的。
关于效率的问题，举个例子，以前的方式，是一个软件需求问题，由系统分析人员直接写好，直接分配给开发/测试人员去做就好了，但是现在是要开会大家一起
去讨论解释（而且为了大家都清楚，可以会邀请很多人），如果讨论会议效率不高，是很有问题的。
所以Scrum Master我想其中重要一点也应该是控制会议的效率了。
> agile并不是不控制进度，相反，agile方法对进度控制的更精确也更理性。
>
> 我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
>
Agile对进度的控制的精确度，这个问题很有意思，举个例子，以前的软件开发，项目经理都可以做3-6个月的计划，但是Agile是2-4周一个迭
代，而且不会在前期投入大量精力去分析整个系统的功能需求和复杂性，所以也无法给出很好的进度和时间估算，这个在项目管理上，是很有风险的，是需要项目
经理不断的观察每个阶段的进展，尽快做出调整的，所以对比传统的方法，Agile对项目经理对项目进度计划是有挑战的。
任何项目或者工作，要让人高度motivated，都是很难的，为什么Agile特别难呢？
> > 6. agile是不是一种软件工程方法？
>
> > 我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
> > 定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
> > 艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
>
> Fred George说，敏捷方法是螺旋模型的一种具体实现。而螺旋模型是软件工程教科书中标准的软件工程方法模型之一。
>
>
不知道Fred为啥这么说了，不过我喜欢知道WHY :-)
假设Agile过程是 User Story->Test Case->Design->Coding->Testing，然后经历一系列的短周期的迭
代后再Release，但是我不喜欢用认为"User Story->Test Case->Design->Coding->Testing"就是等
于Agile，如果没有贯彻/应用Agile的Core Value和Practice，这个等号是不成立的。那是"伪"Agile，所以最好不要认为
Agile是一种Process，这样子的话会陷入过程的泥潭。
On Jul 27, 10:54 pm, "Mo Li" <icecl...@gmail.com> wrote:
> 回复见下
>
> 2008/7/27 pipi <ling...@21cn.com>
>
> > 这段时间做了一些Agile的实践和研究，分享一下我的想法吧
>
> > 1. Agile是什么
>
> > 我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
>
> > 根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
>
> > Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
>
> 如果只说Agile Value/Principle的话，那可以说是一种理念，然而agile的范畴还应当包含以XP,
> Scrum等组成的方法论。这个等式我认为应该是：Agile = Agile Values/Principles + Agile
> Methodologies
>
> 所以下面No.6中，Agile Methodologies是软件工程方法
>
>
>
> > 2. agile规范和实施方法有没有整套指导范本
>
> > 我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
>
> > 但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
>
> 我认为应当先从形式开始，然后逐渐总结和改进。某人说，敏捷不敏捷不重要，持续改进才是核心的。http://www.infoq.com/cn/news/2008/06/martin-agile-scrum
>
这个是两个方面吧，要改变意识，先改变行为，确实是这样子的，但是如果核心人员（特别是Agile的发起者），自己都对Agile核心没有深刻理解，那
> > 这段时间做了一些Agile的实践和研究，分享一下我的想法吧
>
> > 1. Agile是什么
>
> > 我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
>
> > 根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
>
> > Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
>
> 如果只说Agile Value/Principle的话，那可以说是一种理念，然而agile的范畴还应当包含以XP,
> Scrum等组成的方法论。这个等式我认为应该是：Agile = Agile Values/Principles + Agile
> Methodologies
>
> 所以下面No.6中，Agile Methodologies是软件工程方法
>
>
>
> > 2. agile规范和实施方法有没有整套指导范本
>
> > 我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
>
> > 但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
>
> 我认为应当先从形式开始，然后逐渐总结和改进。某人说，敏捷不敏捷不重要，持续改进才是核心的。http://www.infoq.com/cn/news/2008/06/martin-agile-scrum
>
么行为也会流于形式了。
>
>
> > 3. agile是怎样保证交付质量和公司资产积累的
>
> > 关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
> > 并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
> > 的。
>
> > 这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
> > Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
>
> > 当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
>
> 热情或者自组织并不是保证质量的充分条件，但持续的沟通和反馈可以尽快的发现质量问题或者提前避免出现质量问题。个人认为，保证交付质量还是要靠具体实施的方法来实现，例如测试和持续集成，而它们则被认为是XP所推崇的实践之一。
>
一个无敌的方法，然后就可以去招一些普通的开发人员来完成任务了。
但是反过来讲，如果你有顶级的开发人员，但是没有很好的方式来调动他们的积极性和发挥他们的能力，那么这个是PROCESS的问题，这个也是Agile
的核心Principle之一了。
>
>
> > 关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
> > 值所在即可。
>
> > 4. agile适用于哪些类型的项目和团队？
>
> > 我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
>
> 我们目前一个越来越大的团队刚刚拆分成了4个小团队，敏捷的适用性和弱点我的看法如下：http://blog.nona.name/200708256.html
>
>
门、公司做事方式的时候。"
这个我觉得做任何事情都是这样子，如果你无法很好的影响周围的人和公司，很多重要的事情都是无法完成的。
>
> > 5. agile有哪些优点和缺点？
>
> > 优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
> > 题。
>
> 鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？
Agile注重沟通，注定要有比较多的会议，所以会上上的沟通效率是挺重要的。
关于效率的问题，举个例子，以前的方式，是一个软件需求问题，由系统分析人员直接写好，直接分配给开发/测试人员去做就好了，但是现在是要开会大家一起
去讨论解释（而且为了大家都清楚，可以会邀请很多人），如果讨论会议效率不高，是很有问题的。
所以Scrum Master我想其中重要一点也应该是控制会议的效率了。
> agile并不是不控制进度，相反，agile方法对进度控制的更精确也更理性。
>
> 我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
>
代，而且不会在前期投入大量精力去分析整个系统的功能需求和复杂性，所以也无法给出很好的进度和时间估算，这个在项目管理上，是很有风险的，是需要项目
经理不断的观察每个阶段的进展，尽快做出调整的，所以对比传统的方法，Agile对项目经理对项目进度计划是有挑战的。
任何项目或者工作，要让人高度motivated，都是很难的，为什么Agile特别难呢？
> > 6. agile是不是一种软件工程方法？
>
> > 我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
> > 定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
> > 艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
>
> Fred George说，敏捷方法是螺旋模型的一种具体实现。而螺旋模型是软件工程教科书中标准的软件工程方法模型之一。
>
>
假设Agile过程是 User Story->Test Case->Design->Coding->Testing，然后经历一系列的短周期的迭
代后再Release，但是我不喜欢用认为"User Story->Test Case->Design->Coding->Testing"就是等
于Agile，如果没有贯彻/应用Agile的Core Value和Practice，这个等号是不成立的。那是"伪"Agile，所以最好不要认为
Agile是一种Process，这样子的话会陷入过程的泥潭。
鼠标
Jul 27, 2008, 12:36:15 PM7/27/08
to agile...@googlegroups.com
关于沟通，沟通不仅仅是成本很高的一件事，而且是难度很大的一件事。而且软件开发本来就是高成本的一件事情。人力是这个活动的最大的成本，因此如果沟通做的不够好的话，一个团队浪费的时间就是很大的成本。因为一个团队的人都在为一个沟通的错误或者无作为工作。而公司和用户就在为这个浪费埋单。像某些时候，用户在看到一个完整的系统之前都不愿意给出更具体的反馈。这就是一个沟通的障碍，如果无法扫除，那么只好眼睁睁的看着这个浪费发生了。（其实也可以闭上眼睛的）
关于积累，最近也在想这个东西。有些时候，Story这个东西能留下些什么呢？当成是写小说那样的，小说写好了，一些人物关系图啊什么的，也是完全可以后补一下的吧。软件可是比小说宏大得多。
关于积累，最近也在想这个东西。有些时候，Story这个东西能留下些什么呢？当成是写小说那样的，小说写好了，一些人物关系图啊什么的，也是完全可以后补一下的吧。软件可是比小说宏大得多。
2008/7/28 pipi <lin...@21cn.com>
Mo Li
Jul 27, 2008, 1:07:59 PM7/27/08
to agile...@googlegroups.com
继续回复见下
2008/7/28 pipi <lin...@21cn.com>
交流交流，回复见下
> 2008/7/27 pipi <ling...@21cn.com>
>这个是两个方面吧，要改变意识，先改变行为，确实是这样子的，但是如果核心人员（特别是Agile的发起者），自己都对Agile核心没有深刻理解，那
> > 这段时间做了一些Agile的实践和研究，分享一下我的想法吧
>
> > 1. Agile是什么
>
> > 我觉得Agile还是一种理念，理念是什么，我想Agile Manifesto和12条Principle算是核心了
>
> > 根据Robert Martin在Agile Software Development书里面所讲的以及我自己的体会，如果要精确定义的话
>
> > Agile = Agile Development + Agile Design 是包括一些开发过程建议以及如何进行设计两部分的。
>
> 如果只说Agile Value/Principle的话，那可以说是一种理念，然而agile的范畴还应当包含以XP,
> Scrum等组成的方法论。这个等式我认为应该是：Agile = Agile Values/Principles + Agile
> Methodologies
>
> 所以下面No.6中，Agile Methodologies是软件工程方法
>
>
>
> > 2. agile规范和实施方法有没有整套指导范本
>
> > 我对XP和SCRUM没有完全了解，我自己团队用的是类似SCRUM方式的，可以认为是有指导范本了（SCRUM可以算是吧）
>
> > 但是要实施这些，真正是要对Agile的理念理解透彻（Manifesto和Principles），否则还是流于形式，不见得有很大帮助。
>
> 我认为应当先从形式开始，然后逐渐总结和改进。某人说，敏捷不敏捷不重要，持续改进才是核心的。http://www.infoq.com/cn/news/2008/06/martin-agile-scrum
>
么行为也会流于形式了。
基本赞同，这就是为什么敏捷咨询的业务变热门的原因。
我想没有任何过程或者实践或者方法的东西可以保证质量（Agile的任何Practice都不行），如果是这样子的话，就不需要一流的软件人才了，找到
>
>
> > 3. agile是怎样保证交付质量和公司资产积累的
>
> > 关于质量保证，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated），
> > 并且通过良好的沟通和团队合作精神，深刻理解客户需求所在（Valuable Software），通过通过Agile Design来保证软件的质量
> > 的。
>
> > 这个也和Agile本身的理解有关，Agile认为软件是Craft，而不是Engineering，就是一种艺术而不是可以通过过程化做出来的。所以
> > Agile更是一种People Oriented的思路，如果把团队每个人的能量都释放出来了，软件质量理论上是最高的了。
>
> > 当然类似测试驱动和持续集成，这个也是可以提高质量的，不过即使不采用Agile的理念开发，这两点也可以去做的。
>
> 热情或者自组织并不是保证质量的充分条件，但持续的沟通和反馈可以尽快的发现质量问题或者提前避免出现质量问题。个人认为，保证交付质量还是要靠具体实施的方法来实现，例如测试和持续集成，而它们则被认为是XP所推崇的实践之一。
>
一个无敌的方法，然后就可以去招一些普通的开发人员来完成任务了。
这句话我看不懂。。。没有方法可以保证质量－>因此不需要一流的软件人才？－> 是由于找到了一个无敌的方法？ 我想你是想说一流人才的技能能够保证质量吧？如果你说的保证质量是指100%的无BUG，那我同意你说的没有东西可以完全保证。但不可否认一些实践可以降低BUG率并提高出产高质量产品的几率，例如pair, tdd等。由于软件毕竟是人写的，而牛人一般会更好的驾驭实践，而这些实践能一定程度降低BUG。
但是反过来讲，如果你有顶级的开发人员，但是没有很好的方式来调动他们的积极性和发挥他们的能力，那么这个是PROCESS的问题，这个也是Agile
的核心Principle之一了。
我不是特别理解你文章阐述的观点，好像没有说Agile的什么弱点。你的结论："敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部
>
>
> > 关于公司资产，我想你说的是文档管理之类吧，我觉得Agile和这个没有冲突，如果公司要求写什么样的文档，还是可以要求，只要让团队明白这些文档的价
> > 值所在即可。
>
> > 4. agile适用于哪些类型的项目和团队？
>
> > 我想从小到大都适用吧，几个人的团队，或者几十个都可以，不过几十个人的团队要分成好多个小团队了。
>
> 我们目前一个越来越大的团队刚刚拆分成了4个小团队，敏捷的适用性和弱点我的看法如下：http://blog.nona.name/200708256.html
>
>
门、公司做事方式的时候。"
这个我觉得做任何事情都是这样子，如果你无法很好的影响周围的人和公司，很多重要的事情都是无法完成的。
我是想说。。。基于"敏捷方法是适应性方法"这个假设，如果说要找出敏捷方法的弱点，那么就是要找出一个能够不断自我改进的过程的弱点，除非是有某种力量阻止它改进，不然它的弱点很快就会被改进掉的。那这种力量只剩下来自外部的力量了。
你说的不错（沟通不一定会导致效率问题），但是实际上情况，因为很多中国的开发人员不善于沟通，也不善于在开会时沟通，会议的效率有时候会很低。但是
>
> > 5. agile有哪些优点和缺点？
>
> > 优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
> > 题。
>
> 鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？
Agile注重沟通，注定要有比较多的会议，所以会上上的沟通效率是挺重要的。
你这里说"很多中国的开发人员"不善于沟通，但并没有足够的数据来证明这一观点。我见过的不论是公司的还是客户的程序员，大多是很愿意说话聊天的。况且，不善于沟通这件事情本身也是可以改变的。我公司就有那种以前很不爱说话的程序员，经过团队的磨合和pair等实践，至少在团队中交流是足够充分了。
另外，你认为"注重沟通"就必定有"比较多的会议"，不知道你这比较多是多少。在我现在的团队，团队全体的正式会议一周平均只有1次，每天的standup大概只有10分钟。算多吗？会议上的沟通是很重要，但会议外，团队开发过程中的随时沟通更重要。
关于效率的问题，举个例子，以前的方式，是一个软件需求问题，由系统分析人员直接写好，直接分配给开发/测试人员去做就好了，但是现在是要开会大家一起
去讨论解释（而且为了大家都清楚，可以会邀请很多人），如果讨论会议效率不高，是很有问题的。
所以Scrum Master我想其中重要一点也应该是控制会议的效率了。
这点毋庸置疑。
Agile对进度的控制的精确度，这个问题很有意思，举个例子，以前的软件开发，项目经理都可以做3-6个月的计划，但是Agile是2-4周一个迭
> agile并不是不控制进度，相反，agile方法对进度控制的更精确也更理性。
>
> 我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
>
代，而且不会在前期投入大量精力去分析整个系统的功能需求和复杂性，所以也无法给出很好的进度和时间估算，这个在项目管理上，是很有风险的，是需要项目
经理不断的观察每个阶段的进展，尽快做出调整的，所以对比传统的方法，Agile对项目经理对项目进度计划是有挑战的。
任何项目或者工作，要让人高度motivated，都是很难的，为什么Agile特别难呢？
你一开始不是说，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated)。 我完全同意，这是敏捷团队的理想情况，也是对人的基本要求，就是每个人都能够被motivated，但这不是在所有的地方都能很容易的做到。
不知道Fred为啥这么说了，不过我喜欢知道WHY :-)
> > 6. agile是不是一种软件工程方法？
>
> > 我想可以说是也可以说不是，说是的话，是因为还是有一些方法可循的，如XP和SCRUM，虽然不是特别规整，但是比较容易和传统的软件开发过程结合起来
> > 定义出合适的开发过程。说不是的话，前面也说了，Agile更多的是理念，Agile也认为软件是Craft，而不是Engineering，就是一种
> > 艺术而不是可以通过过程化做出来的，所以如果要说Agile是一种软件开发过程，也有些违背Agile的理念了。
>
> Fred George说，敏捷方法是螺旋模型的一种具体实现。而螺旋模型是软件工程教科书中标准的软件工程方法模型之一。
>
>
原文忘记放哪里了。不过大概观点是，Barry Boehm在88年提出的螺旋模型一开始无法得以有效的实施，直到90年代中，开发技术的发展才使得螺旋的开发得以普及，诞生了以螺旋模型为基础的许多轻量级方法。后来被统称为敏捷方法。
假设Agile过程是 User Story->Test Case->Design->Coding->Testing，然后经历一系列的短周期的迭
代后再Release，但是我不喜欢用认为"User Story->Test Case->Design->Coding->Testing"就是等
于Agile，如果没有贯彻/应用Agile的Core Value和Practice，这个等号是不成立的。那是"伪"Agile，所以最好不要认为
Agile是一种Process，这样子的话会陷入过程的泥潭。
这句话我也看不懂。。。你假设Agile Process = ... ， 然后在假设这个Agile Process没有贯彻core value，所以不能叫Agile Process？ 那如果贯彻了Core Value的Process呢？
pipi
Jul 28, 2008, 1:51:14 AM7/28/08
to 敏捷中国
继续回复 :-)
>
> > 我想没有任何过程或者实践或者方法的东西可以保证质量（Agile的任何Practice都不行），如果是这样子的话，就不需要一流的软件人才了，找到
> > 一个无敌的方法，然后就可以去招一些普通的开发人员来完成任务了。
>
> 这句话我看不懂。。。没有方法可以保证质量－>因此不需要一流的软件人才？－> 是由于找到了一个无敌的方法？
> 我想你是想说一流人才的技能能够保证质量吧？如果你说的保证质量是指100%的无BUG，那我同意你说的没有东西可以完全保证。但不可否认一些实践可以降低BUG率并提高出产高质量产品的几率，例如pair,
> tdd等。由于软件毕竟是人写的，而牛人一般会更好的驾驭实践，而这些实践能一定程度降低BUG。
我的意思是：很多软件从业人员，都在寻找一种类似“永动机”或者“银弹”的软件工程方法论，梦想应用这种软件开发过程，就一定可以做好好的软件，这个是
一个错误的观点。不管是CMM还是Agile，如果没有优秀的人才，都是无法做出好的软件的。反过来讲，僵化的软件开发过程，则会束缚优秀人才的创造力
和能力。
TDD和持续集成，这个我不反对，但是我认为不是什么本质的东西了，因为代码首先是写出来的，测试做的再好，也不能把垃圾变黄金的。
>
> > > 我们目前一个越来越大的团队刚刚拆分成了4个小团队，敏捷的适用性和弱点我的看法如下：
> >http://blog.nona.name/200708256.html
>
> > 我不是特别理解你文章阐述的观点，好像没有说Agile的什么弱点。你的结论："敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部
> > 门、公司做事方式的时候。"
>
> > 这个我觉得做任何事情都是这样子，如果你无法很好的影响周围的人和公司，很多重要的事情都是无法完成的。
>
> 我是想说。。。基于"敏捷方法是适应性方法"这个假设，如果说要找出敏捷方法的弱点，那么就是要找出一个能够不断自我改进的过程的弱点，除非是有某种力量阻止它改进，不然它的弱点很快就会被改进掉的。那这种力量只剩下来自外部的力量了。
>
还是不太明白，能否对比这个和在公司内部推广CMM有什么不同？CMM的第五级也是自我改进的。
>
>
> > > > 5. agile有哪些优点和缺点？
>
> > > > 优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
> > > > 题。
>
> > 鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？
>
> > 你说的不错（沟通不一定会导致效率问题），但是实际上情况，因为很多中国的开发人员不善于沟通，也不善于在开会时沟通，会议的效率有时候会很低。但是
> > Agile注重沟通，注定要有比较多的会议，所以会上上的沟通效率是挺重要的。
>
> 你这里说"很多中国的开发人员"不善于沟通，但并没有足够的数据来证明这一观点。我见过的不论是公司的还是客户的程序员，大多是很愿意说话聊天的。况且，不善于沟通这件事情本身也是可以改变的。我公司就有那种以前很不爱说话的程序员，经过团队的磨合和pair等实践，至少在团队中交流是足够充分了。
>
善于说话聊天不等于有效率了。
不过我认为程序员还是比较内向的居多。这个和公司文化也有关系，如果是外企，会比较Open一些，国内企业就未必了。
> 另外，你认为"注重沟通"就必定有"比较多的会议"，不知道你这比较多是多少。在我现在的团队，团队全体的正式会议一周平均只有1次，每天的standup大概只有10分钟。算多吗？会议上的沟通是很重要，但会议外，团队开发过程中的随时沟通更重要。
>
Weekly Meeting和Standup Meeting这个OK的了。
比如：User Story &Test Case的讨论沟通会议吗？设计的讨论？代码Review的讨论？这些没有会议吗？
>
> > 任何项目或者工作，要让人高度motivated，都是很难的，为什么Agile特别难呢？
>
> 你一开始不是说，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated)。
> 我完全同意，这是敏捷团队的理想情况，也是对人的基本要求，就是每个人都能够被motivated，但这不是在所有的地方都能很容易的做到。
>
Agile目标就是能够通过各种Practice创造Motivated的团队，由于对比传统的方式，Agile给与大家更多的空间并且强调团队沟通、
合作等等，所以应该是比较容易激发大家的积极性的（相对传统的方式），所以不是太明白你说这个为什么比较难呢？
> 这句话我也看不懂。。。你假设Agile Process = ... ， 然后在假设这个Agile Process没有贯彻core
> value，所以不能叫Agile Process？ 那如果贯彻了Core Value的Process呢？
看来我语言表达不行。。。
贯彻了Core Value的Process，我想即使不用任何Agile业界定义的Practice（如XP或SCRUM），也是一个Agile的
了，所谓条条大路通罗马的了。
>
> > 我想没有任何过程或者实践或者方法的东西可以保证质量（Agile的任何Practice都不行），如果是这样子的话，就不需要一流的软件人才了，找到
> > 一个无敌的方法，然后就可以去招一些普通的开发人员来完成任务了。
>
> 这句话我看不懂。。。没有方法可以保证质量－>因此不需要一流的软件人才？－> 是由于找到了一个无敌的方法？
> 我想你是想说一流人才的技能能够保证质量吧？如果你说的保证质量是指100%的无BUG，那我同意你说的没有东西可以完全保证。但不可否认一些实践可以降低BUG率并提高出产高质量产品的几率，例如pair,
> tdd等。由于软件毕竟是人写的，而牛人一般会更好的驾驭实践，而这些实践能一定程度降低BUG。
一个错误的观点。不管是CMM还是Agile，如果没有优秀的人才，都是无法做出好的软件的。反过来讲，僵化的软件开发过程，则会束缚优秀人才的创造力
和能力。
TDD和持续集成，这个我不反对，但是我认为不是什么本质的东西了，因为代码首先是写出来的，测试做的再好，也不能把垃圾变黄金的。
>
> > > 我们目前一个越来越大的团队刚刚拆分成了4个小团队，敏捷的适用性和弱点我的看法如下：
> >http://blog.nona.name/200708256.html
>
> > 我不是特别理解你文章阐述的观点，好像没有说Agile的什么弱点。你的结论："敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部
> > 门、公司做事方式的时候。"
>
> > 这个我觉得做任何事情都是这样子，如果你无法很好的影响周围的人和公司，很多重要的事情都是无法完成的。
>
> 我是想说。。。基于"敏捷方法是适应性方法"这个假设，如果说要找出敏捷方法的弱点，那么就是要找出一个能够不断自我改进的过程的弱点，除非是有某种力量阻止它改进，不然它的弱点很快就会被改进掉的。那这种力量只剩下来自外部的力量了。
>
>
>
> > > > 5. agile有哪些优点和缺点？
>
> > > > 优点我想是鼓励发挥整个团队的作用，专注于实现客户价值，缺点嘛，项目进度管理需要更好的进行控制，还有就是沟通是需要成本的，可能存在一些效率问
> > > > 题。
>
> > 鼓励沟通应该算是agile的优点。沟通需要成本是正确的，但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通，难道不沟通的方法论反而效率更高？
>
> > 你说的不错（沟通不一定会导致效率问题），但是实际上情况，因为很多中国的开发人员不善于沟通，也不善于在开会时沟通，会议的效率有时候会很低。但是
> > Agile注重沟通，注定要有比较多的会议，所以会上上的沟通效率是挺重要的。
>
> 你这里说"很多中国的开发人员"不善于沟通，但并没有足够的数据来证明这一观点。我见过的不论是公司的还是客户的程序员，大多是很愿意说话聊天的。况且，不善于沟通这件事情本身也是可以改变的。我公司就有那种以前很不爱说话的程序员，经过团队的磨合和pair等实践，至少在团队中交流是足够充分了。
>
不过我认为程序员还是比较内向的居多。这个和公司文化也有关系，如果是外企，会比较Open一些，国内企业就未必了。
> 另外，你认为"注重沟通"就必定有"比较多的会议"，不知道你这比较多是多少。在我现在的团队，团队全体的正式会议一周平均只有1次，每天的standup大概只有10分钟。算多吗？会议上的沟通是很重要，但会议外，团队开发过程中的随时沟通更重要。
>
比如：User Story &Test Case的讨论沟通会议吗？设计的讨论？代码Review的讨论？这些没有会议吗？
>
> > 任何项目或者工作，要让人高度motivated，都是很难的，为什么Agile特别难呢？
>
> 你一开始不是说，Agile讲究的的是通过创建一个自发组织（Self-Organizaed）的团队，每个团队成本都充满热情（Motivated)。
> 我完全同意，这是敏捷团队的理想情况，也是对人的基本要求，就是每个人都能够被motivated，但这不是在所有的地方都能很容易的做到。
>
合作等等，所以应该是比较容易激发大家的积极性的（相对传统的方式），所以不是太明白你说这个为什么比较难呢？
> 这句话我也看不懂。。。你假设Agile Process = ... ， 然后在假设这个Agile Process没有贯彻core
> value，所以不能叫Agile Process？ 那如果贯彻了Core Value的Process呢？
贯彻了Core Value的Process，我想即使不用任何Agile业界定义的Practice（如XP或SCRUM），也是一个Agile的
了，所谓条条大路通罗马的了。
Steven Mak
Jul 28, 2008, 12:19:50 PM7/28/08
to 敏捷中国
> "Fred George说，敏捷方法是螺旋模型的一种具体实现。而螺旋模型是软件工程教科书中标准的软件工程方法模型之一。"
我倒有興趣知道此話出處:
1) 不同的敏捷方法都沒有在其歴史背景提及螺旋模型, 原創者也沒有提過他們的想法來至螺旋模型
2) 螺旋模型在仍然視為 "重型" 方法, e.g. 它對每個 iteration 的 planning 的要求 . e.g.
http://www.cs.virginia.edu/~cs340/slides/cs340-b-process-v2.ppt
3) 螺旋模型和眾多敏捷方法其中一大分別在於風險處理, 螺旋模型十分重視風險並有明確要求. 敏捷方面很著重對用戶的價值, 然後很常見到 "先易
後難" 的建議. (e.g. 可參考 Crystal Clear)
我暫時看不出敏捷方法如何實現螺模型.
On Jul 27, 10:54 pm, "Mo Li" <icecl...@gmail.com> wrote:
> 回复见下
>
> 2008/7/27 pipi <ling...@21cn.com>
>
我倒有興趣知道此話出處:
1) 不同的敏捷方法都沒有在其歴史背景提及螺旋模型, 原創者也沒有提過他們的想法來至螺旋模型
2) 螺旋模型在仍然視為 "重型" 方法, e.g. 它對每個 iteration 的 planning 的要求 . e.g.
http://www.cs.virginia.edu/~cs340/slides/cs340-b-process-v2.ppt
3) 螺旋模型和眾多敏捷方法其中一大分別在於風險處理, 螺旋模型十分重視風險並有明確要求. 敏捷方面很著重對用戶的價值, 然後很常見到 "先易
後難" 的建議. (e.g. 可參考 Crystal Clear)
我暫時看不出敏捷方法如何實現螺模型.
On Jul 27, 10:54 pm, "Mo Li" <icecl...@gmail.com> wrote:
> 回复见下
>
> 2008/7/27 pipi <ling...@21cn.com>
>
zhuming liu
Aug 1, 2008, 12:19:09 AM8/1/08
to agile...@googlegroups.com
非常感谢各位大侠的指导，鄙人感激不尽了
Tony Qiao
Aug 13, 2008, 9:04:06 PM8/13/08
to 敏捷中国
Agile、ＣＭＭＩ以及其它一些方法并不保证质量，只有做软件的具有能动性的人才是保证质量的前提。
On Aug 1, 12:19 pm, "zhuming liu" <szlzhmj...@gmail.com> wrote:
> 非常感谢各位大侠的指导，鄙人感激不尽了
On Aug 1, 12:19 pm, "zhuming liu" <szlzhmj...@gmail.com> wrote:
> 非常感谢各位大侠的指导，鄙人感激不尽了
Reply all
Reply to author
Forward
0 new messages