梅延涛

梅延涛的博客

他的个人主页  他的博客

对敏捷开发的一些思考

梅延涛  2010年03月02日 星期二 14:20 | 2110次浏览 | 21条评论

近来在工作中所遇到不少非技术因素的问题,这些问题使得我不得不重新思考自己的工作方法,就将一些零碎的想法和疑惑整理到这篇Blog中。其中遇到的问题,还望高人指点;错误之处,请多多指教

    关于敏捷开发,好像很多时候我们提到的都是一些上层软件的开发,因为开发效率和运行效率在很多时候总是相互矛盾的。我现在主要做嵌入式开发的,效率自然尤为重要,因此经常会有牺牲灵活性而提升运行效率的做法。
    但做过几个产品后,我越来越意识到客户——尤其是市场部那些哥们儿的变化远远大于计划,更恼火的是,经常变来变去又会变回来。在开发方法上,我们现在所沿用的,基本上还是注重预见性的瀑布模型,这很显然不适应当今多变的大形势。
    以前,除了对那些不负责任,唯务厚黑的团队成员表示愤恨之外,我不得不不断思考自己的构架,希望从构架层面提供一些灵活的处理来应对这些问题。虽然这最终解决了很多问题,但还是不能满足实际多变的需求,更不能从根本上解决为应付那些求全责备的文档和难缠的客户需求所造成的工作效率不高的问题。
    此外,顺便在此说一点我对现有的一些提升开发工作效率的管理方法的看法:很多时候管理者提高工作效率的手段都过于粗暴:就是一味PUSH!让你永远不能完成你的工作量,同时,再加一些降低人员风险的手段,比如把技术文档化,让团队人员交叉工作,这样万一这个哥们儿抗不住压力离职,另外一个又能接受。这种管理方式貌似现在很凑效,而且我发现也是绝大多数公司的管理手段,此外,我觉得这也是将我等软件爱好者沦为IT民工的主要原因之一。 但是,这种方法虽然降低了人力成本和风险,也有其缺陷,那就是很难创作出优秀的软件,也无法应对复杂多变的需求(因为一切都要进可能预先定义好,而且尽量避免新的东西引入或者改变)。更要命的是,长此以往,团队中成员见会缺乏信任,相互推卸责任和工作,并可能在管理层之间形成较为严重的办公室政治。

    我之前对于“敏捷开发”的理解,其实就限于开发速度上,例如Python那样的开发语言,除了自身语法适合提升开发速度,还有大量现成的可用库和模块,所以一度误以为敏捷开发就是“速度开发”。
    这样就但真的看了相关介绍才发现,这不仅仅是个开发方法,更是一种和企业文化息息相关的管理方式。例如wiki上所提到的价值观,原则等问题,我很赞同这些观点,当我不知道如何能够使之实施。对此,我提几个具体的问题,希望大家能指教:

    1.“客户协作重于合同谈判”,如何能达到这一目标?客户往往和生产者是相互博弈者又相互依赖的矛盾体,而且在生产的过程中,博弈的成分占主导地位,甚至还有不少善于抵赖的客户。在这种情况下让客户协作重于合同谈判,领导者能接受么? 此外,即便领导能够接受,能够允许开发者与客户协作,开发者有没有什么技巧能够和客户真正达成一种合作的态度? 因为我所见到或者听到的那些个客户,往往都比较那个……

    2.“随时应对变化”是否意味着“随时准备重构”? 应对变化的心态首先要良好,其实许多工程师自己对于那些可能导致软件变化的外来因素往往是持有抵制情绪的,我自己就是这样。原因很简单,改变就要有新的工作量,而且很可能会推翻以往的一些设计。重构往往会引发新的较大的工作量,更会引入新的风险,所以往往会尽量避免。

    3.如何分配工作和进行相应的绩效考评?虽然我不是管理者,也没有权限做这些事情,当对软件开发工作的绩效管理一直是我觉得比较困难的问题。据我所知,在一些大的公司里,尤其是对一些核心的开发团队,是没有绩效考评的,工作时间也很弹性,这绝对符合团队之间相互信任的主张。但小公司呢?


    刚开始学习这一问题,就先写这么多了,问题是在实践中产生的, “随时应对变化,响应变化" :)

评论

我的评论:

发表评论

请 登录 后发表评论。还没有在Zeuux哲思注册吗?现在 注册 !
刘洋

回复 刘洋  2010年03月21日 星期日 10:23

我的感觉,客户喜欢变的根本原因是他们自己没有真正搞清楚需求,或者我我们和客户对需求的理解不一致造成的。在这个层面上,沟通和需求文档化可能比设计更为重要

2条回复

  • king

    回复 king  2010年04月27日 星期二 11:08

    同意,大部分人其实都不知道自己到底需要什么。而且作为一个有多层决策链的客户来讲,需求变化是很正常的,这时就需要专业的解决方案专家来进行需求引导。

    0条回复

  • 梅延涛

    回复 梅延涛  2010年03月21日 星期日 11:23

    所谓的需求文档在我看来只是为了压低成本而老板降低人员流动风险的手段,在一个没有人员相对稳定的团队中几乎是没有什么用处的。 根本原因其实就是客户根本不知道自己想要什么,他们只是希望你做一个东西出来,给他们玩儿一下,然后觉得爽就成。
    所以我觉得,仅对于工程师而言,提高自身构架能力才是王道。等有了老板的信任,公司在客户中说话有了分量后,在挺直了腰板告诉那些自命不凡有不舍得花钱的客户:“改变就得付钱!”

    0条回复

郎咸武

回复 郎咸武  2010年03月11日 星期四 23:55

"再加一些降低人员风险的手段,比如把技术文档化,让团队人员交叉工作,这样万一这个哥们儿抗不住压力离职,另外一个又能接受。这种管理方式貌似现在很凑效,而且我发现也是绝大多数公司的管理手段,"
我发现我们公司也是采用以上管理方式。
前个人看:这样做导致一个人,一个风格。再加上没有统一规范,做出的软件更难看。

0条回复

徐继哲

回复 徐继哲  2010年03月03日 星期三 18:27

采用什么样的研发管理方法论,和公司文化以及所处的商业环境有密切关系,无论是CMMI还是敏捷,多吸收思想、灵活运用,照搬就不好了。

0条回复

lili

回复 lili  2010年03月03日 星期三 10:44

敏捷开发的管理有一个很重要的前提,就是开发团队整体的管理水平,技术水平要高,成员有较好的职业道德,自律性强。如果没有这些,光靠过程是不能保证开发质量和效率的。

1.“客户协作重于合同谈判”
要想和客户搞好关系,需要的是沟通技巧和能力,和技术应该没有太大关系。对待客户不能从技术层面的角度出发,要从整体的更高层次的了解客户需求,了解项目对于客户的重要程度和对客户担当者有什么影响,总之了解的越全面对对付客户越有帮助。换位思考很重要。搞技术的人很难跳出技术0,1的思维模式,自然很难和客户搞好关系。所以我认为一个项目组除了需要有一个技术牛人之外,还需要一个在技术人员和客户之间搭桥的人员,他不需要有很高的技术水平,但一定要有沟通的技巧和能力。
2.“随时应对变化”是否意味着“随时准备重构”?
好的设计即使有一定的变化,也不需要打动干戈来进行重新设计。一般来说,如果客户有些变动系统就需要重构那可能有2个原因:
1是你没有更好的把握客户和业务需求,2是你的架构太弱,没有可扩展性和可维护性。
3.如何分配工作和进行相应的绩效考评?
这是一个没有定律的比较难做的事情。因人而异。所以如果能做到在项目中能做到在公司总的考核原则下因人而分配工作,因人而考核是最理想的。

8条回复

  • 徐继哲

    回复 徐继哲  2010年03月03日 星期三 18:24

    系统讲讲日本的软件公司是如何搞的?还是CMMI多一些吧。

    7条回复

      • lili

        回复 lili  2010年03月04日 星期四 11:42

        估计会让大家失望。管理水平并不高。但日本人的认证细致在很大程度上填补了一些。所以和他们交流很累。但这也锻炼了个人的沟通能力。

        6条回复

          • 梅延涛

            回复 梅延涛  2010年03月04日 星期四 15:03

            To lili: 日本计算机技术很差吗?可是我看他们的机器人都做得很好。我能不能理解为他们的工程做的很差,但是计算机科学做得很强呢? 还是他们更注重法律,经济的专业领域,在计算机或者科技领域确实做得没有我们想象中的那么好?
            Thanks:)

            3条回复

              • lili

                回复 lili  2010年03月05日 星期五 11:56

                在这里再贴一些权威机构调查的数字:

                本软件开发成功率:2003年、26.7%; 2008年、31.1 %
                日本IT系毕业生 2005年7500人

                0条回复

              • 梅延涛

                回复 梅延涛  2010年03月05日 星期五 11:55

                To Lili: 您说的很有道理,我们在整个教育的过程中浪费了学生太多的时间,扼杀的太多的兴趣。 我前次参加深圳Linux用户组的活动,遇到深圳这边一个初中的物理老师,他就带自己的学生再兴趣小组中做了很多兴趣方面的研究,如示波器-单片机开发等。 学生们用Linux下各种工具实现和解决了不少问题,遇到问题来参加活动,而且得到ZhangLe大哥等Linux牛人的不少帮助。 我觉得这其实就是一个很好的方式,可惜学生们的负担还是太重了…

                0条回复

              • lili

                回复 lili  2010年03月05日 星期五 11:49

                据我在日本软件大公司工作的经历,我认为日本的计算机水平确实没有我们想的那么好。在这里做软件开发的中国人,韩国人,印度人,菲律宾人很多。他们现在软件的应用之所以能发展到这个程度,我认为不是他们自己的技术水平有多好,而是他们有远见而且有钱,他们可以投入时间投入金钱利用世界上先进的人才来为他们服务。

                们的机器人做的好是因为他们做事情的专注和对个人兴趣的开发。日本中学每年都有机器人比赛。初中高中生就开始研究并自己制作简单的机器人,然后参加比赛,真是做到了从娃娃抓起。如果中国的学校也能把作业补课去掉,让学生做自己喜欢的事情,搞些类似的活动比赛来提高学生动手思考的能力,我想用不了一代人就能赶上日本。

                0条回复

          • 徐继哲

            回复 徐继哲  2010年03月04日 星期四 11:48

            所谓的不高可能是没有期望中的那么高吧,但话说回来,日本毕竟是科技强国,可以学习、借鉴的地方不少吧。

            1条回复

              • lili

                回复 lili  2010年03月04日 星期四 14:55

                至少计算机技术上没什么可学的。要说可以学的话也就是态度上。比如客户至上,不忽略细节。计算机技术没有中国强。看看他们大型机的研究就知道了。
                日本什么人都可以搞软件开发,学法律的,文学的,英语的,化学的。。。。。。都是些贴不上边的专业,最基本的理论知识也没有,可想而知能是什么水平了
                当然每年也有一些计算机专业毕业的学生,但在整个行业需求里被分散后比例就很少了。这样一来整体水平差得很。

                0条回复

陈莉君

回复 陈莉君  2010年03月03日 星期三 10:43

思考着,或许就进步着

最近在看一本书,“0bug,C/C++商用工程之道”,这本书大家很有争议,不是从学术而是从思考和实战的角度写,尽管缺乏严谨,但对在工程一线的你们可能有所帮助。

1条回复

孔志奎

回复 孔志奎  2010年03月03日 星期三 10:29

“随时应对变化”是否意味着“随时准备重构”?
首先, 软件的架构必须是可扩展的, 本身具备应对变化的可能
其次, 软件架构的可扩展能力必须是在预见范围内的, 否则一味的强调可扩展能力, 就会牺牲许多其它方面的东西, 比如 性能, 复杂度
再者, 考虑小范围的重构, 随时重构. 重构应该成为一种习惯. 不要等到实在没有办法了再做全盘的重构; 这绝对不是一个好主意. 因为通常来说, 市场不会留给你足够的时间去做这样的事情. 而且人的惰性(不光是重构的实施者, 还有其涉及的其它人员, 比如测试)往往会使这样庞大的计划最后泡汤.

2条回复

  • 徐继哲

    回复 徐继哲  2010年03月03日 星期三 18:25

    同意,主动反思、重够很重要,任何事情一旦“被动”那么就容易产生不好的心态,心态不好了,看什么都不爽。

    1条回复

张晓龙

回复 张晓龙  2010年03月02日 星期二 21:48

1.“客户协作重于合同谈判”

-----如果是中国的客户,很难。中国的客户技术水平低,而且特别强势,很难合作

2.“随时应对变化”是否意味着“随时准备重构”?应对变化的心态首先要良好,其实许多工程师自己对于那些可能导致软件变化的外来因素往往是持有抵制情绪的,我自己就是这样。原因很简单,改变就要有新的工作量,而且很可能会推翻以往的一些设计。重构往往会引发新的较大的工作量,更会引入新的风险,所以往往会尽量避免。

-------非常同意。 根据我的了解,大公司最质疑“频繁重构”这个观点。必要的重构是可以的,但是我们所知道的大的系统成熟起来都要若干年。即使重构也是几年才能进行一次

3.如何分配工作和进行相应的绩效考评?虽然我不是管理者,也没有权限做这些事情,当对软件开发工作的绩效管理一直是我觉得比较困难的问题。据我所知,在一些大的公司里,尤其是对一些核心的开发团队,是没有绩效考评的,工作时间也很弹性,这绝对符合团队之间相互信任的主张。但小公司呢?

-----没有绩效考核。敏捷强调自管理,如果还需要考核,那就不是自管理。这么说有点虚,但是在实际情况中的确很难考核。
奉劝大家不要想办法去通过考核约束研发人员,效果很差。还是考虑怎么调动他们的积极性。

1条回复

  • 梅延涛

    回复 梅延涛  2010年03月03日 星期三 09:22

    >>-----如果是中国的客户,很难。中国的客户技术水平低,而且特别强势,很难合作。
    我也是这么认为的,而且很多中国客户开的是技术公司,其实是做贸易的,他们只想做渠道,所以这种方式几乎是不可能的。

    >>奉劝大家不要想办法去通过考核约束研发人员,效果很差。还是考虑怎么调动他们的积极性。
    就我个人的心态而言,在小公司中最能调动我积极性的就两个:一个是团队中又德才兼备的技术牛人;另一个就是让我获得更多的收入。而小公司通常没有牛人,又喜欢压缩成本,通常两者都不具备,呵呵。

    0条回复

暂时没有评论

Zeuux © 2024

京ICP备05028076号