敏捷开发中的态度问题

某位大佬的话：

                 选定了要走的路，就是选定了它通往的目的地。

有几个关键词，为做事而工作。欲速则不达。对事不对人。排除万难，奋勇前进。

       举个简单的例子，我在实习项目中间，犯过一个错误，在进行某个指标的计算的时候，没有考虑除0异常，这种情况很少发生，偏偏就在我的继任者接手的时候发生了。他有一天很兴奋的说，“你的程序有bug”。我当时应激反应就是你告诉我这个有pi用。举这个例子，我想说明一个问题就是，我们在出了问题的时候，下意识的都想到这个是谁负责的。要找出元凶，仿佛找出元凶是我们的目的，找到元凶问题就解决了，并且这个问题就不会再发生了。而且更要命的是，找出元凶后，接踵而来的是无止境的埋怨、指责，这无异于火上浇油。老板也不会因为你发现了这个问题。揪出了元凶而对你有任何好感，资本家永远关注的是利益，只有解决了问题才有利益。相反这个时候，如果你能多想想，为了解决这个问题，现在能做些什么？这样的话，就会给人一种很正面的感受。这是敏捷开发中的一个很重要的习惯。即所有的工作为做事。我们不是批评家，不是以找出多少别人的问题来评价。

       还有就是规范、标准。符合了标准不代表不出问题。总结一下，指责不能修补bug。“这不是我的错”这句话不对，“这全是你的错”这句话就更不对了。

       码农都会遇见一个问题，出现一个bug的并且时间紧迫的时候，快速修复确实可以解决问题，有时候只需要加若干行代码。它就可以正常工作了。但下面的做法能更好的诠释谁是拙劣的代码工人，谁是优秀的程序员。优秀的程序员会挖掘更深层次的原因，去理解为什么要加这几行代码。别的地方也有这个问题么，可能你会问，敏捷开发的目的不就是解决问题么。这里很快的解决问题了，为什么又不行了？我在上篇文章中提过。敏捷开发主要是在三个方面迭代：预防问题，发现问题，解决问题。解决问题的时候又要想着预防问题。这次的bug可能加几行代码就解决了。但是随着时间的推移，别的地方会不会出现由这个原因导致的更严重的bug呢。这就是所谓的，千里之堤毁于蚁穴。快速修复的诱惑，很多人把持不住。但是程序崩溃的痛苦，这些人同样承受不了。

       个人英雄主义的编码方式不被推崇。代码复审很有意义，提交代码前，把代码发给同组的其他人检查，这种传阅的方式，特别有用。

       不懂的代码，千万别动。

        还有一个就是开会、讨论的时候，对事不对人，反对性意见不是不能提，但是一定要注意提出问题？脱离实际的反方观点，会让会议没有效率？什么是脱离实际的反方观点？比如说：我们不能用这个数据库系统，万一哪天这个数据厂商倒闭了咋办？

        建设性的意见很受欢迎。

       能容纳自己并不接受的观点，说明你自己很有学识。

       我们常常是要找一个优点多缺点少的方案，并不是找一个没有缺点的方案。这个观点很重要，并且要达成这个目的，在决策的时候，通常有下面几个要注意的地方：

1、设定决策时间限制。找到在这段时间内最好的方案

2、设立仲裁人

3、支持已经做出的决定

最后要说的是，面对问题的勇气。这个我觉得最关键的表率作用。比如说，我的上个项目代码可读性差，参数复杂。每次提及要重构代码，大家都含糊应对。后来我花了两天时间把后台代码整个重构一遍，效果好不好先不说，至少我已经开始干了。

最后感慨一下，设计充满妥协（生活也是如此），成功属于意识到这一点的人。