【转】程序员的生产力始为需求而休工具

Marco Behler是同一位著名开发者和市场营销人员,同时为是Marco Behler
GmbH的老祖宗。近日,Behler就程序员生产力这同话题进行论述,在社区有了于生之震慑。

乃真的掌握影响程序员生产力的关键因素是什么吗?是VIM、Emacs、最新的Haskell
Web框架,还是爱的NoSQL数据库也?遗憾的凡,如果您将关注点放在工具、框架或流程上,那便认证您还是没真的理解是题材。我看,影响程序员生产力的关键因素在于起点:恰当的需求。

作为开发者缘何要关注需求,这难道说不是业务人员的作业?

理所当然了,创始人/产品经营/团队主任总得使关注是问题:到底出什么才能够让客户最终埋单啊?但若起开发者的见对这个问题会是安的也?有时见面冒出这么的状,有人打于几,大叫:现在就是从头支付XYZ,马上,立刻,如果中间出现问题,我们可以当付出过程遭到解决,这就称为先发优势?其实,我们称为:尽快开始,但永远不会见了。很有或你所支付的一半之上之物都是匪清的。

而怎么亮自己形成了?

预期中的,如果非克一心知晓需要,那就会造成遗漏,当问于什么时候能出了,你也许会见遗忘这,忘记坏。那么该怎么测试不清的需求也?这跟君喜爱的BDD工具没有其余关系。如果输入不清晰,那么测试为无见面清楚,输出就重新非清了。

公连自己激励,对为?

而再糟糕的凡,频繁之匪清楚的急需是只信号,表示业务人员不确定客户究竟想只要啊。遗憾之是,这也表示若所付出之重重行事还是纸上谈兵无效的。如果这种气象屡屡出现,就会指向程序员的生产力造成非常要命的毁损,这将重影响程序员的效率。

究竟什么才是适宜的求?

那什么才是合适的急需呢?我以为相当的需要的制订过程应是下边这法的:

  • 急需业务人员与程序员共同讨论,并且通过双方充分的沟通
  • 内需持续拆解、拆解、再拆除
  • 不断打磨,经得起推敲

本人是独程序员,需求的从与我无关?

真,在大型集体中或许会见产生特别的工作分析师,他们的重点工作便是于用详细的求规范传递让落实集体之前对其展开连发的周到。在美好状态下,这么做是宏观无缺的,你唯有待以在那时编写代码就执行,不过事实上情况倒是并非如此。

无论怎样,组织的圈更小,程序员需要处理的事体就越是多。公司的创始人可能会见撞击在几大喊:作为程序员的你不光要当贯彻,还要关注需求的发出过程。

无论怎样,你还应该成为平等曰学者

对于你吧,可能看AngularJS
2.0底提升路线而比较同客户讨论世界问题和要求再度好玩。不过,我思念说的凡,你的艺、对框架或算法的知道只是你每日工作的一致片段。对于有开支工作以来,基础则是“恰当的需要”。

Behler的篇章刊载后高速即挑起了诸多开发者的共鸣,很多丁耶混乱发表了协调之眼光,下面摘录出部分独立上报以飨读者:

Sasi Pallekonda说到:

说得极其硬了!开发者不仅使考虑该行使什么数据结构,还欲考虑需要是什么样配合最终用户的,并且如何实现需求,读了Behler的文章获益匪浅。

Erik Gollot说到:

特别同意文中的看法,我今天针对如何编写好的需异常感谢兴趣,因为根据自己的经验,用户故事是遥远不够的。

Wes Higbee说到:

可怜同意Behler的意,对这个我哉开了深切的构思,我道:方向要比速度更为重要,只有确定了可行性,速度才是起含义的,否则再快之速度吗是干无效的。

Jussi Laasonen说到:

不少早晚,人们还认为快速软件开发只不过是“立刻起构建XYZ”,但事实上,这么做是完全错误的。

Fayez Naccache说到:

本人曾于咱们称为精益创业的团组织中劳作6独多月份了。在就中间,我们没有计划、没有详细需求、没有您所说之相当的需要。我以为工作起来十分拮据,一点动力还未曾。我充分欢喜文中的立句话:尽快上马,但千古不会见收;还有无什么样,组织的层面更为聊,程序员需要处理的工作就是越是多。这对准自家本之做事吧真是又合适不过的讲述了。

Eliseu Monar说到:

Eric
EvansNoSQL已介绍过同样栽“普适语言”,可以解除团队成员里沟通的障碍,我杀好这本书。Martin
Fowler对之也发过介绍:

普适语言是Eric Evans在Domain Driven
Design一修被所运用的术语,用于描述如何当开发者和用户中构建出一致栽通用且严格的言语。该语言应该依据软件开发中的世界模型,因此她当是格外纯粹的,因为软件是无力回天处理模糊问题之。

Evans代表在同领域专家沟通时利用普适语言是不行关键之,这有助于测试与领域模型的实现。此外,普适语言(以及模型)还当就团队成员对世界理解的连增高而连演化。

普适语言的发起人Eric Evans对之则以为:

透过广泛使用基于模型的言语,我们可构建起一个完好无缺且可掌握的范,该型由有简单元素结合,这些简单元素最终能发挥出复杂的定义。领域专家应该本着那些笨拙且无法转达领域含义的术语或者结构持反对意见,开发者应该警觉那些影响设计之混淆的处和不一致性。

Behler关于程序员生产力的文章引起了众多口之共鸣,同时他为特别编写了千篇一律随名也Customer
Requirements的书。该书主要介绍了要求联系的技巧、如何适度地进行估价、如何防止模糊不根本的急需产生、如何和同事和客户联系需要、恰当合理之需求于开发与测试会发出怎样积极影响,同时各级一样段还提供了实际上的例子供大家参考。

程序员生产力这同样话题是每一个开发人员都津津乐道的,那么对于你的话,影响生产力的因素还产生怎么样吗,不妨分享下我们共同讨论。

【企业商业智能应用(BI)问卷调查,高概率赢取iPad
Mini】由InfoQ和多贱国内外大学与的商号BI调查启动,只待10分钟即可形成问卷,国内就需要50客,抽取2大iPad
Mini,中奖率还是要命高滴!
点击这里初步调查。

 

http://www.infoq.com/cn/news/2015/07/programmer-productivity?utm\_source=infoq&utm\_medium=popular\_widget&utm\_campaign=popular\_content\_list&utm\_content=homepage\#theCommentsSection

网站地图xml地图