敏捷宣言:
个体和交互胜过过程和工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
敏捷是一种一人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法,敏捷方法可以快速地响应变化,它强调团队合作,人们专注于具体可行的目标,这就是敏捷精神。敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。
没有任何计划在遇敌后还能继续执行,对于软件行业,真正的敌人是变化,敏捷,一种成功的软件开发方法,成功与否取决于你识别和适应变化的能力
敏捷工具箱:
习惯一:做事WIKI:用于项目组内知识共享
版本控制:项目开发中所有的产物,都要有版本控制系统统一管理
单元测试:用代码来检查代码,是开发者获得反馈的主要来源
自动构建:又称为持续集成
习惯二:欲速则不达出了问题,最高优先级应该是解决问题,指责不能修复bug,如果你说的话只是让事态更复杂,或者只是一味的抱怨,或者伤害了他人的感情,那么你无意中在给问题火上浇油,把矛头对准问题的解决办法,而不是人,这是真正有用处的正面效应。用于承认自己不知道答案,会让人感觉放心,一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起,因互相帮助,而不是互相指责
不要坠入快速的简单修复之中,要投入时间和精力保持代码的整洁、敞亮,代码复审和单元测试是不错的实践
习惯三:对事不对人
不要否定别人的想法,而是提出引导性的问题,让他意识到自己的问题
做出决策有两种极端:1.一个人说了算 2.需要全票通过
有一些技巧可以解决这类问题:
让我们骄傲的应该是解决了问题,而不是比较谁出的主意更好1.设定最终期限:实现制定好时间限制,没有最好的答案,只有更合适的答案,有最终期限可以避免讨论无休止的进行
2.逆向思维:如果找不到最合适的方案,就找缺点最少的方案
3.设立仲裁人:仲裁人可以防止明星员工操纵狐疑,并及时打断假大空式的发言,仲裁人应该专注于调停,而不是发表自己的观点
4.支持已经做出的决定:一旦方案被确定了,每个团队成员都必须通力合作,努力实现这个方案
注意点:
1.尽力贡献自己的好想法,如果你的想法没有被采纳也无需生气,不要因为只是想体现自己的想法而对拟定的好思路画蛇添足
2.若对一个想法有成见,你很容易提出一堆不太可能发生或不太实际的情形去批驳他
习惯四:排除万难,奋勇前进
要诚实,要有勇气说出实情,有时,这样做很困难,所以我们要有足够的勇气
如果你说天要塌下来了,但其他团队成员不赞同,反思一下,也许你是对的,但你没有解释清楚
如果你说天要塌下来了,当其他团队成员不赞同,考虑一下,也许他们是对的
习惯五:跟踪变化
习惯六:对团队投资唯有变化是永恒的
如何更上技术变化的步伐,有几种建议:迭代和增量式的学习、了解最新行情、参加本地的用户组活动、参加研讨会议、如饥似渴的阅读
你不需要精通所有技术,但需要清楚知道行业的动向,从而规划你的项目和职业生涯
习惯七:懂得丢弃找出团队中的高手擅长的领域,帮助其他的团队成员在这些方面迎头赶上
唤起人们对技术和技巧的激情,将会对项目大有裨益
习惯八:打破沙锅问到底学习新的东西,丢弃旧的东西,在学习一门新技术的时候,要丢弃会阻止你前进的旧习惯
习惯九:把握开发节奏不停的问为什么,不能只满足于别人告诉你的表面现象,要不停地提问直到你明白问题的根源
习惯十:让客户做决定在很多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律,那样的随机安排很难处理,你根本不知道明天将会发生什么。
保持事件之间稳定重复的间隔,更容易解决常见的重复任务。
项目开发需要有一致和稳定的节奏。编辑、运行测试、代码复审,一致的迭代,然后发布。如果知道什么时候开始下一个节拍,跳舞就会更容易。
习惯十一:让设计知道而不是操纵开发开发者、经理或者业务分析师不应该做业务方面的决定,用业务负责人能够理解的语言,向他们详细解释遇到的问题,并让他们做决定
习惯十二:合理地使用技术设计可以分为两层:战略和战术,前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样设计,更确切的说,它应该只描述总体战略,不应深入到具体的细节,不要一开始就进行战术设计,它的重点是集中在单个的方法或数据类型上,这是,更适合讨论如何设计类的职责
好的设计应该是正确的,而不是精确的,不应该涉及不确定或者可能会发生变化的细节,它是目标,不是具体的处方
计划是没有价值的,但计划的过程是必不可少的
首先决定什么是你需要的,接着为这些具体的问题评估使用技术,对任何要使用的技术,多问一些挑剔的问题,并真实地做出回答
新技术就应该像是新的工具,可以帮助你更好的工作,它自己不应该成为你的工作
习惯十三:保持可以发布
提交代码的流程:
保证你的系统随时可以编译、运行、测试并立即部署1.在本地运行测试:先保证代码可以编译,并且能通过所有的单元测试。接着确保系统中的其他测试都可以通过
2.检出最新的代码
3.提交代码
习惯十四:提早集成,频繁集成
习惯十五:提早实现自动化部署代码集成是主要的风险来源,要想规避这个风险,只有提早集成,持续而有规律地进行集成
成功的集成意味着所有的单元测试不停地通过
通常,每天要和团队其他的成员一起集成代码好几次,比如平均每天5-10次
习惯十六:使用演示获得频繁反馈一开始就进行全面部署,而不是等到项目的后期
使用部署系统安装你的应用,在不同的机器上用不同的配置文件测试依赖的问题,质量保证人员要像测试应用一样测试部署
习惯十七:使用短迭代,增量发布在开发的时候,要保持应用可见,每隔一周或者两周,邀请客户,给他们演示最新完成功能,积极获得他们的反馈
迭代开发时在小且重复的周期里,完成各种开发任务:分析、设计、实现、测试和获得反馈,所以叫做迭代
发布带有最小却可用功能块的产品,每个增量开发中,使用1-4周左右迭代周期
没有规定一个迭代必须要紧挨着一个迭代,可以在迭代中间安排一些其他任务
习惯十八:固定价格就意味着背叛
习惯十九:守护天使让团队和客户一起,真正地在当前项目中工作,做具体实际的评估,由客户控制他们要的功能和预算
习惯二十:先用它再实现它编写能产生反馈的代码
好的单元测试能够为你的代码问题提供及时的警报,如果没有到位的单元测试,不要进行任何设计和代码修改
编码之前,先写测试
先写测试,就会站在代码用户的角度来思考,而不仅仅是一个单纯的实现者,这样做是有很大区别的,你就会发现因为你自己要使用它们,所以能设计一个更有用、更一致的接口
习惯二十一:不同环境,就有不同问题
习惯二十二:自动验收测试使用持续集成工具,在每一种支持的平台和环境中运行单元测试,要积极的寻找问题,而不是等问题来找你
习惯二十三:度量真实的进度为核心的业务逻辑创建测试,让你的客户单独验证这些测试,要让它们像一般的测试一样可以自动运行
习惯二十四:倾听用户的声音不应该去计算工作量完成百分比,而应该测定还剩下多少工作量没有完成,如果你最初估计这个任务需要40小时,在开发了35小时后,你认为还需要另外30个小时的工作,那就得到了很重要的度量结果,如果真正花费的时间比最初估计的时间要长,没有关系,这可以作为下一次估计的参考
度量的粒度以工作日作为时间单元比较合适
习惯二十五:代码要清晰地表达意图每一个抱怨的背后都隐藏了一个事实,找出真相,修复真正的问题
没有愚蠢的用户,只有愚蠢、自大的开发人员,你的用户有可能会阅读所有的文档,记住其中的所有内容,但也可能不会
习惯二十六:用代码沟通PIE原则,代码必须明确说出你的意图,而且必须富有表达力,这样可以让代码更易于被别人阅读和理解。代码不让人迷惑,也就减少了发生潜在错误的可能
习惯二十七:动态评估取舍如果必须通读一个方法的代码才能了解它做了什么,那么开发人员先要投入大量的时间和精力才能使用它,反过来讲,只需短短几行注释说明方法行为,就可以让生活变得轻松许多,开发人员很快可以了解到它的意图、它的期待结果,以及应该注意之处
不要注释绝大部分代码,特别是在方法体内部,源代码可以被读懂,不是因为其中的注释,而应该是由于它本身优雅而清新------变量名运用正确、空格使用得当、逻辑分离清晰,以及表达式非常简洁
如何命名很重要,程序元素的命名是代码读者必读的部分,通过使用细心挑选的名称,可以向阅读者传递大量的意图和信息
注释可用来为读者指定一条正确的代码访问路线图,为代码中的每个类或模块添加一个短小的描述,说明其目的以及是否有任何特别需求,对于类中的每个方法,可能要说明下列信息:
使用细心选择的、有意义的命名。用注释描述代码意图和约束,注释不能替代优秀的代码
- 目的:为什么需要这个方法?
- 需求(前置条件):方法需要什么样的输入,对象必须处于何种状态,才能让这个方法工作?
- 承诺(后置条件):方法成功执行后,对象现在处于什么状态,有哪些返回值?
- 异常:可能会发生什么样的问题?会抛出什么样的异常?
解释代码做了什么的注释用处不那么大,相反,注释要说明为什么会这样写代码
习惯二十八:增量式编程对任何单个因素独断地强调,而不考虑它是否是项目成功的必要因素,必然导致灾难的发生
没有适宜所有状况的最佳解决方案,你必须对手上的问题进行评估,并选出最合适的解决方案
考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了,就将注意力放在其他因素上,不要为了感觉上的性能提升或者设计的优雅,而将设计复杂化
在很短的编辑/构建/测试循环中编写代码,这要比话费更长时间仅仅做编写代码的工作好得多,可以创建更加清晰、简单、易于维护的代码
习惯二十九:保持简单
习惯三十:编写内聚的代码不要让自己被迫进行过份设计,也不要将代码过分复杂化
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因,否则不要使用模式、原则和高难度指数之类的东西
习惯三十一:告知,不要询问让类的功能尽量集中,让组件尽量小,要避免创建很大的类或组件,也不要创建无所不包的大杂烩类
作为某段代码的调用者,开发人员绝对不应该基于被调用对象的状态来做出任何决策,更不能去改变该对象的状态,这样的逻辑应该是被调用对象的责任,而不是调用者的,在该对象之外替它做决策,就违反了它的翻转原则,而且为bug提供了滋生的土壤
告知,不要询问,不要抢别的对象或是组件的工作,告诉它做什么,然后盯着你自己的职责就好了
习惯三十二:根据契约进行替换
习惯三十三:记录问题解决日志替换原则,相对基类的对应方法,派生类服务(方法)应该不要求更多,不承诺更少,要可以进行自由的替换,在设计类的继承层次时,这是一个非常重要的考虑因素
习惯三十四:警告就是错误维护一个问题及其解决方案的日志,保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了
习惯三十五:对问题各个击破嵌入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法,签入构建工具中的代码不应该产生任何警告信息
习惯三十六:报告所有异常单元测试带来的积极效应之一,是它会强迫形成代码的分层,要保证代码可测试,就必须把它从周边代码中解脱出来
在解决问题时,要将问题域与其周边隔离开,特别是在大型应用中
习惯三十七:提供有用的错误信息必须要处理所有的异常,倘若可以,从失败中恢复再好不过,如果不能处理,就要把异常传播到方法的调用者,这样调用者就可以尝试对其进行处理了
习惯三十八:定期安排会面时间一方面要提供给用户清晰、易于理解的问题描述和解释,使他们有可能寻求变通的之法,另一方面,还要提供具备关于错误的详细技术细节给用户,这样方便开发人员寻找代码中真正的问题所在
一种实现上述两个目的的方式:显示清晰的错误说明,该错误信息不只是简单的文本,还包括了一个超链接,用户、开发人员、测试人员都可以由此链接得到更多信息
要保证会议议题不会发散,每个人都应该只回答下述三个问题。
- 昨天有什么收获
- 今天的计划
- 面临着哪些障碍
习惯三十九:架构师必须写代码
习惯四十:实行代码集体所有制积极的编程可以带入深入的理解,不要使用不愿意编程的架构师---不知道系统的真实情况,是无法展开设计的
习惯四十一:成为指导者让开发人员轮换完成系统不同领域中不同模块的不同任务
不要无意间丧失了团队的专家技能,如果某个开发人员在某个领域中机器精通,不妨让他作为这方面的驻留专家,而且系统的其它部分代码对他开放,这样对团队和项目都很有帮助
习惯四十二:允许大家自己想办法与团队其他人一起共事是很好的学习机会,知识有一些很独特的属性;假设你给别人钱的话,最后你的钱会变少,而他们的财富会变多,但如果是去教育别人,那双方都可以得到更多的知识
通过详细解释自己知道的东西,可以使自己的理解更深入,当别人提问时,也可以发现不同的角度
习惯四十三:准备好后在共享代码指给他们正确的方向,而不是直接提供解决方案,每个人都能从中学到不少东西
习惯四十四:做代码复查绝不要提交尚未完成的代码,故意签入编译未通过的代码或者是没有通过单元测试的代码,对于项目来说,应被视作玩忽职守的犯罪行为
习惯四十五:对于提升代码质量和降低错误率来说,代码复查是无价之宝,如果以正确的方式进行,复查可以产生非常实用而高效的成果,要让不同的开发人员在每个任务完成后复查代码
发布进展状况、新的想法和目前正在关注的主题,不要等着别人来问项目状态如何