敏捷开发的优缺点

~保持微笑~ 2014-01-26 10:52:05
现在很多项目都流行套用敏捷开发,最近和朋友又谈起这个话题,想大家一起探讨一下,你们的敏捷开发给项目带来的好处有什么,又存在什么不好的地方?

我个人觉得:

敏捷确实是项目进入实质开发迭代阶段,用户很快可以看到一个基线架构版的产品。

敏捷注重市场快速反应能力,也即具体应对能力,客户前期满意度高。

但敏捷注重人员的沟通,忽略文档的重要性,若项目人员流动大太,又给维护带来不少难度,特别项目存在新手比较多时,老员工比较累。

需要项目中存在经验较强的人,要不大项目中容易遇到瓶颈问题。

你们都在项目中遇到过那些呢?你对敏捷的态度又是怎样的。



...全文
38948 24 打赏 收藏 转发到动态 举报
写回复
用AI写文章
24 条回复
切换为时间正序
请发表友善的回复…
发表回复
  • 打赏
  • 举报
回复
引用 23 楼 ArayChou 的回复:
敏捷很适合对不未知领域的探索。 传统模式搞半年,给客户一看,这是啥?然后就SB了。 敏捷的意思就是我做一点就给客户看看,客户反应不好赶紧转向or掉头。
敏捷的思想还是很值得推荐推广的, 但是落实到不同的开发团队中,肯定结果和效果也不同。。
ArayChou 2016-06-23
  • 打赏
  • 举报
回复
敏捷很适合对不未知领域的探索。 传统模式搞半年,给客户一看,这是啥?然后就SB了。 敏捷的意思就是我做一点就给客户看看,客户反应不好赶紧转向or掉头。
列子汤问 2016-05-31
  • 打赏
  • 举报
回复
同意,敏捷开发对技术人员的技术功底要求特别高,对业务人员的要求也特别高。
smallcrocodile 2016-05-11
  • 打赏
  • 举报
回复
学习ing,敏捷是什么?敏捷不是什么!
loneba 2016-01-20
  • 打赏
  • 举报
回复
什么是敏捷开发? 这个没有完全的定义吧?符合敏捷宣言的实践应该都算吧?关键看能不能用好!
gauldoth 2016-01-11
  • 打赏
  • 举报
回复
敏捷这个词本身就很误导,让人有一种很快能完成开发的感觉. 我觉得叫灵敏比较好. 这种不是银弹的东西,到了国内,就变成银弹了.
Bonnie-Wu 2015-12-30
  • 打赏
  • 举报
回复
感觉目前国内把敏捷有点用烂了。 大家一谈到敏捷,就会联想到各种敏捷实践、各种敏捷提倡的会议,建立敏捷宣言等等,但真正有多少,是真正理解了这里面的内涵?公司领导的急功近利,基本上抹杀了敏捷的可持续性,一个公司推行敏捷一段时间后,随着一个个人员的流动,最后就变成了一个不三不四的框架。 一些小的公司,我感觉倒是不用提敏捷不敏捷,在都不确定自己该干嘛的时候,可以先引入看板的管理,可能是更好的途径。
皇帝猎萌 2015-11-27
  • 打赏
  • 举报
回复
个人以为敏捷开发 特别适合小型的企业需求……
kernelkoder 2015-09-29
  • 打赏
  • 举报
回复
敏捷基本是扯淡的一种方式
shyboyyang 2015-01-05
  • 打赏
  • 举报
回复
个人感觉最大的优点是通过客户的参与来避免浪费时间和金钱搞一些没用的东西。
  • 打赏
  • 举报
回复
借口一多,什么东西都会变了味道。
木子007 2014-10-24
  • 打赏
  • 举报
回复
敏捷是不是 每天都要汇报工作进度啊,模块功能细化。
OTIZG 2014-08-14
  • 打赏
  • 举报
回复
敏捷开发不是不可取,但是要想成功实施,必须满足前置条件: 1、项目组的技术牛人比较多,又或者说对项目的类似经验特别丰富,无需新学习业务知识(新手多千万别用) 2、项目有一个比较好的设计架构,尤其在设计之初就考虑好一些关键性的问题,比如:性能...(曾经项目组在这上面栽了大跟头) 3、团队成员的自觉性,又或者为职业操守(每天不是为了工资而在工作) 4、项目Leader的团队领导能力,而不是管理能力(有人可能还区分不清这二者的区别吧) 5、公司领导以及PMO项目管理人员的支持,以及他们对敏捷开发是否真正理解 6、项目的客户理解与配合 .... 还有很多,在这给大家抛砖引玉,看看是否还有其他经验
台风双头蛇 2014-08-07
  • 打赏
  • 举报
回复
敏捷的前提是需要有一个合格的团队. 这个团队包含了开发过程中的各种角色, 而这些角色在其本职工作的能力上是平均水平以上的. 这样的要求其实是一个敏捷开发的缺点, 也就是说基础条件较高. 能及时交付或者说更早的将软件面对客户是一个比较大的亮点. 这样客户可以在开发的过程中就参与, 给出其中肯的评价, 当然客户的水平也必须是平均线以上的, 也就是说客户不会随便乱喷需求, 随便乱喷赞美.
kingr2014 2014-07-24
  • 打赏
  • 举报
回复
对参与员工的个人能力和态度要求比较高,否则会造成散漫和难以管理。 其实无论哪种模式,关键在于管理。敏捷只是现在一个时髦的词,基础还是我们传统提倡的协作沟通高效。
liming_sd 2014-06-12
  • 打赏
  • 举报
回复
缺点:在设计上不会像瀑布式做得那么到位。
liming_sd 2014-06-12
  • 打赏
  • 举报
回复
软件敏捷开发宣言中提出了以下12个原则: 1. 持续、尽早交付有价值的软件以满足客户,是我们优先要做的首要任务。 2. 拥抱需求变更,甚至是在开发的后期。敏捷过程利用变更为客户带来竞争优势。 3. 频繁交付可执行的软件,从几周到几个月,交付时间越短越好。 4. 在整个项目过程中,业务人员和开发人员必须每天在一起工作。 5. 激发每个团队成员的积极性来打造项目。为他们提供所需的环境与支持,并且信任他们可以完成工作。 6. 在一个开发团队内部最有效的传递信息的方式是面对面的交流。 7. 可执行的软件是进度的首要检验对象。 8. 敏捷过程倡导可持续发展。赞助商,开发人员和用户应该尽可能保持一致的步伐。 9. 保持关注先进的技术与设计会增强敏捷性。 10. 尽量用艺术化来简单阐述未完成的工作是很有必要的。 11. 最好的架构,需求,和设计出自于自我组织管理的团队。 12. 每隔一段时间,回顾反思如何让团队变得更高效,并相应地调整其行为。 我觉得是:人的作用、灵活机动、及时沟通、有效纠偏、允许变更、快速交付。
Alan_Wdd 2014-02-28
  • 打赏
  • 举报
回复
引用 5 楼 ckc 的回复:
文档不文档并不是敏捷的重点。 敏捷的思路就是尽可能让客户参与到项目之中,客户及时使用产品,及时提出意见, 这样有助于得到一个真正符合客户需要的东西。 文档有积极性的一面,又有消极性的一面,理论上适度的文档会让我们的利益最大化, 可是实践中什么叫“适度”?每个人有每个人自己的看法。 敏捷的思路不注重文档而是注重客户的感受,因为我们最终想得到的并不是文档而是客户的使用情况。
ckc 2014-02-18
  • 打赏
  • 举报
回复
文档不文档并不是敏捷的重点。 敏捷的思路就是尽可能让客户参与到项目之中,客户及时使用产品,及时提出意见, 这样有助于得到一个真正符合客户需要的东西。 文档有积极性的一面,又有消极性的一面,理论上适度的文档会让我们的利益最大化, 可是实践中什么叫“适度”?每个人有每个人自己的看法。 敏捷的思路不注重文档而是注重客户的感受,因为我们最终想得到的并不是文档而是客户的使用情况。
缪军 2014-02-13
  • 打赏
  • 举报
回复
引用 楼主 ztj188 的回复:
但敏捷注重人员的沟通,忽略文档的重要性....
恰恰相反,敏捷方法重视文档是放在第一位的, 敏捷方法让文档成为"活的",高度重用的, 而不是传统意义的项目开始一周后就难以为继的word和Excel, 而实现这些目标,需要实实在在的硬技术, 而不是装出站立会议和结对编程的样子就能号称敏捷方法的
加载更多回复(3)

1,557

社区成员

发帖
与我相关
我的任务
社区描述
软件工程 敏捷开发
社区管理员
  • community_144
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧