濟南軟件開(kāi)發(fā)之軟件開(kāi)發(fā)中的11個系統思維定律

2015-10-14 10:06:44
    1. 今日的問題源于昨日的解決方案(Today’s problems come from yesterday’s solutions)
  當解決問題時,我們會(huì)感到很高興。我們經(jīng)常不考慮後(hòu)果。令人感到意外的是,我們提出的解決方案可能(néng)會(huì)産生反作用,并帶來新問題。
    作爲對(duì)取得巨大成(chéng)功的團隊的獎勵,公司決定爲團隊中的少數骨幹成(chéng)員發(fā)放獎金并晉升職位。團隊中的其他成(chéng)員會(huì)感到不公平,并且會(huì)喪失積極性。最終使團隊成(chéng)員之間的關系更加緊張,後(hòu)續項目也就(jiù)很難再取得成(chéng)功。
項目經(jīng)理頻繁要求開(kāi)發(fā)者修複一個新的軟件Bug,或者處理客戶的緊急需求,而開(kāi)發(fā)者盡力滿足這(zhè)些要求。但是,過(guò)于頻繁地分散精力會(huì)妨礙他們完成(chéng)叠代過(guò)程中的主要任務。因此,項目進(jìn)展很慢。
  2. 用力越大,系統的反作用力也越大(The harder you push, the harder the system pushes back)
  當事(shì)情的進(jìn)展結果并非如我們所願時,我們會(huì)固執地堅持自己的方法。我們沒(méi)有時間來停下來思維并尋找更好(hǎo)的替代方案,而是“義無反顧”地向(xiàng)前沖。有時候雖然解決了問題,但往往又發(fā)現深陷于其他問題之中。
   當一個系統遠未完成(chéng)時,經(jīng)理通常會(huì)不斷催促員工加班加點地工作,并且要求按時完成(chéng)。系統bug數量的持續增加及整體質量的急劇下降,導緻更多的延誤。因此,需要做更多的工作來部署軟件系統。
    爲了滿足新系統的要求,開(kāi)發(fā)者勇敢的對(duì)原有的系統架構進(jìn)行擴展,但死闆陳舊的方法已經(jīng)不能(néng)滿足這(zhè)些新需求。他們忙于做這(zhè)件事(shì),以至于沒(méi)有時間停下來仔細分析并且改變方法,從而導緻系統質量下降。
  3. 福兮禍之所伏(Behavior grows better before it grows worse)
  短期的解決方案,會(huì)給我們帶來短暫的休息和狀況的暫時改善,但是不會(huì)從根本上解決問題。這(zhè)些問題終究會(huì)使情況變得更糟。
公司爲顧客提供豐厚的優惠并投入巨資宣傳,讓很多人購買軟件 。但是,顧客購買之後(hòu)很不滿意,因爲軟件無法使用也不可靠。
如果開(kāi)發(fā)小組能(néng)夠按時完成(chéng)系統開(kāi)發(fā),管理層承諾,如果開(kāi)發(fā)團隊能(néng)夠按時完成(chéng)系統開(kāi)發(fā),公司會(huì)提供巨額的獎金。一個團隊開(kāi)始努力的工作,但很快他們就(jiù)意識到這(zhè)是不可能(néng)實現的。于是開(kāi)發(fā)者變得悲觀并喪失動力。
  4. 最容易出去的方法往往會(huì)導緻返回來(The easy way out usually leads back in)
  在生活中學(xué)到的一些解決方案能(néng)夠幫助我們輕易地并且更早的地獲得成(chéng)功。我們總是試圖把它們強加到任何情形上,而忽略了特殊的背景以及相關人員。
開(kāi)發(fā)者還(hái)沒(méi)有準備好(hǎo)接受結對(duì)編程或者測試驅動開(kāi)發(fā)這(zhè)樣(yàng)的實踐時,敏捷教練強行實現完全的極限編程。這(zhè)會(huì)給任何敏捷方法帶來壓力、沖突以及負面(miàn)影響。
開(kāi)發(fā)者把設計模式應用到任何地方,這(zhè)是徒勞的,而且這(zhè)會(huì)讓系統變得複雜。
  5. 治療帶來的結果可能(néng)會(huì)比疾病導緻後(hòu)果更嚴重(The cure can be worse than the disease)
  有些熟知的方法可能(néng)會(huì)更危險,比如在編程的時候喝啤酒,來減輕不切實際的任務期限帶來的壓力。
由于不信任全職開(kāi)發(fā)者,一家公司雇傭了大量的承包商來開(kāi)發(fā)核心功能(néng)。結果,系統不具有概念完整性,自己公司的開(kāi)發(fā)者看不懂,并且無法做出修改。所以,公司員工也不了解相關領域的知識、解釋以及概念。
開(kāi)發(fā)者會(huì)走捷徑,拷貝相似功能(néng)的代碼來趕進(jìn)度,并且争取盡快發(fā)行第一個版本。他們一開(kāi)始進(jìn)展迅速,但是代碼最終會(huì)變成(chéng)大泥球(比喻系統結構不清晰)。
  6. 欲速則不達(Faster is slower)
  當我們看到成(chéng)功的曙光,我們會(huì)全力以赴,不再小心謹慎。然而,最優增長(cháng)速率通常會(huì)比可能(néng)的最快增長(cháng)速率要慢得多。
經(jīng)理們往往爲已經(jīng)成(chéng)功的項目增加很多人手,但總體進(jìn)展就(jiù)會(huì)變慢,因爲交流所用的花費增加,以及團隊成(chéng)員之間失去默契。
在沒(méi)有對(duì)代碼進(jìn)行合理重構及改善的情況下,開(kāi)發(fā)者快速的爲系統添加新的功能(néng),會(huì)使系統變得難懂,而且難以修改。
  7. 在時間和空間上,因果并不密切相關(Cause and effect are not closely related in time and space)
  我們善于爲出現的困難尋找原因,即使這(zhè)些原因很牽強,并且遠非是真正的根本原因。
爲了按時完成(chéng)系統,開(kāi)發(fā)團隊不再接受來自客戶的需求改變。因此,客戶對(duì)發(fā)行的軟件不滿意。
實時系統曆經(jīng)坎坷之後(hòu),管理層迫使開(kāi)發(fā)者同意,并且在給系統做出任何修改之前撰寫詳細的技術說明。結果開(kāi)發(fā)者失去了爲系統做出任何改進(jìn)的動力,并且開(kāi)始拖延。
  8. 微小的改變可以産生明顯的效果,但這(zhè)種(zhǒng)杠杆效應最大的地方往往也最不明顯(Small changes can produce big results-but the areas of highest leverage are often the least obvious)
  像改變公司政策、願景或者廣告用語這(zhè)樣(yàng)顯而易見并且關系重大的解決方案往往不起(qǐ)作用。相反,小而普通,但持續的改變卻會(huì)帶來大不相同的效果。
開(kāi)發(fā)者每天都(dōu)與客戶進(jìn)行交流,并且做出大部分決定。因此,能(néng)夠更好(hǎo)地理解客戶的需求、做出更好(hǎo)的決定并且給出最優的解決方案。
開(kāi)發(fā)者爲系統的每項功能(néng)設計自動化單元測試。因此,設計更靈活、人們更自信、系統在每次修改之後(hòu)都(dōu)能(néng)得到完全的測試。
  9. 魚與熊掌可以兼得,但不是同時兼得(You can have your cake and eat it too – but not at once)
  我們經(jīng)常會(huì)面(miàn)對(duì)刻闆的“非此即彼”選擇。如果我們改變一下自己的觀點及系統規則,這(zhè)些選擇有時并不會(huì)使我們進(jìn)退兩(liǎng)難。
經(jīng)驗豐富的項目經(jīng)理知道(dào)增加系統特性的數量與削減時間和開(kāi)支不可兼得。然而,如果我們完善一下想法、尋找合适的人才并且避免過(guò)度開(kāi)發(fā),這(zhè)也是可能(néng)做到的。
開(kāi)發(fā)者認爲他們應該要麼(me)采用事(shì)務腳本,要麼(me)采用域模型體系架構模式。然而,複合域中的高性能(néng)解決方案可以將(jiāng)兩(liǎng)者結合,以得到最佳性能(néng)。
  10. 把一頭大象分兩(liǎng)半不會(huì)得到兩(liǎng)頭大象(Dividing an elephant in half does not produce two small elephants)
  無法整體了解系統,往往會(huì)做出次優決定。
項目經(jīng)理往往通過(guò)生成(chéng)的代碼量和叠代過(guò)程中實現的功能(néng)數來評估開(kāi)發(fā)者。而開(kāi)發(fā)者往往會(huì)生成(chéng)大量無用代碼。
管理層承諾,每發(fā)現一處系統bug,測試者將(jiāng)得到5美元。測試者對(duì)跟開(kāi)發(fā)者合作不再感興趣,并且不再試圖消除産生bug的根本因素。團隊之間良好(hǎo)而且高效的關系不複存在。
  11. 無可非議(There is no blame)
  我們喜歡歸咎于客觀條件,或對(duì)别人指指點點,甚至對(duì)此深信不疑。但是,我們自己以及問題的原因都(dōu)是系統的一部分。
今天早上團隊沒(méi)有發(fā)布系統完全是喬的過(guò)錯。即使項目經(jīng)理親切地爲其提供了免費的啤酒、T恤以及披薩,他也沒(méi)能(néng)在一晚上的時間内修複所有的缺陷。
人們不會(huì)使用一個公司優秀的Web 2.0社會(huì)化應用,用戶喜歡簡單實用的東西,并且不會(huì)感激你辛勤工作的成(chéng)果。
  然後(hòu)呢?
  以上11條系統思維定律表明,我們提出的所有解決方案都(dōu)會(huì)産生一定的後(hòu)果,有時非常嚴重并出乎意料。我們周圍的系統本就(jiù)那樣(yàng),我們不應苛責它們,而是要從中學(xué)習。要掌握系統思維方式并控制這(zhè)些系統,我們需要做到如下幾點:
    1. 要明白我們是在跟什麼(me)樣(yàng)的系統打交道(dào),是人或是軟件;
    2. 有意識地學(xué)習相互關系、因果鏈;
    3. 把系統看做一個整體,并且視其爲其他系統的一部分。
  系統思維方面(miàn)有很多挑戰,通過(guò)獲取并且利用有關系統工作方式的知識,我們可以戰勝其中的很多挑戰。但是,大部分嚴峻挑戰是我們人類與之相沖突的本性。我們的激情、感情以及本能(néng)可以輕易改變我們理智、條理分明的思維方式。掌握系統思維方式的第一步就(jiù)是要學(xué)習如何跟自己合作。