经管08006_XP的理念:非传统战略——克服来自经理和开发人员的抵触

XP让人感觉很不舒服,人们会抵制它。这种抵制来自恐惧和骄傲。通过将使用XP作为一种战略,可以客服这些情绪,增加获胜的机会。

1968年奥林匹克运动会,Fosbury带着他的“Fosbury跳”一路过关斩将,获得金牌并创下了新的奥运会记录。“Fosbury跳”不同于以往面对横杆劈腿跳的方式,而采用后背过杆并且肩膀先着地。坦白说,这看上去很蠢!但是,人们很难用传统方式击败使用非传统方式的获胜者。

XP就是一种非传统战略!使用它,可以开发出按时交付并具有很高商业价值的伟大软件,而且不需要开发人员加班加点的工作!使用XP,会增加获胜的机会!

最后,不要只为XP而关注XP,不要成功一个狂热的XP追星族,反而忽略了产品方面的问题!

XP只是手段,而不是目标!

克服来自经理的抵触
——经理们会反对使用XP,因为他们在方法选择上有着错误的假设。将问题的焦点放在降低软件开发费用上,他们就不再反对了。
1、了解经理的目标,帮助经理成功
2、开发成本——研发和修改的金钱、时间;留住高级开发人员;普通开发人员的贡献。
3、可能的反对意见:
   
XP不成熟——不试过又怎么知道呢?实践是检验真理的唯一标准!现在的状态就没有风险么?就是最好的么?穷则变!
    XP过分简单——kiss,简单就是美;XP简单,但是不过分;大部分文档不必要。
    结对编程成本太高——一个臭皮匠,弄死三个诸葛亮:-)
   
全职现场客户难以应付——防止开发人员等待客户或者猜测需求;典型的需求文档只有15%是完整的,7%是正确的。
   
XP太不正式——不要试图用有趣的PowerPoint幻灯片和PDF文档来掩盖问题。提供足够的文档,但绝不要提供不必要的文档:计划游戏、系统隐喻、需求故事、测试用例(关注结果)。

   
“XP的局限”——不要将XP当做百宝箱,什么都从里面拿,要知道他是一个整体,单一的实践可能立即产生正面的影响,从而让人们接受随后采用的其他实践,但是有可能造成不良后果。如:开发人员仅偶尔结对编程、不再编写文档,这样会缺少有价值的反馈。

   
克服来自开发人员的抵触
——开发人员会反对使用XP,因为他们可能看不到XP的优势。将问题的焦点放在XP的支持环境上,他们就不再反对了。
1、开发人员,喜欢跟机器交流,不喜欢跟人沟通。
2、开发人员希望:
    开发软件,而不是编写文档或整日开会;
    为自己开发的软件产品而自豪;
    工作中得到乐趣;
    一旦软件发行,再也不用去维护该产品。喜欢新的挑战,而不是给老代码补补丁。
3、可能的反对意见:
   
XP过分简单——真正含义是:“我学过其他软件方法,我的工作也因此取得了成绩,我不想再倒退。除此之外,在编程上我已经不像以前那么出色了,因为我还要花很多时间做一些‘更高级别的事情’。”

   
我不喜欢结对编程——开发人员不习惯成群的狩猎;而且认为没有个人代码的拥有权,就很难成为编程英雄。强调知识共享、改进代码质量及增强士气。(开发人员不喜欢代码被审查,也不喜欢审查别人的代码,尽管审查已经被证实在保证软件质量方面起着巨人的作用。几项研究同时表明,代码审查是对代码质量的最大贡献,甚至超过了测试!)结对编程比同行评审有过之而无不及!

   
XP稀奇古怪——编写代码前先编写测试用例并运行测试用例–代码变简单,因为仅需要通过测试即可,也不再担心别人修改自己的代码,测试用例也被当做很好的文档;允许不断改进设计以符合变化的需求–渐进的递增的设计,需求中的变化不是大量修改的借口;结对编程,经常要共享单个键盘和鼠标。

   
XP没有提供足够的信息——开发人员不喜欢创建文档,甚至一个都不想创建,但是他们喜欢有足够的信息指导工作。经常有没有足够的设计文档,过分依赖需求故事代替规格说明书,XP导致失败!把代码当做最好的文档!XP不是建议不编写文档,而是说不应该花时间去创建不毕业的文档。

   
——必要的文档:面向维护——wiki风格的常见问题数据库(10个类一页);技术备忘录(20个类一页);清晰一致的验收测试规则;测试用例和代码

    ——每天一个短会;测试用例针对逻辑而不是UI;需求和估算写在卡片上。

欢迎关注我的微信公众号:

 

如无特殊说明,文章均为本站原创,转载请注明出处!

发表评论

邮箱地址不会被公开。 必填项已用*标注