一次和朋友谈起敏捷,朋友说了一句“一切开发方法都是耍流氓,软件做的好不好全看人怎么样”。好吧,我50%的同意这个观点。“只要人足够优秀,流程就是个屁。"纵观人类历史上那些牛叉叉的软件,基本都是最初几个大牛凭借自己的天才才华捣鼓出来的。比如Unix啥的。我相信这些大牛们开发软件时候时候,肯定没有仔细考虑过该采用什么软件开发流程,典型的code and fix。问题在于我们很难保证软件开发队伍里的人都足够优秀。现状是优秀的人都是一小部分。所以我们需要一个好的开发方法帮助团队能够完成软件项目。
我认为一个有战斗力的开发团队,应该具有三个支柱:
1. 人
2. 管理制度
3. 开发方法,这是敏捷能干的事
1、人
不管问题看起来是什么样子,最后一定是人的问题。当然一般情况下,你和老板反映开发中的问题时,如果过度强调这是人的问题,那一般不会有什么好的果子。而且,如果你自己不是老板,一般情况下人的问题你也解决不了。只能是把意见向上反馈。如何找到合适的人,这��️是另外一个话题。真正遇到人的问题,Scrum Master其实是没有太好的办法。我的经验是赶快请这个同学离开团队。
2、管理制度
这个问题也很操蛋,涉及到公司层面的制度设计,小p职员只能在下面吐吐槽而已。比如外包的问题,公司为了省点钱或人力啥的,雇了一些外包的程序员来参与软件的开发。一般来说,外包开发人员是非常苦逼的,核心的工作公司也不会让外包人员做。干的再累也看不到啥前途。那公司就应该对外包人员有个合理的心理预期,不要期望外包人员天天雄赳赳,气昂昂热情高涨的为你工作。如果有幸聘到了一些有责任心,劳模式的外包人员,那就是公司赚了。赶紧想办法挖过来吧。期望外包团队成为一个自我管理的团队,这个问题实在不是敏捷开发能解决的。又回到了第一个问题。
现在很多公司采用矩阵式的管理方式,管资源的和管项目的人分开。强矩阵方式开发人员都对项目负责,项目的成败直接关系的开发人员的前途。弱矩阵方式就是项目开发人员都只对自己的直属经理负责,项目经理的评价占的比例太低,这种情况就麻烦了,指望敏捷来解决这个问题,实在是强敏捷所难。
我之前的公司就是典型的弱矩阵方式。由于项目比较多,一个开发人员往往要参与几个项目。部门领导直接抓一个重点项目,完蛋了,开发人员在做这个重点项目的时候,热情高涨。对于其它项目,就热情一般般了,经常发生项目经理要求开发人员干活,开发人员却不愿意的情况。这个问题,敏捷也没有办法解决。
3、开发方法
敏捷啥都不能干,我们要敏捷干嘛。好吧,我们谈点敏捷能干的事吧。凡是遵守敏捷价值观的开发方法都可以标榜为敏捷开发方法。既包括技术层面的实践,也包括管理层面的实践。在实际的推广中,往往更重视管理层面的敏捷实践。我想这主要有两个原因:一、管理层面的变化,大家马上就能看的见,立刻就能告诉别人,你看,我们敏捷了;二、老板们没办法度量技术层面的实践。也就是说你做或者没做,老板们没办法直接知道。
在三个支柱中,如果前两个不能动,那我们只能从第三个上面想办法了。
说起流程,广大开发人员都是一般辛酸泪啊。这简直就是套在程序员脑袋上的一把枷锁。本来写个代码就完了,现在还有评审,还要让测试帮助验证,每天还有个站立会议。。。。。。。对此,我只能说
合理的开发流程能够在的一定程度上保证软件开发的成功率,提高开发效率。注意是合理,不是繁冗。什么叫合理?就是开发人员愿意执行的流程。如果开发人员都在抱怨,就要想一想是不是流程有问题了。
熊孩子:”我什么流程都不想要,我想怎么开发就这么开发“
哥: "别闹了,快回家吃饭去"
敏捷说:
个体与交互重于过程和工具
但是敏捷可没说不要流程。
我见过多次流程制定出来,一段时间后就流于形式的案例。我建议广大制定流程的老板们,最后一段时间后检查一下流程的执行情况,是否达到了预期的效果,是否真的在执行。如果和预期的不一样,又没有新的代替方案,那么最好的方案就是直接取消。
熊老板:”取消,扯淡! 那不是说我之前决策是错的。不行,不但不能取消,我还要加强监督,必须执行!“
那怎么判断这个流程是否有效?先严格执行,看看效果,如果过段时间大家还都在抱怨,那么这个流程就应该取消了。Scrum 里面有个回顾会议,就是用来干这些事的,反省一下最近有啥可以改进的。其实还有个简单的方法可以判断这个流程是否合理,就是在会议室宣布新流程时,观察一下广大程序猿们的反应,如果大家都对你笑而不语,或者低头窃窃私语,管理者就应该有点谱,这个流程推行可能会有点麻烦。