这段时间做了一些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的理念了。
4. agile适用于哪些类型的项目和团队?
我想从小到大都适用吧,几个人的团队,或者几十个都可以,不过几十个人的团队要分成好多个小团队了。
5. agile有哪些优点和缺点?
优点我想是鼓励发挥整个团队的作用,专注于实现客户价值,缺点嘛,项目进度管理需要更好的进行控制,还有就是沟通是需要成本的,可能存在一些效率问
题。
鼓励沟通应该算是agile的优点。沟通需要成本是正确的,但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通,难道不沟通的方法论反而效率更高? agile并不是不控制进度,相反,agile方法对进度控制的更精确也更理性。
我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
交流交流,回复见下
> 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所推崇的实践之一。
>
一个无敌的方法,然后就可以去招一些普通的开发人员来完成任务了。
但是反过来讲,如果你有顶级的开发人员,但是没有很好的方式来调动他们的积极性和发挥他们的能力,那么这个是PROCESS的问题,这个也是Agile
的核心Principle之一了。
我不是特别理解你文章阐述的观点,好像没有说Agile的什么弱点。你的结论:"敏捷什么情况下适用性不好呢?答案是,当你没有办法改变你周边的人、部
>
>
> > 关于公司资产,我想你说的是文档管理之类吧,我觉得Agile和这个没有冲突,如果公司要求写什么样的文档,还是可以要求,只要让团队明白这些文档的价
> > 值所在即可。
>
> > 4. agile适用于哪些类型的项目和团队?
>
> > 我想从小到大都适用吧,几个人的团队,或者几十个都可以,不过几十个人的团队要分成好多个小团队了。
>
> 我们目前一个越来越大的团队刚刚拆分成了4个小团队,敏捷的适用性和弱点我的看法如下:http://blog.nona.name/200708256.html
>
>
门、公司做事方式的时候。"
这个我觉得做任何事情都是这样子,如果你无法很好的影响周围的人和公司,很多重要的事情都是无法完成的。
你说的不错(沟通不一定会导致效率问题),但是实际上情况,因为很多中国的开发人员不善于沟通,也不善于在开会时沟通,会议的效率有时候会很低。但是
>
> > 5. agile有哪些优点和缺点?
>
> > 优点我想是鼓励发挥整个团队的作用,专注于实现客户价值,缺点嘛,项目进度管理需要更好的进行控制,还有就是沟通是需要成本的,可能存在一些效率问
> > 题。
>
> 鼓励沟通应该算是agile的优点。沟通需要成本是正确的,但它不一定会导致效率问题。据此认为agile存在效率问题更是无法说通,难道不沟通的方法论反而效率更高?
Agile注重沟通,注定要有比较多的会议,所以会上上的沟通效率是挺重要的。
关于效率的问题,举个例子,以前的方式,是一个软件需求问题,由系统分析人员直接写好,直接分配给开发/测试人员去做就好了,但是现在是要开会大家一起
去讨论解释(而且为了大家都清楚,可以会邀请很多人),如果讨论会议效率不高,是很有问题的。
所以Scrum Master我想其中重要一点也应该是控制会议的效率了。
Agile对进度的控制的精确度,这个问题很有意思,举个例子,以前的软件开发,项目经理都可以做3-6个月的计划,但是Agile是2-4周一个迭
> agile并不是不控制进度,相反,agile方法对进度控制的更精确也更理性。
>
> 我认为敏捷的另一个弱点就是需要每个成员高度motivated。而这一点确实是很难的。
>
代,而且不会在前期投入大量精力去分析整个系统的功能需求和复杂性,所以也无法给出很好的进度和时间估算,这个在项目管理上,是很有风险的,是需要项目
经理不断的观察每个阶段的进展,尽快做出调整的,所以对比传统的方法,Agile对项目经理对项目进度计划是有挑战的。
任何项目或者工作,要让人高度motivated,都是很难的,为什么Agile特别难呢?
不知道Fred为啥这么说了,不过我喜欢知道WHY :-)
> > 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,这样子的话会陷入过程的泥潭。
非常感谢各位大侠的指导,鄙人感激不尽了