梅延涛 2010年03月02日 星期二 14:20 | 2212次浏览 | 21条评论
近来在工作
关于敏捷开发,好像很多时候我们提到的都是一些上层软件的开发,因为开发效率和运行效率在很多时候总是相互矛盾的。我现在主要做嵌入式开发的,效率自然尤为重要,因此经常会有牺牲灵活性而提升运行效率的做法。
但做过几个产品后,我越来越意识到客户——尤其是市场部那些哥们儿的变化远远大于计划,更恼火的是,经常变来变去又会变回来。在开发方法上,我们现在所沿用的,基本上还是注重预见性的瀑布模型,这很显然不适应当今多变的大形势。
以前,除了对那些不负责任,唯务厚黑的团队成员表示愤恨之外,我不得不不断思考自己的构架,希望从构架层面提供一些灵活的处理来应对这些问题。虽然这最终解决了很多问题,但还是不能满足实际多变的需求,更不能从根本上解决为应付那些求全责备的文档和难缠的客户需求所造成的工作效率不高的问题。
此外,顺便在此说一点我对现有的一些提升开发工作效率的管理方法的看法:很多时候管理者提高工作效率的手段都过于粗暴:就是一味PUSH!让你永远不能完成你的工作量,同时,再加一些降低人员风险的手段,比如把技术文档化,让团队人员交叉工作,这样万一这个哥们儿抗不住压力离职,另外一个又能接受。这种管理方式貌似现在很凑效,而且我发现也是绝大多数公司的管理手段,此外,我觉得这也是将我等软件爱好者沦为IT民工的主要原因之一。 但是,这种方法虽然降低了人力成本和风险,也有其缺陷,那就是很难创作出优秀的软件,也无法应对复杂多变的需求(因为一切都要进可能预先定义好,而且尽量避免新的东西引入或者改变)。更要命的是,长此以往,团队中成员见会缺乏信任,相互推卸责任和工作,并可能在管理层之间形成较为严重的办公室政治。
我之前对于“敏捷开发”的理解,其实就限于开发速度上,例如Python那样的开发语言,除了自身语法适合提升开发速度,还有大量现成的可用库和模块,所以一度误以为敏捷开发就是“速度开发”。
这样就但真的看了相关介绍才发现,这不仅仅是个开发方法,更是一种和企业文化息息相关的管理方式。例如wiki上所提到的价值观,原则等问题,我很赞同这些观点,当我不知道如何能够使之实施。对此,我提几个具体的问题,希望大家能指教:
1.“客户协作重于合同谈判”,如何能达到这一目标?客户往往和生产者是相互博弈者又相互依赖的矛盾体,而且在生产的过程中,博弈的成分占主导地位,甚至还有不少善于抵赖的客户。在这种情况下让客户协作重于合同谈判,领导者能接受么? 此外,即便领导能够接受,能够允许开发者与客户协作,开发者有没有什么技巧能够和客户真正达成一种合作的态度? 因为我所见到或者听到的那些个客户,往往都比较那个……
2.“随时应对变化”是否意味着“随时准备重构”? 应对变化的心态首先要良好,其实许多工程师自己对于那些可能导致软件变化的外来因素往往是持有抵制情绪的,我自己就是这样。原因很简单,改变就要有新的工作量,而且很可能会推翻以往的一些设计。重构往往会引发新的较大的工作量,更会引入新的风险,所以往往会尽量避免。
3.如何分配工作和进行相应的绩效考评?虽然我不是管理者,也没有权限做这些事情,当对软件开发工作的绩效管理一直是我觉得比较困难的问题。据我所知,在一些大的公司里,尤其是对一些核心的开发团队,是没有绩效考评的,工作时间也很弹性,这绝对符合团队之间相互信任的主张。但小公司呢?
刚开始学习这一问题,就先写这么多了,问题是在实践中产生的,
“随时应对变化,响应变化"
:)
Zeuux © 2024
京ICP备05028076号
回复 刘洋 2010年03月21日 星期日 10:23
回复 king 2010年04月27日 星期二 11:08
回复 梅延涛 2010年03月21日 星期日 11:23
所以我觉得