“你的代码到底什么时候能交给我?”---谈谈软件

   郑州软件公司今天来和大家谈谈郑州软件开发，郑州软件定制工作中常见的时间浪费现象---延迟（Delay）

        国内软件公司工作人员在软件开发周期的时间浪费中常见的现象一一延迟(Delay)，软件开发的拖延情况有下面几种。
      
      ·  等待某人有空：例如，等待数据库管理员(DBA)帮忙设定数据库；等待文档工 程师(technical writer)帮忙写使用手册；等待r队友J帮忙一起解决bug；等待
公司招募到新人。
      
       ·  等待资源：等待测试设备；等待购买的软硬件设备到货；等待从Amazon买的书寄来。
      
       ·  等待某项知识：例如，等待产品经理告诉开发者所有的需求细节；等待资深程序设计师告诉你bug要如何解决、程序要如何写；等待新人搞清楚项目状况。
       
       ·  等待核准：例如，等待老板核准项日进行；等待法务审核合约；等待客户画押 需求；等待批准需求变更。
       
       ·  等待功能或产品完成：例如，等待系统分析师生m完整的软件架构；等待系统设计师画出全部的UML设计图；等待程序全部完成以便测试；等待程序通过 测试。
  
        开发人员通常每1 5分钟就会做出一个重要的决定（一秒钟几十万上下？！），如果开发人员对于他正在做的工作具备足够的知识（例如，知道客户到底要他做什么），或是当他剞司题时L马上就可以获碍解答，那么，开发人员就可以快速做出（较高质量的）决定。但如果开发人员缺少足够的知识或没有人可以回答他的问题，那么，聪明的人类只会有下面三种反应。
       ·  停下手边的工作，试着寻找答案：原本的工作被中断，如果找答案的过程很冗长，将造成工作切换的浪费。
      
       ·  停下手边的工作，找其他事情来做：柿子挑软的吃，而原本的工作可能就会变成半成品(partially done work)。最惨的情况就是不断地找新的事情，却没有一件事真正完成过，直到“堆栈溢出”j(stack overflow)--注释1为止。
      
       ·  猜测可能的做法，硬着头皮继续做下去：蛮干。最后的成果可能不是客户所需要的，结果则需要重复劳动(rework)或再复学习(releaming)。这个现象常常发生在很多『有理想，有抱负，外加有创意j的开发人员身上。
   

        如果找答案的代价很高，或是程序很繁杂（例如，要联络客户、协调其他部门的人）那么，属于“宅男”、  “宅女”类型的开发人员则会冈为害羞与偷懒等原冈，而选择后 面两项做法。
        在情况允许下，如果瞎耗一段时问不做事又不会被发现，开发人员也可能会执行一个“空循环”不断地等待，期待答案自己出现。这些行为都是一种浪费。消除延迟的方法很多，例如rF面几种。
   
       ．  组织跨职能团队。团队成员包含完成项日所需的所有人才，除了可以减少交接(hand off)所造成的浪费，也能大大降低延迟的问题。冈为如果工作需要其他团 队或部门的配合，很有可能需要等待对方育空的时候才会理睬你。不幸的是，
对你而言非常紧急的事情，对其他团队或部门的人而言，通常是优先权很低的r额外工作。所以，要等待对方有空或是突然大发慈悲愿意帮忙，才会处理你的工作。
   
       ．  让团队成员坐在一起。如果【刻队成员在同一个办公事工作，有任何问题时，只要走几步路马上可以找到其他团队成员。如果团队成员分散在不同的办公室中，就必须靠打电话或是发电子邮件的方式来沟通。等待对方回电话或是回电
子邮件的时间都是拖延所造成的一种浪费。
   
       ·  采用比较短的开发周期（例如两周）并经常与客户互动。如果你的客户需要等待六个月才可以看到你所开发的软件，在这漫长的等待过程中，客户无法给予任 何建议，也冈此最后所开发出的来软件不是大好（完全满足客户的需求），就是
大坏（和客户想象中的样子差很多）。由历史的经验可得知，结果是人坏的几率要高很多（冈为经过漫长六个月的等待，客户心巾的需求早就已经不知道改过多少次了）。如果能够采用较短的开发周期，例如每两周把软件开发的成果跟
客户报告，并且听取客户的意见，如果有做错或是需要调整的地方，则在下次的开发周期中立刻修改。如此便可开发出符合客户需求的软件，而且减少客户因为漫长等待所形成的浪费。

      ．  指定专人排除障碍。就算乡民们的开发团队是属于一个跨职能团队，团队成员在开发软件时还是有可能遇到很多阻碍(impediment)，导致无法持续进行开发工作而必须等待问题的解决。例如，开发人员对于需求有疑问时却总是找不到
客户或是Product Owner可询问，冈此，只好暂停手边的开发工作。或是团队将软件送给品管部门进行测试，但却迟迟未被排入品管部门的测试行程之中，而耽搁后续的开发工作。如果团队采用Scrum方法，那么，团队中的ScrumMaster就必须负责尽早排除这些障碍，将等待的浪费降到最低。

     ·  改善开发与测试环境。如果开发人员的计算机很烂，很可能每次开启一个稍微大一点的开发项日就要花几分钟的时间。有时候光是等待软件编译完咸，就可以让开发人员有充裕的时问喝完一杯咖啡外加吃完一‘片蛋糕。这些等待都是不
必要的浪费，只会拖慢开发人员的脚步。所幸，这种延迟所形成的浪费是可以靠着花钱j轻易解决。钱要怎么花？很简单，帮开发人员的硬盘更换为市面上目前访问速度最快的固态硬盘(solid-state drive,SSD),22寸以上的16:10大屏幕（或是使用双屏幕），增加很多很多的内存（把计算机的内存插槽全部插满， 至少8GB以上），购买一把舒适的座椅（最好是那种台币一万以上的人体工学椅），配备支持结对编程的大桌子。除了开发环境之外，测试环境也很重要。很多时候开发进度延误并非是冈为程序写不完，而是没有足够的测试设备加速整体的开发流程。冈此，请帮团队准备充裕的测试设备，例如：提供很多、很多、很多的虚拟或实体测试机器，购买一台超级快的持续集成服务器，架设分布式持续集成系统与环境等（这种花钱可解决问题的实际案例，可参考<CH71：十分钟建构））。

      以上总结为一句话——采用敏捷方法就对了啦！
 
         

       注释1---- 一个函数或方法调用自己，这样的函数称为递9：j函数。递少：j函数每次调用白己的时候，计算机会把本次执行的状态先暂时存放往一个称为“堆栈”的数据结构中（stack；想象一下，你把你家里厨房的盘子堆成一大叠，  卜面的盘了压着下面的盘了．。每次要拿盘了的时候只能从最I．-面那个开始拿起，这就是堆栈数据结构的行为），等待递少I调用返心之后（从调用白己的状念中返叫）再从堆栈中驭出上次执行状态以便继续未完成的计算过程。以卜看彳<懂都没关系，。醺点足这种递归调用的程序一定要有正确的终结条件j，否则程序不断调用白已，等待陷入无限循环之中而无法脱离。由于计算机所配置的堆栈空间是有大小限制的，如果递归程序写错或足递¨阶层过深，造成堆栈窄问满出（overflow，就是空间不够用的意思），此种现象就称为“stack overflow”。