我心中的敏捷：两种世界观

【简介】感谢网友“昵称酱”参与投稿，以下是小编帮大家整理的我心中的敏捷：两种世界观（共5篇），仅供参考，欢迎大家阅读。

篇1：我心中的敏捷：两种世界观

系列文章目录索引：《我心中的敏捷》

引言：

“实践、总结，再实践，再总结”,我的很多研发观念，都是在这样的过程中不断形成和改进的，而我之所以能坚持这样不断作下去，是因为我想把一件事不断的作得更好，一直逼近我自己想要的极致，而事实上，因为每位开发者所在的领域、所掌握的工具、所面对的客户都可能有所不同，采用不同的开发方式本身就是非常自然而然的。其实，我的这个系列文章，有一部分是在说研发，而更重要的一部分是在说我们应该以什么样的思想、什么样的态度，以及什么样的方法来作事，而无论“这件事”是研发，还是销售，是产品，还是公司，我想，很多的东西，都同样适用。经过前面一虚一实的两篇文章后，下面引出的这篇文章仍然偏向于“虚”,仍然偏向于方法论，至于对大家有没有用，要看大家思考的深度和探索的力度。

正文：

“敏捷开发”中的“敏捷”二字，其最本质的含义是： 对用户需求的快速响应。而其产生，发展乃至壮大的前提是： 随着信息化进程的不断推进，有信息化需求的企业和用户，也在不断提高自己提出IT需求的能力，他们的需求不仅越提越专业，而且，也越提越快，经常变化和更新。作为一个系统实现者，作为这个商业生态圈的服务提供者，你无法否决用户提出的需求，你所能作的，很多的时候，也最多是建议用户多给你点时间来完善，让用户多交点钱。而你，该作的，还是要作。推而论之，在这种情况下，谁家能更快更好的响应用户不断变化的需求，谁就能争取到用户。

从本质上说，敏捷开发，是一种非常务实的开发方式。这种“务实”可以通过以下方面表现出来：

1. 它强调对于用户不断变化的需求一定要尽快的快速响应，虽然用户需求的频繁更改是让开发者最为恼火的，但是，没办法，作为一个商业行为，无论你的用户提出什么修改需求，你都要尽量满足，只有这样你才能争取到用户，才能让项目带来利润。

用户关注的是“他自己是否能用这个系统给自己带来好处”, 用户始终不会关心“开发者因为这项修改将付出多大的代价”. 虽然不近人情，但作生意就是这样。

2. 敏捷开发的兴起，是因为创建者们发现很多用户的很多需求在很多的情况下是无法事先全部预想好的，是在开发过程中不断完善起来的。传统的瀑布开发模型，强调在开发之前先建立完整以及完备的开发计划和开发内容，强调“先规划再开工”, 是一种先全部计划好了，然后再按步就搬进行操作的方式，

而敏捷开发，更相信世界上根本不存在多么周详的计划能把所有的事情在事前全部计划好，它相信，“需求变更本身就是需求存在的一种形式”.

所以说，传统的瀑布开发模型与敏捷开发模型相比较，在形式上，可能是一个先全面计划再执行，而另一个是先计划一部分然后即刻开工，在开工中不断完善； 但是在本质上，这两种开发模型却代表了两种完全不同的开发世界观，甚至就是开发者的世界观的反应：

前者假设世界太美好，假设自己太强大，假设团队太牛B, 一切都能搞得定，所以，他们设想着所有的东西只要列得出来，就能按计划完成；

后者假设自己并不强大，假设团队也不是万能的，假设用户需求肯定是会变化的，假设用户本身还需要不断学习和提高，假设用户自己可能都搞不清自己想要什么样的系统，假设要想作出用户想要的系统只有在作的过程中与用户不断交流与确认，假设这种交流是不可能一次性完成而是一项长期的任务，长期到甚至在软件交付了以后也仍然需要不断追踪用户需求的最新变更。

瀑布开发，假设世界是无限美好的，一切尽在掌控中； 而敏捷开发，则假设世界本身是有缺点的，而且，有不少东西是我们只能影响但掌控不了的。相比较而言，敏捷开发的开发思想就要来得更为务实和坦率。

在瀑布模型中，一旦发生需求变化，给项目带来的风险是巨大的。而如果不变，那很可能作出来的东西就不是用户想要的东西，那这个东西对于用户而言还有什么意义？所以，在瀑布开发模型中，不管开发团队愿意不愿意接受需求变更，这种变更的客观事实已经给项目本身带来太多的风险。

而敏捷开发呢？是不是就没有瀑布模型的那些开发步骤： 需求提出-->需求冻结-->需求实现-->实现评估？答案是否定的，敏捷开发当然也会有这些过程，但是，敏捷开发对于瀑布模型最大的改进在于： 把瀑布模型中的大版本切成敏捷开发中的一个个小版本，从而大大缩短软件发布小辨本的时间周期，始终坚持尽最快速度向用户提交一个最新功能的版本，让用户在体验中不断与开发团队共同完善。

而不是象瀑布开发模型那样，用户提出了需求后，开发团队闷头作一两年，发布一个很大的很全的但可能是不合用户本意的系统。敏捷开发的发布周期通常是两周到两个月，它不要求每次都要发布很多的内容，但它要求最好要向你的最终用户频繁发布你的最新版本。

所以，从这一点来看，敏捷开发与传统开发，最大的不同点正是在于“敏捷”二字，而其对用户的具体表现就是： 用户可以拿到新版本的周期由一两年大大缩短到了两周到两个月。

来自：blog.csdn.net/sodme/archive//03/24/4021583.aspx

篇2：我心中的敏捷

系列文章目录：

我心中的敏捷(1)：首先不应该是噱头

我心中的敏捷(2)：我们的实践

我心中的敏捷(3)：两种世界观

我心中的敏捷(4)：多样的形式与不变的本质

我心中的敏捷(5)：SCRUM之项目分解与控制力

引言：

这是继“作团队感悟”之后的又一个系列文章，在这个系列文章里，主要记录和描述了我对于敏捷开发、敏捷团队以及敏捷公司的理解，

我心中的敏捷

，

我认为，敏捷和迭代，已经是一种世界观和方法论，而不仅仅是一种技术手段或者工具。融汇贯通敏捷和迭代的深层次思想，不仅仅能帮助我们提高研发水平和研发质量，更重要的，它可以更好的帮助一个团队或者一个公司走向成功。

篇3：我心中的敏捷：我们的实践

系列文章目录索引：《我心中的敏捷》

引言：

第一篇文章，说到了敏捷方法论和世界观的问题，看似有点玄了，其实，任何一个可以坚持下去的人或者任何一件可以坚持作下去的事，它的背后，都一定有一套自己的逻辑体系在支撑，而这个逻辑体系，就可以看作是它作事作人的方法论，敏捷二字，其含义有两层： 高效率，高质量。其目的也绝不仅仅在于“快”研发，它的终极目的，是推动整个产品或者公司团队加速面向市场提供好产品的速度和质量。在这一篇文章中，将会详细谈到我们自己的具体作法，当然，这已经是一年前的文章，很多作法可能已经因应现在的形势进行了改进，但基本的思想已暗含其中。你的作法可能与此不一样，但任何已经学会驾奴开发过程的同仁应该都会明白这些作法背后的含义。

正文：

敏捷开发，最最主要的，是要理解敏捷的本质是什么？在我看来，敏捷的本质，很简单： 如何快速出东西，快速的出质量高的东西。

由此，我认为开发过程中的所有东西，都应该围绕着这两个主题展开： 快速，质量。

写程序写了这么多年，我们大家可能都有点感受： 写得越来越没感觉了，写得越来越麻木了。因为，随着自身的成长和成熟，很多开发过程中会出现的常规难题，被我们一一攻破，似乎在我们眼前的路，已经没有了太多的挑战，技术难度的挑战。

为什么会有这种感觉？在这里，我要毫不客气的指出： 那是因为你把自己仅仅当成了一个有任务就作，无任务就闲的技术人员，而非产品人员。当你把自己定位成一个产品人员之后，你才会知道用户需求是如此多而复杂，我们还有如此多的事要作，要去作得更好。

什么是技术人员？什么是产品人员？

我给一个狭隘的解释：

技术人员，就是只泡在技术的单纯世界里，而不太注重用户感受以及用户体验的人，他们把攻克一个技术难题当作是对自己能力最大的肯定；

产品人员，是指从产品出生到投放，都一直能为用户考虑，为用户着想，在每一个细节上让用户爽而不是让开发者自己爽，他们把用户口碑当作是对自己能力最大的肯定。

那么，我们要作什么样的人？要作什么样的技术人？

对于一个研究院所，他可以选择成为一个单纯的技术人员。但是，如果放在绝大多数直接面对市场的大中小企业里，他就必须选择成为一个从产品角度考虑的技术人员，要让自己成为产品人员。

我坚持认为，技术有没有价值，不是靠别人推荐，不是靠专家认证，也不是靠发了多少研究论文，而是技术本身有没有在创造价值，有没有很好的在创造价值。我是一个彻头彻尾的实用主义者，我鄙视所有的学院派。

马云说： 找人，首先，要找价值观相似的人。而什么样的价值观才是相似的？

马云，从一个企业管理者的角度，认为跟他价值观相似的应该是这种人： 进入阿里，就要想着长期耐得住寂寞的作下去，作对社会有推动的有价值的事，不要只想着钱，不要只想着干几个月就走人。

而我，除了认同他的这些观点之外，想在招技术人员方面额外加一点： 我们不要学院派。我把这一点同样视为价值观是否相似的一个基本考核点，单纯的学院派，不适合来我们团队。

在网易，我们的团队，是一个狼性文化十足的团队，这在现今的网易，可能是一个非常独特的特例。但是，我们正用自己的成绩，效率和质量来证明着自己。没有狼性文化的团队，注定无法成长； 而没有狼性文化的公司，也注定无法壮大。

我先介绍一下我们的作法。在我们这整个项目中，配备了接近10名程序，5位QC（质量测试）,近10位策划，

根据项目内容，分成了五个小组： A, B, C, D, E.平时的工作，是将整个项目内容拆解，各个小组平行推进。这是我们总体的人员分配。

我所在的组，是D组，我们的程序有两位，一个客户端，一个服务端，其他人员： 一个QC, 一个策划。我们组共计四人。我们小组，从7月份开始，接手作游戏内的一个比较大的群体系统： 势力系统。这是比公会系统更为庞大和繁杂的系统，是将来带动玩家互动的主要系统之一。在接手这个新系统时，我就在尝试一种新的开发方式。

原来的开发方式是：

策划人员出策划案，程序将策划案实现，QC对已经实现的系统进行测试。

我们现在的方式是：

策划人员出策划案，所有人员对策划案进行流程模拟，找问题，程序开始带着QC一起设计，程序将系统进行实现，QC对系统可行测试。

而更具体的步骤是：

1. 策划出案子；

2. 所有人员（程序，QC）通读案子，各自模拟流程进行推导，看有没有破绽及断层之处，提交策划人员进行修正； 修正完后，QC开始进行测试用例设计。

3. 程序制定数据包协议，对协议进行走读： 向其他程序，QC以及策划讲解这个数据包过来之后会如何进行处理，包括要进行的判断，要作的逻辑，以及广播包要发的玩家对象范围。这一步，最大的好处，是让每个参与者都明白我们的逻辑底层到底是如何走的。

4. 程序设计关键数据结构，这一步，是带着QC一起作。一个程序功能，就两点： 数据结构+算法。而首先，最主要的是决定采取什么样的数据结构，数据结构进一步决定了采取什么样的算法。这个数据结构，其意义已经超出程序代码本身，这个数据结构会牵涉到QC, 牵涉到策划。在我们这个项目中，数据结构最主要的内容就是各种各样的配置表，这个表的内容应该含有哪些内容，这些内容应该如何组织和约定，就成为提高程序，QC和策划工作效率的一个重要环节。

5. 程序对功能进行逐块实现。但在这里的实现，也会有多种不同的方式。我们的作法是： 先实现最基本的功能，让客户端和服务器端能尽快联调起来，然后各自发布一个基本流程版本给对方： 客户端给服务器端发布一个可用的客户端，服务器端发布一个可用的服务器给客户端，两个人分别用这个可用的版本进行各自的细节完善。

6. 程序实现功能后，按照QC之前设计的测试用例对自己作的程序进行自测。由于时间及专业有限，这种自测，主要是测关键逻辑及易错部分，全面的覆盖性测试还需要依赖QC人员自己完成。

7. 程序自测完成后，带QC及策划人员进行代码走读，将产品正式交付QC进行测试。之所以在这个环节加入代码走读这一项，其目的也只有一个： 让项目的每一个参与者，都能非常清楚程序底层到底是如何实现的。这一点，对QC进行全面测试非常非常重要，QC在进行代码走读之后，可能会对当初的测试用例进行修正。当然，这里的代码走读，还是具有一定技巧的，因为QC和策划毕竟不是专业的技术人员，对于算法和太深层次的技术细节可能并不容易理解，所以，这里的走读，要作到既能让他们能理解关键逻辑，也要让他们不要因为无法理解众多技术细节而出现过多的懊恼情绪，这也会影响工作效率。

8. QC第一轮测试完成后，策划人员对已经实现的功能进行游戏体验，提出修正和完善意见。

以上，就是我们在实际开发中所采用的一套完整的方式。其核心思想有几点：

1. 让项目的每一个参与者，都成为项目本身的主人。这种主人翁思想的植入，是通过让他们每个人都参与到项目的各个环节中，让他们每一个人都仔细了解项目的每一处细节实现来体现。

2. 将QC的优势发挥在开发设计期，而不是后面的交付期。因为到了交付期，其实，产品已经出来了，如果到那时发现问题要进行修改，其带来的代价将远远大于开发期的修改。QC的测试用例，以及“测试式思维”, 是对程序人员固有思维方式的一个非常有利的促进和监督。

我们的开发方式还在不断的总结和完善中，还有很多很多我认为非常有效的方法和感悟想和大家分享，在下篇文章中再接着谈。

来自：blog.csdn.net/sodme/archive//03/23/4015875.aspx

篇4：我的世界观

“啊！我的世界观‘毁灭’啦！”你们肯定会问：“怎么回事？世界观怎么会‘毁灭’呢？”别急，听我慢慢说给你听。

这周三最后一节课是兴趣课，而我的兴趣课是学吹葫芦丝。

王老师让我吹三级曲目——《月光下的凤尾竹》，我心想：幸亏我在家里练过，不然就惨了！整整一首，在第九行的“3——5——6——5——”这段音符音特别长，等我吹完，才喘一口气，就像把五脏六腑吐出来似的，我的脸被憋得通红通红的，像一个刚成熟的苹果。

王老师突然给了我一个伴奏，我的天啊！心想：王老师，求求你放过我吧！刚才清吹都喘不过来气，更别提跟伴奏啦！但又想：这是老师给我的挑战，我必须硬着头皮上！这也是检验我的成果的时候！

刚开始还不错，可后来伴奏旋律渐渐快了，我跟不上节奏，我慢，它快，它快，我慢......等我吹完，就差点没气了，这时，我的脑袋一片空白。王老师对我说：“不行，回家再听听伴奏，再练练。”这时的我特别沮丧，一点成就感也没有了。世界观“毁灭”了！

这才刚刚开始，三级曲目就给了我一个“下马威”，我得继续加油，重建世界观！

作者：张欣宇

篇5：我的世界观读后感

读了文章，我首先十分敬佩爱因斯坦，他的人生已被这篇文章梳理。

爱因斯坦说，人是为他人而生存，这就是人与人之间的彼此依靠。比如，中国有5亿非农村户口的人，但他们却需要8亿农民为他们耕地、种粮食，并且还得做成更好的面包、薯片、巧克力，也做成了不同的服装：羽绒服、外套、T―恤衫，然后给那5亿非农村户口的人吃饱、穿好。

爱因斯坦说，安逸和享乐不是真正意义上的生活。是的，真正意义上的生活，应该是精神上的一种触动。就如你十分的有钱，并且住在一个别墅里，一直在享受着物质上的奢侈生活，可你自己却没有感觉到。其实你一生中最大的痛苦就是没有享受到精神意义上的自由，这将会是多么悲惨的事啊！人应该满足于精神上的生活，不只是满足于物质上的生活。

读了爱因斯坦的文章，使我受益匪浅：这篇文章使我了解到人是为别人生存的，人无法得到物质上的自由以及精神上的生活是最重要的。