Tips for agile developers

周末读完了这本《敏捷开发修炼之道》,跟《程序员修炼之道》基本上是同一个性质的,理论还是很好,但是这些和“前端优化”类似,大家都知道,但是都不去做。养成一个习惯是很难的事情,有些是知道“如果我有了这个习惯就受益匪浅”,只是在平时coding的时候很容易遗忘。whatever,这里面有些理论感觉我是还用不到的,先把有些启发和共鸣的摘录下:

  • 在敏捷团队中,如果你向敏捷团队中的同事抱怨,他们会说:“好,我能帮你做什么?”他们把精力直接放到解决问题上,而不是抱怨。他们的动机很明确,重点就是做事,不是为了自己的面子,也不是为了指责,也无意进行个人智力角斗。勇于承认自己不知道答案,这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作,应该互相帮助,而不是互相指责。
  • 对事不对人。//cmt:这个态度大家平时都知道,可是我还是感觉能纯粹的做到对事不对人很难。在讨论一些事情的时候,难免会把“谁说的这句话”的因素不知不觉的放进来,这样的坏处是,很容易让你对这个人看法影响到你对他提的意见的看法,这样很不好。以后在讨论的时候,应该脑袋里把要解决的事情放在一边,讨论问题的人放在一边,把每个人看作是提问问题的“木头人”,每个人都一样,只针对他们提问问题本身的意见做思考。

  • 做正确的事。要诚实,要有勇气说出实情。有时,这样做很困难,所以我们要有足够的勇气。
  • 一个学习型的团队才是较好的团队。每周,要求团队中的一个人主持讲座。他会给大家介绍一些概念,演示工具,活着做团队感兴趣的任何一件事情,你可以挑一本书,给大家说说其中一些特别内容,项目或者实践。无论什么主题都可以。读书小组逐章一起阅读以本书,会非常有用,但是要选好书;坚持有计划有规律的举行讲座。//cmt:我们的qc组在这点上做的不错,每周有qc技术沙龙,范围也很广泛。
  • 在许多不成功的项目中,基本上都是随意安排工作计划,没有任何的规律。敏捷项目会有一个节奏和循环。最大的节拍就是迭代时间,一般是1-4周的时间。当时间到的时候,迭代就完成了,那部分是固定不变的,但是在一个具体的迭代中完成哪些功能是灵活的。换句话说,你不会改变时间,但是你可以改变功能。
  • 小而可达到的目标会让每个人全速前进。庆祝每一次难忘的成功。//cmt:这点倒是和韦尔奇在《赢》里的一条类似:懂得欢庆,也就这条最容易做:这个地方腐败就好。
  • 设计可以分为两层:战略和战术。前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样的设计。更确切的说,它应该只描述总体战略,不应该深入到具体的细节。
  • 白板,草图,便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力,而不是启发你的工作。
  • 根据需要选择技术。首先决定什么是你需要的,接着为这些具体的问题评估使用技术。对任何要使用的技术,多问一些挑剔的问题,并且真实的做出回答。//cmt:我觉得这个很重要,尤其是我们这些程序员大都有追求新技术的天性,出来一个就心里痒的想要用到项目里来,然后为了使用给自己找一堆理由。之前一段时间,我觉得老庄是保守派的人,总是对新技术或新方法不轻易使用,现在看来那才是比较稳重和成熟的作法,而我当时是多么幼稚。
  • 敏捷的一个主要特点就是持续开发。
  • 统一过程和敏捷方法都使用迭代和增量开发。对付大项目,最理想的办法就是小步前进,这也是敏捷方法的核心。
  • 依赖于单元测试。//cmt:这个部分要看下python的web自动化测试框架。
  • 度量真实的进度:我们不应该去计算工作量完成的百分比,而应该测定还剩下多少工作量没有完成。不要用不恰当的度量来欺骗自己或者团队,要评估那些需要完成的待办事项。在安排时间上,一周工作40小时,不是说你就有40小时的编码时间。你需要减去会议,电话,电子邮件以及其它相关活动的时间。
  • 每一个抱怨的背后都隐藏了一个事实。没有愚蠢的用户,只有愚蠢,自大的开发人员。
  • 代码,对于类的每个方法,可能要说明下列信息:目的,为什么需要这个方法;需求(前置条件),方法需要什么样的输入,对象必须处于何种状态,才能让这个方法工作;承诺(后置条件),方法成功执行后,对象现在处于什么状态,有哪些返回值;异常,可能会发生什么样的问题,会抛出什么异常。
  • 代码被阅读的次数要远远超过被编写的次数,所以在编程时多付出一点努力来做好文档,会让你将来受益匪浅。
  • 保持简单。//cmt:是我一直想遵守的kiss原则。
  • 维护一个问题及其解决方案的日志。保留解决方案时修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。要记录团队做出一个重要决策的原因。//cmt:blog,rss feed,wiki都是很好的工具。
  • 提供有用的错误信息。用户在给支持团队打电话报告问题时,我们希望他们提供足够多且好的信息,以帮助尽快识别问题所在。
  • 协作:定期安排会面时间。开立会(站着开会),每个人只回答三个问题:昨天有什么收获?今天计划要做哪些工作?面临哪些障碍?立会的时间最长不能超过30分钟,10~15分钟比较理想。要注意报告的细节。在会议中要给出具体的进度,但是不要陷入细节之中。
  • 强调代码的集体所有制。让开发人员轮换完成系统不同领域中的不同模块的不同任务。
  • 成为指导者意味着要分享,而不是固守,自己的知识,经验和体会。意味着要对别人的所学和工作感兴趣,同时愿意为团队增加价值。一切都是为了提高队友和你的能力与水平,而不是为了毁掉团队。
    然而,努力爬到高处,再以蔑视的眼神轻视其它人,这似乎是人类本性。也许再没有意识到的情况下,沟通的障碍就已经能够建立起来了。团队中的其它人可能处于畏惧或尴尬,而不愿提出问题,这样就无法完成知识的交换了。这类团队中的专家,就象是拥有无数金银财宝的有钱人,却因健康原因而无福享受。我们要成为指导别人的人,而不是折磨别人的人。
  • 感觉不是在以填鸭式的方式给予别人帮助。用问题来回答问题,可以引导提问的人走上正确的道路。
  • 代码复查。开发人员对代码复查感到担心,允许别人看他们的代码,会让他们有受威胁的感觉。这影响了他们的自尊心。他们担心在情感上受到打击。
  • 代码复查的基本检查项:代码能否被读懂和理解?是否有任何明显的错误?代码是否会对应用的其它部分产生不良影响?是否存在重复的代码?是否存在可以改进或重构的部分?
  • 如果不及时跟进讨论中给出的建议,代码复查是没有实际价值的。要确保参与人员得到每次复查活动的反馈。作为结果,要让每个人指导复查完成后所采取的行动。
  • 及时通报进展与问题。发布进展状况,新的想法和目前正在关注的主题,不要等别人来问项目状态如何。

到这里基本上把本书的核心部分写完了,要附上我一直坚持的《程序员修炼之道》上的一点:由那个青蛙骨头汤的故事引出来的道理:做催化剂。在小组中,想做的东西可能很多,很多未必都要身体力行的做这些,知道所有细节,有时候只要你开个头,“催化”一下这个项目的产生就可以了。去年的cottage即是如此。

之前在韦尔奇的《赢》里看到一句话:在你成为领导之前,成功只同自己的成长有关。当你成为领导以后,成功都同别人的成长有关。//很明显跟领导这词相距甚远,只是这句话还是给自己带来了一些启发。

与君共勉。

– EOF –

0 comments:

Leave a Reply

Your email address will not be published. Required fields are marked *