敏捷开发资料收集

1、Manifesto for Agile Software Development

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

2、TAPD-腾讯敏捷产品研发平台

3、你如何理解敏捷开发? - 知乎

作者:李国柱 精益敏捷/团队成长转型
链接:http://zhihu.com/question/19645396/answer/57383177
来源:知乎
我想试着从敏捷与传统开发的不同入手来说明敏捷的本质。

传统开发方式和敏捷的不同首先是世界观(软件开发的世界)的不同。

在传统开发方式的世界观里,软件开发过程是确定的、可测的,只要在一开始努力收集到需要的信息并制定好计划,然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好,没收集到必要的信息,计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程,文档,试图让每一步都做到万无一失。

而在敏捷的眼里世界可不是这样的,敏捷认为在软件开发中,世界是变化的,有很多不确定性的。一方面,从认知角度来说,我们是无法在一开始就收集到确保成功所需要的所有信息的,必然是随着开发的进行,我们对正在做的东西的认识才越来越深刻。因而做一段时间后常常有发现需求需要调整,或之前的设计不是最合适的情况发生。另一方面,世界本来就是在快速变化中,我们不得不随之做出调整。因此敏捷的很多实践主要针对如何应对变化。
作者:肖琦
链接:https://www.zhihu.com/question/19645396/answer/24782180
来源:知乎
著作权归作者所有,转载请联系作者获得授权。
从一只产品汪的角度出发,在我看来,敏捷开发就是一种保守主义的产品思维。

先说说建构VS扩展的二元分析框架:

建构论相信,存在一个全知的设计者,能够掌握人类社会的所有知识,然后设计出一个完美的方案,让人们各取所需、良性运转。

而扩展论呢,它认为知识是分散掌握在一个一个具体的人手中,所有的这些人和知识汇聚在一起,才构成了知识的全部。

建构论的产品经理们,会认为开发好产品的方法是可以被完全学习和掌握的,只要有足够优秀的设计者们聚集在一起,只要有足够牛逼的idea,假以时日,就能设计开发出足够优秀的产品。

扩展论的产品经理们,认为开发好产品的方法是不能被完全学习和掌握的,产品不可能覆盖用户的所有使用场景并预解决用户的所有问题,一切的一切,只有让产品直接面向用户,到海量用户中去寻求产品改进的方法。开发一个好产品的知识是分散在一个一个具体的用户手上。

毫无疑问,保守主义站在了扩展论这一边。

埃德蒙·伯克,保守主义的开山祖师说过:「我們擔憂人們會依照自身的理性主導其生活和交易,因為我們懷疑每個人的理性其實是相當有限的。」

应用到产品思维身上,我把它翻译为:「我们担忧产品经理们会依照自身对用户和社会的想象,来固执地设计产品,因为我们怀疑每个人产品经理对用户的理解其实都是相当有限的。」

这其实就是敏捷开发的出发点。一点一点往前拱,寻求渐进式改进,而不是革命式重建,不要求一步到位解决用户的全部问题,不要贪多求全,而是小步快跑,快速检验,在实践和迭代中去发现问题,解决问题,积累宝贵的经验。

我相信每一位信奉敏捷的产品经理,同时也是一名保守主义者,不相信有什么必然通往成功的道路,不相信有什么全知全觉的产品大牛,只相信每一次过往经验的成功和失败, 只相信用户才是检验的唯一标准。

我们永远无法找到真理,我们的每一次努力只是想离它更近一些。

4、敏捷开发在中国的实践面临怎样的挑战? - 知乎

作者:程墨Morgan
链接:https://www.zhihu.com/question/33651587/answer/282469647
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

特定于我国,敏捷开发最大的问题不是不敏捷,而是太敏捷。

你肯定看过这样的对联:“这个功能很简单,怎么实现我不管。”横批:“明天上线。”

江湖上流传的也是这样的传说,某某团队听说竞争对手在做什么功能,于是加班加点,一晚上就把这个功能抢先做出来了。

从商业角度出发,敏捷肯定是有好处,但是现在敏捷被滥用了,这屈指可数的几个“敏捷案例”被无限夸大,说得好像敏捷压倒一切,敏捷就是快,敏捷就是上午有个点子就撸起袖子干,下午就要实现完,晚上就上线最好。

愚蠢!幼稚!

和所有正常的开发流程一样,敏捷的终极目的是让开发过程可控,而不是失控,这么疯狂“试错”,拍脑袋就干,不是失控是什么?可是现在我国就是有一帮这样愚蠢幼稚的家伙在自行解读敏捷。

宇宙之道,在于阴阳平衡,敏捷应该兼顾快速反应和团队的长期成长,什么都只要快就行了,还要估计story point干嘛,还要统计load factor干嘛,现在我国敏捷实践的问题就是只偏向快速反应,至于方向判断和精细设计全都不要,阴盛阳衰。

了解更多职业道理请关注
@程墨Morgan

5、敏捷开发——互联网时代的软件开发方式

6、敏捷软件开发 - 维基百科,自由的百科全书

7、敏捷开发之Scrum扫盲篇 - 远哥 - 博客园

原文地址:https://www.cnblogs.com/xkxf/p/9047480.html

时间: 2024-10-11 04:00:13

敏捷开发资料收集的相关文章

iOS开发之资料收集

github排名:https://github.com/trending, github搜索:https://github.com/search. 此文章转自github:https://github.com/Tim9Liu9/TimLiu-iOS UI 下拉刷新 EGOTableViewPullRefresh- 最早的下拉刷新控件. SVPullToRefresh- 下拉刷新控件. MJRefresh- 仅需一行代码就可以为UITableView或者CollectionView加上下拉刷新或者

敏捷开发-Scrum 实战

最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量. 参考资料: <轻松Scrum之旅-敏捷开发故事>.<敏捷无敌> 硝烟中的Scrum 和 XP 火星人敏捷开发手册 Scrum-Checklists 维基百科:http://zh.wikipedia.org/wiki/Scrum Scrum 工具 禅道 JIRA+GreenHopper Scrum 中的角色 Scrum

柯南君 教你看敏捷开发のScrum是如何工作的?

现在敏捷开发是越来越火,人人都在谈敏捷,人人都在学习Scrum和XP,柯南君的朋友"远哥"是一位项目leader,柯南君与远哥促膝长谈,远哥也毫不避讳,知无不言言无不尽,把自己对Scrum的理解和自己工作中的经验积累与柯南君分享,在这里柯南君代替远哥与大家分享一些经验. 一. 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用

腾讯敏捷开发及快速迭代

腾讯敏捷开发及快速迭代 http://www.edu-hb.com     2013-6-4 15:23:50     来源: itwriter      从 2006 年开始,腾讯的研发规模开始膨胀,开发模式急需规范和标准化,到底走 IPD(集成产品开发)还是 Agile(敏捷)的开发路线,公司管理层也在为拿不定主意而犯愁,之后研发管理部开始与 ThoughtWorks 公司接触,逐渐将敏捷产品开发引入进来,并正式命名为 TAPD(Tencent Agile Product Developme

柯南君: 教你看敏捷开发のScrum是怎样工作的?

柯南君 教你看敏捷开发のScrum是怎样工作的? 如今敏捷开发是越来越火,人人都在谈敏捷.人人都在学习Scrum和XP,柯南君的朋友"远哥"是一位项目leader.柯南君与远哥促膝长谈.远哥也毫不避讳.知无不言言无不尽.把自己对Scrum的理解和自己工作中的经验积累与柯南君分享,在这里柯南君取代远哥与大家分享一些经验. 一. 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心.迭代.循序渐进的开发方法. 怎么理解呢?首先.我们要理解它不是一门技术,它是一种

用户故事驱动的敏捷开发 – 1. 规划篇

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆.就算是最终打算一试,也经常会不知如何开始.这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的.也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品! 今天

【DevOps】团队敏捷开发系列--开山篇

随着软件发布迭代的频率越来越高,传统的「瀑布型」(开发-测试-发布)模式已经不能满足快速交付的需求.2009 年左右 DevOps 应运而生,开发运维一体化,通过自动化工具与流程让整个软件开发构建.测试.发布更加快捷.频繁.高效和可靠. 本系列教程目录 本系列将详细讲解Devops落地细节.将构建整个持续集成与交付的一整套体系与流程.对于未来要开篇的系列博文列表如下: [DevOps]团队敏捷开发系列(一)--开山篇 [DevOps]团队敏捷开发系列(二)--版本控制之道Git [DevOps]

编程心法 之 Scrum - Agile 敏捷开发

Scrum是一种敏捷开发的方法 先定一个能达到的小目标 Scrum 团队 包括产品负责人.开发团队和Scrum Master Product Owner 产品负责人:管理代办事项和优先级的唯一负责人. 相关术语 Sprint 敏捷开发的周期,一般情况下需要2-6周时间,最终应该完成一个可演示给客户或者是可发布的产品 Epic 可以认为就是一个大的Stroy, 还没有拆解, 是对大Story的一个描述性标签 提问:Epic和User Story之间的区别是什么? 回答:准确的说,Epic是比用户故

互联网公司的“敏捷开发”流程是怎么样的,每个职位的角色和分工是什么?

作者:暗灭 第一   为什么需要敏捷开发. 在几万年以前,软件项目的开发都是以年来计算的,这代表什么意思呢 ?需求设计了半年多,方案设计做了半年多,开发了三年多,测试了半年多,修改Bug用了半年多.总计花了很长很长的时间,然后上线后发现有很多需求已经不存在了,同时又出现了很多新的需求. 怎么办?继续改.这一改又是半年多的时间过去了.马丹用户的需求还再改,怎么办? 这是困扰软件开发项目的最大的问题,越大的项目,参与的人越多,风险越大.文档越规范,维护起来的难度就越高,导致项目中遇到的问题越来越多.