IBM一旦決定擁抱變化,成就客戶,所面臨的實際問題很快涌現出來,雖然恰恰是敏捷所能夠解決的最核心問題,但仍然在這個問題上需要艱難的抉擇;過去的 80年代、90年代我們雖然總結出了強大的IPD軟件開發過程,甚至迭代式開放方式,但是所有的計劃和迭代需求在一開始就已經確立,團隊會參考長期和短期計劃完成所需任務,每個人都有非常清晰的明確定位,知道各自的目標和所需完成的工作量;大家形成了一種完全適合傳統開發的習慣,那就是設立目標,嚴格執行之直至完成;項目經理在進度和項目的方向的掌控上有著較大的權力,大家也習慣了服從指揮,做好螺絲釘;當然,與之俱來形成了的規則就是,但凡我要開展工作,我一定要確定“我可以進入”, 每每完成一項工作,大家也非常喜歡以“退出標準”作為尺度標定工作的完滿結束;傳統的工廠式軟件開發的流程逐漸變得沉重,項目經理疲于奔命的忙于各項指標的度量,做各種報表以滿足各級領導的視覺需求;而各級團隊不得不在各種指標和進度的選擇下,為了使得流程得以順利進行,都極可能的去維系自己的“角色職責”,概要計劃、詳細計劃方方面面,計劃面又包括了“首要優先級、次要工作”, 并明確排除了職責可能涉及的“但沒有足夠掌控能力、或者被可能影響嚴重"的工作. 因此,延遲和工作流程的臃腫,不同團隊之間的壁壘加深,保護意識過強。因此,軟件部的智囊團終于發現了IPD,這個本來就基于瀑布式模式所研究出來的開發方法,需要重新調整;
IBM 2009年的軟件部規??磥?, 全球有26065人廣泛分布在各大洲地區, 超過500個來自各個時期的收購,非常獨立的產品線;獨立而大量的工具和開發平臺在公司內被采用;從明眼人眼里看來,IBM分明就是成千上萬個小公司組成的;正因為“每家”都有自己的小九九,都充分相信了自身的成功法則;雖不是每個項目組風格各異,但是從IBM的5大品牌來看,行事作風迥異;勢必沒有一種技術、一種工具、一種流程、一種組織結構能夠一統天下;
原文轉自:http://blog.csdn.net/u012936954/article/details/16917007