敏捷开发

在本次敏捷中国2009大会上，来自阿尔卡特-朗讯的何勉与大家探讨了如何在复杂产品和组织中成功实施敏捷开发方法，同时保持产品质量和开发节奏的持续提高，最终获得商业上的成功。而他对敏捷开发中的个人与团队，以及团队、组织要为敏捷做出哪些改变和努力等方面的的独到见解，同样给人启发。

Michele Sliger是《软件项目经理的敏捷之路》一书的编者和顾问，本文总结了她对如何做好敏捷项目经理的一些观点和建议。

作为敏捷宣言的创始人之一，在Dave Thomas看来，敏捷并不是一个全新的事物，凡有经验的程序员在编程实践经验中都会逐渐摸索总结并应用到这些方法。

如果可以方便高效地切分多个团队，而且每个都拥有自己的product backlog，那就这么做好了，每个PB都可以独立划分优先级。假如多个团队共享同一个backlog，这就暗示着多个团队（每个团队的适当人数是7～9人）共享相同的PB，处理PB的优先级时就会出现问题，而且“有条理地选择条目并把其放入Sprint backlog”也将成为麻烦事。

本文向您介绍实践敏捷方法的六个关键点，包括在常规业务中应用敏捷方法、敏捷项目管理中的交叉技能等。

在软件开发中采用敏捷方法需要很多组织级的改变，例如企业文化、个人角色、过程等。作为一个组织，想要进行敏捷转变，就必须学着妥善处理这些变化。

敏捷中国大会2009终于落下了帷幕，总的来说今年的大会办得相当成功。Kent Beck和David Thomas，两位敏捷宣言的签署人，给大会带来了十分精彩的演讲

通过以下两种趋势可在现代软件开发中付出更少、获利更多：敏捷开发和离岸外包。让我们看一下如何以及何时成功结合这两种趋势以增强企业的竞争力。它的具体内容包括：敏捷软件开发趋势、结合趋势、使用正确的实践和工具和通信、通信、通信。

本文给出了敏捷开发中需要注意的九个认识方面的误解，供大家参考，一定要注意哦！

本文作者回顾了目前敏捷开发的大体框架。对于敏捷软件开发，目前理解期最重要的目的是识别软件过程中没有必要的任务或者是性能低下的任务，然后去除之或者改进之。

很多人在尝试实施敏捷开发时说：敏捷开发对人的要求太高了。可是，敏捷对人的要求真的那么高么？本文将对一些对敏捷开发的误解进行诠释。

由InfoQ和ThoughtWorks共同主办的敏捷中国大会2009于2009年9月12日顺利闭幕，约有550人到场参会。在这次大会上，极 限编程创始人Kent Beck、敏捷宣言创始人之一Dave Thomas以及国际敏捷权威专家Fred George以及众多国内外讲师如约分享了他们在敏捷领域的实践心得。

本文简单讲述了重复代码产生的原因到移除重复代码的技巧和我们为什么要移除重复代码。

最近在极限编程Yahoo讨论组上，有些用户讨论了软件重用与XP实践——只在必要的时候才写代码——二者的明显冲突。Ron Jeffries和其他人一起探讨了代码重用的成本与收益，以及在敏捷环境中何时重用，如何重用。

软件架构设计描述的是事物本身，而敏捷开发描述的是创建这个事物的过程。所以敏捷开发和架构是没有直接替代关系的两个范畴。

《敏捷教练》的作者Rachel Davies和Liz Sedley做了一个有趣的演讲，名为“敏捷教练的十大技巧”，或者也可被称为“敏捷教练常犯的10大错误”。

增量迭代开发(敏捷实践之一，它意味着每次迭代的产出只是本次迭代范围内的需求)真的不利于产生好的设计吗?Scrum真的提倡“忽视架构问题”吗?如果没有敏捷技术实践的话，架构设计能有效的演化吗?测试先行式的开发真会产生优雅的设计吗?在红绿条提示下的重构循环只在局部小范围内有效吗?

“个体与交互胜过过程与工具 ”是《敏捷宣言》的第一条价值观。您发现哪些工具对于敏捷开发来说是必不可少的吗？您是否用过阻碍优秀实践和/或沟通的工具？如果用过的话，你用了哪些折衷方案解决这类问题呢？

“系统思考是一扇重新看世界的窗”，那么，我们是否可以用“系统思考”的观点来重新审视软件开发过程，从而找一种更为合适的敏捷开发之路呢?

每个项目经理都听说过梦魇般的编程项目: 项目历时长达预期时间的两倍、严重超出成本预算，又远远看不到结果。幸好，可以使用敏捷编程来解决这些问题。本文从六个方面进行了解答，供大家参考！