在公司做了三次相关敏捷的主题:现有项目的敏捷之路,SCRUM,敏捷软件测试。

  但是,有朋友说这几次都是站在管理的角度,程序员自己如何才能做做到敏捷呢?回来想想再结合之前看过的书总结出了如下18条,于是起名“降龙十八掌”吧。到底哪一条对哪一掌,大家自己对吧。

  1. 态度积极。做事时专注,有问题积极找人帮忙同时也乐于帮助别人,勇于承认错误,如果你从没犯过错误,说明你可能没努力去工作。

  2. 深入理解需求。对一个需求要尽可能多的理解,不要急于着手编码。

  3. 不做世外高人。不要一个人默默无闻的编码,多阅读同事的代码,也请同事阅读自己的代码,保证代码易读,易理解。

  4. 敢于发表意见。发现问题时,敢于提出来,不能任何事情都是全票通过,这样会扼杀创新,容纳自己并不接受的想法,贡献自己的好想法。

  5. 持续学习,乐于分享。如果你很长时间不学习,发现很多东西很陌生,但如果你天天学习,每天学的东西很少,不要见到新技术出现“少小离家老大回”的现象。分享自己的知识,提高自己的团队,同时提高自己。

  6. 保持合适的节奏。不要闲,忙,互上互下,冰火两重天。

  7. 积极与客户沟通。对需求不确定的任何地方一定要问客户,给出建议同时让客户做决定。但不要问很多没有价值且耗费客户很多时间的问题。

  8. 重视设计,每一个系统,每一个功能都需要设计,敏捷不是没有设计。但是设计不要太细,包含系统的结构或类的职责,形式可以多样,白板,草图,贴张纸可以,终还是通过代码来体现。

  9. 尽早集成,频繁提交。注意提交不要破坏代码库。提交前在本地运行测试,获得新代码,再运行本地测试,通过后提交代码。原子提交,一旦功能不能使用,可以立即快速回滚, 这样可以尽早暴露集成的问题,使修复bug的成本大大减小。

  10. 用单元测试守护代码。自动化用户验收测试。这样可以快速回归。

  11. 自动化部署。尽早实现一键部署,节省时间且可以尽早知道系统需要的软硬件环境。

  12. 尽早提交,尽早得到客户的反馈。

  13. 一定要个人计划,而且每天度量自己的进度,SCRUM里可以通过站立会议。要有自己的Backlog

  14. 虚心接受用户的抱怨,认真对待抱怨,找出客户抱怨的原因

  15. 代码集体所有,任何人都可以改自己的代码,自己也可以改任何人的代码。

  16. 代码会说话,利用你的代码和同事沟通,代码要清晰表达自己要干什么。保持代码简洁易于理解,至少公用方法简洁易于理解。减少代码注释,用有意义的类名,方法名,参数名自己来解释。

  17. 分离解决问题,修复Bug时把其它的地方隔离起来,像修复电器一样,会把线路板拆下来修。比如使用Mock等方法。

  18. 给客户显示可以查询错误的信息。比如可以在错误信息前加一错误号,这样可以方便开发人员在错误日志里定位。