管技理术

公司里又有人抱怨产品经常随意的增加需求，说纯敏捷开发已经不适合现在的大团队了。我觉得诧异、惊奇、不敢相信。现在所有的大公司都在推行敏捷开发，怎么敏捷开发就不适合我们公司，团队大了，就不适合了呢。

不想去说敏捷适合还是不适合，我自己相信是一定适合的。但是问题出在哪里呢？人！出在人的身上。不管是瀑布模式，迭代模式，任何的模式，都是由人来执行的。混乱，加班，Bug，这些的问题一定出在人的身上。所以，不管用哪种模式，首先要解决的是人的问题。

所有的IT项目中，有两个名词，是大家都离不开的。管理和技术。通常人都会分开的来看这个两个词，要求管理的人，只是做好协调，计划，服务等一些辅助的工作。而技术呢，则要求人很牛逼，架构师，资深，各种语言，各种工具，各种算法。都需要精通。现在招人，你的job描述里，没有精通二字，你都不意思跟人打招呼。但是，中国人是最擅长考试的，各种牛逼的名词，牛逼的算法，全都可以记在脑袋里。然后，通过了面试，万事大吉。这些都是好的吗？如果有了牛逼的技术，为什么项目还是乱，还是加班，bug还是多呢？ 不管是管理，还是技术，都只是解决了部分的问题。曾经在Moto见过了优秀的管理者，能够很迅速，有效的安排项目计划。但是，对着一个烂透了根的产品，不停的打补丁，能避免最后崩溃的结局吗？不能。

好了，我不想说管理和技术，我想说管技和理术。 管理，有管有理，技术，有技有术。分离了管理和技术，也就只有加班的份了。技术做好了架构以后，便不管实现。管理做好了计划以后，便只盯结果。这些都会导致出现问题，加班。不管是哪种开发模式，如果没有频繁的，有效的沟通，最后总会出问题。有效的沟通，并不一定是面对面的语言，也可以使有效的文档（日式外包，便是有效的文档，文档细致到方法，变量。所以产出的东西，能够让他们满意）。

管的人，要懂得技，能够理解这个技，能够带来什么。理，要理清节奏，理清顺序，排好优先级。术，要搭好架子，提出好的方案。最后，还是要管。敏捷开发，看起来，似乎没有了管理人员。实际是scrummaster 代理了这个角色。由master来管理这个小的团队。

至于流程，学习敏捷吧，敏捷的流程，本身就能够解决问题，李小龙说：“我不害怕一次练习1000个踢打动作的人，但我害怕将一个踢打动作练习1000次的人。”在敏捷开发中，效率也可以通过反复实践来得到提升。 重复，进而改进，会得到好的结果。