-
[转]敏捷开发方法
六月的雨 发布于 2011-11-20 20:55:42
一、敏捷开发方法
（一） 说明
本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法，Agile Software Development是一组软件开发方法的总称，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷开发方法又称为“轻量级”开发方法。
下面这段话摘自Martin Fowler的一篇文章：
从无到繁重再到敏捷
多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。
我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。
这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或Jim HighSmith 所称的“巨型”（monumental)方法。
作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。
敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。
但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：
? 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。
我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心
（二） 方法背后的思想
Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想
人们掌握过程（process）可以分为3个阶段：
1 following 遵循一个定义好的process
2 detaching 知道不同process的适用范围，在不同的场合使用不同的process
3 fluent 不关心是否遵循特定的process，知道在什么情况下采用什么动作
软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远重于交流的形式（Effect of communication is more important than the form of communication）。
一般软件开发有两个目标：1 尽快的生产出软件2 为下一个team或项目做准备，有时这两个目标是矛盾的，我们要在这两个目标之间寻求平衡
在软件开发中，人的因素要远远大于过程和技术。人是有缺陷的：
1 容易犯错误，因此必须在错误扩散之前找到并改正错误
2 当觉得可能失去较多的时候，不愿意冒险
3 重新构造而不愿意重复使用已有的东西
4 难于坚持一个习惯
针对个人因素的几个建议：
1 具体的模型较抽象的模型更容易理解
2 从一个例子开始是容易的
3 通过观察他人的成果学习
4 要有足够的不受打扰的时间
5 分配的工作要与个人意向，能力匹配
6 不正确的奖励会有坏作用，从长期看个人兴趣比奖励更重要，培养在工作中的自豪感：
1) pride in work参与工作的自豪感，通常参与一个重要的工作会有自豪感
2) pride in accomplishment 完成工作的自豪感，长期未完的工作会使士气低落
3)pride in contribution 为他人贡献的自豪感
7 鼓励关心其他人的工作和整体的工作
在一个团队之间，交流是最重要的，实践证明面对面的实时的交流是最有效的，对交流的延误会损失信息，白板是最好的交流工具，交流工具的先进并不能提高交流效果。文档的作用是记录和备忘，不能通过文档交流。
敏捷开发方法要避免的过程设计的几个常见错误
1 对所有的项目使用同一种过程
2 没有弹性
3 过于沉重
4 增加不必要的“必须完成”（“should do” is really should？）
5 没有经过实践检验
敏捷开发方法过程设计的几个原理：
1 交互的面对面的交流是代价最小，最迅速的交换信息的方法
2 超过实际需要的过程是浪费的
3 大的团队需要重量级方法
4 处理重大问题的项目需要重量级方法强调
5 增加反馈和交流可以减少中间产品和文档的需求
6 轻量级方法更强调理解（understanding）,自律（discipline）和技能(skill)，重量级方法更强调文档（documentation），过程（process）和正式（formality）
understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分
discipline是指个人主动的完成工作，process指个人根据指令完成工作
skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作
7 确定开发中间的瓶径，提高它的效率
对于瓶径处的工作应该尽量加快，减少重复，（使用更熟练的人，使用更多的人，使用更好的工具，使瓶径处的工作的深入尽量稳定）对于非瓶径处的工作可以多一些重复，在输入还不确定的情况下也可以尽早开始。
这些原理的几个结论：
1 向一个项目增加人员要花费较大代价（constly），因为原有人员和新人员之间的交流要花费大量时间
2 团队的规模经常是跳跃的，例子：需要6个熟练的程序员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，最后增加到了20个不熟练的程序员。
3 应该侧重于提高团队的技能而不是扩充团队
4 对不同的项目使用不同的过程
5 在适用的条件下，轻量级的方法优于重量级的方法
6 对不同的项目要裁减过程
敏捷开发方法的原则是“刚刚好”（Light and Sufficient） -
5年测试学习工作历程
泊涯 发布于 2009-12-21 12:06:10
5年测试工作成长经历
毕业工作5年，辗转了三家公司，一家专门做ERP 的台资公司工作一年半主要是做生管相关的测试，一家专门做金融行业的工作三年多主要是做建行的性能测试以及性能优化工作，第三家公司就是目前中软海晟主要是做烟草行业的软件性能，如果说涉及的岗位应该是业务功能测试人员、QTP自动化功能测试、性能测试优化人员，当然还有时兼职做网管。带过五六个徒弟，也给朋友的软件公司做过测试培训，支持其他行业的软件公司的性能诊断优化，如果回到五年前看待我那时是新人的成长角度，我也发现了当时我自己在学习过程中存在的很多方法方式问题。通过以师带徒或者师傅带我的亲身经历以及同行友人新手入门的学习经历，自我总结下学习，希望能对以后的我学习工作生涯有所监督帮助，毕竟对于一个公司接触的新技术新系统我们都是要以新人的角度去学习去看待，不能自我满足，下面是学习的几点。
一 积极主动
无论在工作上还是生活学习上等方面，我们都要保持主动学习，主动思考，主动承担任务，主动沟通等等，因为一个人的主动性很重要这是说明一个人的做事态度心态或者说为人处事之态。
二 学会学习
在公司学是为了提升自我价值，提高工作效率，也可以说为公司更好的工作服务，因此我们要主动积极学习，而不是什么都是依赖公司灌输学习，公司不是学校，需要改变由老师灌输知识的学习方式。就算公司有相关的技术培训，公司安排有导师带新人，也不能被动的学习，等着别人给你讲。
而且公司给你培训学习是为了让你好好做好份内之事，你走人有其他人排队等待你的职位，而且公司教会你的知识能当你做好这个工作而不会教你精通这个工作，如果要做到更好只能靠自己学会学习，不懂就问，多实践多学习，问同事，问同行，问Google 问baidu等等，身边处处都是学习机会，关键就看有没有留心学习了。
三 主动思考
学习的过程中一定要多主动思考，才能将知识转换为自己的。工作的时候也是这样，先自己想想怎么做，不要等着别人告诉你答案。
四 学会独立解决问题
新人学习碰到问题往往不自信，担心自己的错误而不是其他错误，不敢提出错误指出出错都要先通过他人认证才敢提出，这种想法要克制。碰到技术问题要先学会思考，看怎么解决问题，但是不是专牛角尖整体就围绕那个问题思考是在解决不了就求助，工作任务不能耽搁，只有当自己能够独立解决问题了，才说明成长了。
五 勇于承担责任
工作需要我们每个人都要承担责任。对于新人来说学习别人交接给你的任务，要好好学习主动承担，因为接下来这个任务就是你的，事情就是你承担的，现在虽然有人带你，但是不能一直依赖别人，别人带你时间到就完成任务也许就离职走人，如果你没有勇敢承担下来多学习多问，倒是出问题在承担，事情就大了。说明的不是那人没带好你而是你没承担好你的任务做好自己的职责。
六 学会沟通
工作中我们随时需要与人沟通，因为很少有工作是不需要沟通就能完成的。
七 学会协调
工作还需要我们有良好的协调能力，协调能力对于管理者要求是很高的，对普通员工来说也是需要的。当你没有完成工作需要的资源的时候，就需要想办法协调，而不是在等资源。
八 学会反馈
工作中我们要善于反馈。领导给你安排了学习或者工作任务，如果你不反馈，他就不知道你的进展和困难。千万不要等着领导主动来关心你，主动来找你沟通。有问题更需要及时反馈，不反馈领导就默认你没有问题，一切在按照计划进行，等任务到期了你再来反馈困难就晚了。
九 善于分析问题
在工作中难免碰到问题，当碰到问题时不要像无头苍蝇四处乱撞，也不要就马上指望别人，推卸责任，要先把问题分析清楚，理清问题的来源，描述清楚，在跟别人沟通如何解决。
十 善于总结
我们总是在成功的经验和失败的教训中成长，常常总结会让人进步的更快。把看过的文档内容copy到一起，这不是学习总结，能把学过的东西用自己的语言描述出来，这才是进步。工作的时候也需要随时总结，做的好的地方继续发扬，做的不好的就想办法改进，这样肯定能够进步。
十一 勤奋
对新人来讲，需要勤奋。一般来讲，态度比能力更重要。新人刚去的一段时间领导不能很快的知道工作能力，往往就看勤奋程度。尤其是在胜任工作之前，一定要勤奋。
十二 不找借口
有道是：只会成功找方法，不为失败找借口。什么没经验，专业不对口，工作条件恶劣等等，这些是好的借口原因，但是这也是为自己推卸自己责任的借口，人的一生借口可以很多，但是对待自己的前途不能有任何借口，有自己的弱势需要想办法弥补。
十三 不要提太多要求
对于新人刚进公司，感觉工作压力大，不要抱怨培训太少、资料太少、文档积累太少等等。有这类问题当然要提出，毕竟有时是这些导致你工作没办法胜任的其中一个原因，但是不是主要原因，有时你在要求公司提供什么给你的时候也要想想我们能给公司提供什么，也许我们提供的刚好也是其他新人需要的。而且不要把学习寄托在公司培训上，公司不是学校或者培训机构。资料太少，你自己要主动收集？文档太少，主动沟通获取。
十四 适应环境
不管工作的环境是否跟你想象中的有差距，都别指望别人为你改变环境。只有自己去适应它，生活也是不要抱怨房价高，而让ZF或者开发商降低到你能接受的价格，只能靠自己努力，让房价不是价，这个确实难度高但是也是一个希望目标，工作事业的动力。
十五 感恩之心
要有一颗感恩的心。对于别人给你的帮助一定要表示感谢。无论你导师的指导工作做的是否到位，你都应该感谢他，因为他是义务带你的，不要认为指导你就是他的责任，他也有他的工作要做，当然在工作中难免有些人为认为你没有把你所会的全部叫他而抱怨，我在工作中带过那些人也许是我要求太严格，抱怨我老是让他们学习这个学习那个，但是有些人虽然离职了但是逢年过节都会发信息祝福，成为好友，但是也有碰到学会了就对你的问候之类的置之不理，或者反过来瞧不起你，也许你教会他了他学习能力强了有资格瞧不起你了说明你自己的技术能力有待提高，但是每个人的性格不一，我们要做的是既然人家教会你了，即使你技术超越他了，但是他是你的启蒙老师，永远是你的老师就要尊重他人。个人看法。
十六 不断提高技术能力
IT技术是不断创新技术，技术能力强了，你的机会和选择也就多了，做一个高技术高管理，除非你不做it技术。
标题搜索
我的存档
数据统计
- 访问量: 14363
- 日志数: 15
- 图片数: 3
- 文件数: 1
- 建立时间: 2007-02-12
- 更新时间: 2010-10-29
