再说敏捷，兼对“对敏捷开发等时髦概念泼点冷水”的回复

再说敏捷，兼对“对敏捷开发等时髦概念泼点冷水”的回复

敏捷在国内的宣传中，给人的感觉是降低成本，实际上能做这些的咨询公司，人力的单价都很高，也会有一些商务的政策保护，如果把这钱给一些有经验的公司，我相信做的也不会差。

我一直认为敏捷能够提出，一定是要一个特定的行业背景的，这个背景我们现在根本不知道，到底当时市场发生了什么情况，要革谁的命，这个没人说。

今天看到一个革命者跳出来质疑，觉得很有意思，我主要是对他的一段话做了回复。这段话比较有代表性，下面的很多小孩也提出过很多类似的问题，这次就一并贴出来。

-----------------------------------------------------

敏捷已经不时髦了，质疑它没有什么不对的，不过还是建议你多做项目，多思考，方法论提出来的观点，到底是要解决什么问题的。如果你没有那种疼痛点，那么这些方法对你就没效。你没有这种病，并不意味着这药对其它的病没效。

“详细设计和编程阶段，我倒觉得确实需要敏捷一下。文档写了给谁看？东西做好了就行。不过，照scrum的观点，天天开例会，烦不烦呀？哪那么多成果和疑问呀？只有领导喜欢，天天看着燃尽图有变化，很有成就感。”从这段话里面，我觉得有几个问题需要你好好思考。

设计工作并不等于写文档，文档作为阶段成果物，是要提交给客户（合同里会有约定，客户也要依次做阶段评审和后期运维支持）和公司（公司做阶段评审和知识管理）的，但是设计会变化，这就要求文档跟设计开发同步，设计必须要做，文档也必须要同步，你跳不过去。所以会有各种工具，比如数据库你会用PD，代码你会用JAVADOC，还有一些自己开发的东西，比如你说的需求跟踪。项目越大，文档的要求越高，什么样的文档有用是另外一个课题，你可以多想想。敏捷方法里面没有提文档，但是我相信在实际的项目中，应该会有这些过程的，比如文档的编写和审核，没有这些项目肯定都走不下去，只是人家故意回避掉了而已。

“东西做好了就行”，这句话很有意思，经常听到这句话。我经常会问，你怎么来证明你做好了？你怎么证明你理解了业务的需求，并且对于你每天的工作任务的成果是有一个衡量正确与否的标准？我觉得测试驱动是敏捷方法里面最有价值的一块。不过测试驱动并不是测试代码先写，也不是单元测试。

同时，你说东西做好了，但是怎么让项目经理知道，并且让项目组都知道项目的进展？如果你是项目经理会怎样？汇报说代码开发的差不多了，还有2周就能做完。数字呢？没有数字没有图表，沟通汇报会非常吃力，如果客户和领导对项目的进展有质疑，那么会要求你做更多的解释，甚至抽人出去或者要求压缩进度。

日例会开着烦，那么想过为什么要开？还是沟通，另外也是要敲打一下你这样的人，呵呵。

现在很多的敏捷方法把一些以前忽略的东西做了补充，特别是个人的工作方法，能看到很多职业经理人培训的东西，比如GTD、会议管理、沟通、文案写作，比较不错，这些都是个人职业素质，直接影响到个人做事的效率，也对团队的效率造成直接影响，也影响个人的职业发展通道。我觉得这些比技术知识更重要，技术会淘汰，这些技能不会。