• 您的電話 *

  • 您的需求

  • 發送

顛覆視覺創新  塑造優-秀品牌

展示企業形象  宣傳產品服務

您當前所在的位置:

搜索

50 年的軟件開發經驗帶給我的 63 個啟示

作者:華夏支點網絡 瀏覽:5380 發表時間:2020-10-31 14:49:04

技術圈能夠從業 50 年的開發者顯得彌足珍貴,本文作者 Karl Wiegers 就是這樣一位有著豐厚經驗的軟件行業從業者,在過去 50 年里,他積累了 63 條啟示,并將其梳理分享出來,希望對你有所啟發。


以下為譯文:

1970 年,我在大學里上了第一堂編程課(當然了,學的是 FORTRAN)。在過去的半個世紀中,我的很多時間都花在了軟件工作中:需求、設計、用戶體驗、編程、測試、項目管理、寫文檔,領導過程改進,撰寫 7 本書和許多篇文章,咨詢,培訓。

當然,在此過程中也完成了一些支線任務,比如讀了有機化學的 PhD(我的論文有三分之一都是計算機代碼),做了幾年的研究員。但基本上來說,我是個軟件行業的人。

在如此漫長的這段時間里,我積累了許多關于軟件行業的見解。在本文里,我將跟大家分享 63 個啟示,也許你也會像我一樣覺得它們很有用。


關于需求


1. 如果你沒有搞明白需求,那么項目的其他部分你做得再好也沒用,最終都會失敗的。

2. 午餐后你在辦公桌上發現的便簽紙,保存下來的語音郵件和電子郵件,以及記得似是而非的走廊上的隨意對話,所有這些都不能算得上是需求。這只是一堆信息而已。

3. 對于所有項目利益相關者來說,利益的交集在流程需求(Requirements Process)中發生得最多。

4. 如果缺少了高質量的需求,利益相關者們可能會對最后交付的內容感到倍感意外。在軟件中,意外幾乎總是壞消息的代名詞

5. 在探索需求時,請不要只考慮當前的用戶。你曾經的客戶仍然是你的客戶。

6. 人們不應該只是去“收集”需求。需求獲取是個探索,協作,發現和發明的過程,而不僅僅是簡單的收集。一個商業分析師不僅僅要干抄寫員的活。

7. 需求獲取的目的是讓客戶的聲音——即 VOC,voice of the customer——盡可能地貼近開發人員的耳朵——即 EOD,ear of the developer。商業分析師有助于縮小其中的溝通差距。

8. 對于需求獲取,人們通常寄希望于兩種方法:“心靈感應”和“千里眼”。但這兩樣都沒用。

9. 不管我們的文化怎樣宣稱,但客戶其實并不總是正確的。但是客戶總是有他自己的意見的,而你必須理解以及尊重這個意見。

10. 需求開發需要迭代。你不能指望在第一次討論中就 get 到所有的需求;要知道你可能永遠也無法完全 get 到。有效的需求開發涉及對細節和清晰度的逐步改進。

11. 不要害怕對需求進行記錄。與獲取知識的成本相比,記錄知識的成本很低。

12. 如果要求中未描述某些功能或特性,則沒人期望在產品中看到它。

13. 需求開發的可交付成果不僅僅是一組書面需求,而是一種共識和一致的預期。

14. 對于需求開發而言,比較實際的目標不是創建出的需求有多完美,而是創建出的需求足以使團隊以可接受的風險水平進行建設。這種風險就在于,由于被忽視的,不必要,不完整,模棱兩可或溝通不暢的情況下產出的需求,而不得不進行過多的計劃外返工的情況。

15. 我們有時在表達需求時會比較隨意,因為我們會假設讀者有一個跟我們自己類似的“理性過濾器”,但是對于一段相同的陳述,人們經常會以不同的方式解讀。這種模糊性會導致期望不匹配以及交付時的意外。

16. 把需求工作室和審核小組保持在一個較小的規模。一大群人連是否要離開一個起火了的房間的無法做到意見相同,更不用說在某項需求應該如何措辭上達成一致了。

17. 當有人提出新需求時,第一個要問的問題是:“這在我們的討論范圍之內嗎?”如果是的,那就必須解決。如果不是,那就不解決,或者至少不是現在解決。但是,如果答案是“不是,但我們應該關注這個問題”,那么你必須調整范圍來適應它。這對成本,進度,資源,參與度,優先級和效益折中都有影響。

18. 如果你沒有一個記錄在案且已達成共識的項目范圍,怎么能知道自己是否正在經歷范圍蔓延?

19. 在決定要在一個產品或迭代中包含哪些功能時,請避免“分貝優先級”的做法(俗稱按鬧分配)。聲音最大的那些客戶所要求的功能從業務角度來說并不一定是最重要的。

20. 項目的利益相關者們必須能夠理解,對可能的需求進行討論與承諾將其包含在產品中之間是有區別的。

21. 有兩個術語,你聽到時一定要提高警惕:“假定需求”和“隱含需求”。要力爭明確地交流需求的預期。


關于項目管理


22. “項目管理”指的不是一項具體活動。項目管理是人員管理,需求管理,風險管理,機會管理,預期管理,承諾管理,變更管理,資源管理,以及供應商管理的混合物。

23. 為什么有些公司永遠沒有時間來好好地做出軟件,而后續卻總能擠出時間,金錢和人力來彌補?這是一個謎。

24. 每個人都愿意認為自己的團隊擁有頂尖人才,但事實是在所有軟件開發人員中有半數的能力都低于平均水平。那么這些人都在哪工作呢?

25. 不要輕易地評估任何人。如果別人請你評估,最合適的回復是:“讓我先考慮一下,回頭再與您聯系吧。”

26. 無論別人施加給你多大壓力,都不要給出自己無法兌現的承諾。

27. 如果你手上有很有說服力的數據,而對方幾乎沒有任何數據的話,你在談判中就會占據優勢地位。

28. 除非你把評估記錄下來并將其與實際發生的情況進行比較,否則你將永遠是在猜測,而不是在評估。

29. 不能因為覺得對方喜歡聽好話,就影響到你對某人的評估。


關于質量與過程改進


30. 關于軟件質量:你可以現在就付錢給我,也可以以后再付給我,但是要付得更多。

31. 力求完美;追求卓越。

32. 永遠都別被老板或客戶說服去做壞事。

33. 質量應該是你的重中之重。高質量的自然結果就是長足的生產力,因為這樣團隊就不需要浪費太多時間進行返工了。

34. 力求能讓一位同輩,而不是客戶來發現缺陷。同輩技術評審是一種行之有效的技術,可以提高質量和生產力。

35. 如果和你打交道的人不講理,那任何軟件工程方面的技術都沒用。

36. 當人們被要求改變自己的工作方式時,他們的本能反應是問“這對我有什么好處?”但其實這個問法是不對的。正確的問法應該是“這對我們團隊有什么好處?”

37. 軟件開發人員永遠都在尋找出色的工具,但請記住,小傻瓜有了工具以后也只會變成大傻瓜。

38. 當人們不了解當前工作方式所導致的痛點在哪里時,進行流程更改是很難的。就像如果人們不知道自己家里有老鼠,就很難把更好的捕鼠器賣給他們。

39. 問:更換燈泡需要多少名軟件過程負責人?答:只需要一個,但前提是燈泡必須愿意被更換。

40. 在朝著新的工作方式發展的過程中,不要低估改變組織文化的必要性和困難程度。實行一套新流程比灌輸一種新文化更快。你需要在這兩方面都做到成功。

41. 不管是否是出于好意,改進計劃如果不能轉化為行動那都無濟于事。

42. 在許多情況下,常識,良好的判斷力,以及經驗應當比正式程序更重要。但是,有時候這個程序的存在是有充分理由的。在決定繞過它之前需要先調查一下。

43. 在領導組織采用新的工作方式時,請不斷輕柔地施以壓力。

44. 能促使人們改變工作方式的最好動力是痛苦。不是人為的,外部施加的痛苦,而是當前工作方式帶給團隊的非常真實的痛苦。選擇那些可以最終減輕痛苦的改善活動吧。

45. 除非你花時間進行回顧,學習經驗教訓并不斷改進團隊的流程,否則沒有理由來預期下一個項目能比上一個項目做得更好。

46. 你不能一下更改所有內容。找出那些能夠帶來最大收益的流程變更,并在下個周一開始實施。我沒有開玩笑:就是下周一!

47. 對文檔模板中采用“縮小以適應”的理念。先從一個豐富的模板開始,用來提醒你多考慮有哪些信息可以包含進去,然后再根據每個項目的規模,性質和需求來進行重塑。

48. 有許多團隊都被要求做到事半功倍。不過,通常情況下,他們并沒有能讓自己事半功倍的方法。如果沒有相應的培訓和過程改進來提高效率和效果,就不要期望更高的生產力會神話般地自己顯現。

49. 適用于四個在同一辦公室里工作的人的非正式流程是無法擴展到在不同大陸工作的多個開發團隊上面的。

50. 如果軟件行業有什么東西是可復現的,那就是在一個又一個的項目上重復地做同樣的蠢事。你需要通過回顧來學習,理解,以及不斷改進。

51. 當人們不遵循既定流程時,你面前只有三種選擇:(1)讓人們開始遵循流程;(2)調整流程使其更加有效和實用,然后讓人們遵循它;(3)放棄這個流程并不再假裝你遵循這個過程。


其他見解


52. 人工智能不能替代真實的事物。

53. 在技術界,如果你領先其他人一個星期,那么你就是大佬了。

54. 今天的“必須馬上搞定它”的那種開發項目會成為明天的遺留系統維護噩夢。

55. 軟件系統的許多問題都發生在接口上:軟件和軟件,軟件和硬件,軟件和人,人和人。這些接口需要好好研究。

56. 人們總是過多地談論自己的“權利”。而每項權利的另一面都是責任。要以協作的心態去思考以及行動。

57. 一盎司的設計相當于一磅的重構。

58. 要當心“商業周刊式的管理方式”——僅僅因為有人讀到了它所承諾的極好結果,就匆忙地在軟件開發中采用最熱門的新事物。

59. 在拇指和食指之間保持一英寸的距離。在大多數情況下,這就是質量和垃圾之間的唯一區別。只在于多聆聽一點,檢查一下你的工作,再次運行測試,參考清單,閱讀說明,再多問一個問題。通常,這是改善垃圾的唯一方法。

60. 你沒有時間去重新犯一遍那些軟件從業者之前犯過的錯誤。閱讀并尊重文獻。向你的同事學習。慷慨地與他人分享你的知識。

61. 軟件開發中計算技術可能占 50%,剩下 50%在于交流溝通。但商業分析是完全在于交流溝通的。我們在計算方面要占得更多。

62. 如果你想自立門戶做個獨立顧問或承包商,則你需要向全世界宣告自己有空。如果沒有人了解你,那不管你業務能力有多好都沒用。

63. 在軟件行業中,我們經常會假裝。我們假裝已經找到了合適的利益相關者,他們了解自己的業務目標,并且清楚自己的需求。我們假裝合適的人向我們傳達了正確的需求,?

50 年的軟件開發經驗帶給我的 63 個啟示
技術圈能夠從業 50 年的開發者顯得彌足珍貴,本文作者 Karl Wiegers 就是這樣一位有著豐厚經驗的軟件行業從業者,在過去 50 年里,他積累了 63 條啟示,并將其梳理分享出來,希望對你有所啟發。
長按圖片保存/分享
0

50 年的軟件開發經驗帶給我的 63 個啟示

2020-10-31 14:49:04

瀏覽: 5381

技術圈能夠從業 50 年的開發者顯得彌足珍貴,本文作者 Karl Wiegers 就是這樣一位有著豐厚經驗的軟件行業從業者,在過去 50 年里,他積累了 63 條啟示,并將其梳理分享出來,希望對你有所啟發。

技術圈能夠從業 50 年的開發者顯得彌足珍貴,本文作者 Karl Wiegers 就是這樣一位有著豐厚經驗的軟件行業從業者,在過去 50 年里,他積累了 63 條啟示,并將其梳理分享出來,希望對你有所啟發。


以下為譯文:

1970 年,我在大學里上了第一堂編程課(當然了,學的是 FORTRAN)。在過去的半個世紀中,我的很多時間都花在了軟件工作中:需求、設計、用戶體驗、編程、測試、項目管理、寫文檔,領導過程改進,撰寫 7 本書和許多篇文章,咨詢,培訓。

當然,在此過程中也完成了一些支線任務,比如讀了有機化學的 PhD(我的論文有三分之一都是計算機代碼),做了幾年的研究員。但基本上來說,我是個軟件行業的人。

在如此漫長的這段時間里,我積累了許多關于軟件行業的見解。在本文里,我將跟大家分享 63 個啟示,也許你也會像我一樣覺得它們很有用。


關于需求


1. 如果你沒有搞明白需求,那么項目的其他部分你做得再好也沒用,最終都會失敗的。

2. 午餐后你在辦公桌上發現的便簽紙,保存下來的語音郵件和電子郵件,以及記得似是而非的走廊上的隨意對話,所有這些都不能算得上是需求。這只是一堆信息而已。

3. 對于所有項目利益相關者來說,利益的交集在流程需求(Requirements Process)中發生得最多。

4. 如果缺少了高質量的需求,利益相關者們可能會對最后交付的內容感到倍感意外。在軟件中,意外幾乎總是壞消息的代名詞

5. 在探索需求時,請不要只考慮當前的用戶。你曾經的客戶仍然是你的客戶。

6. 人們不應該只是去“收集”需求。需求獲取是個探索,協作,發現和發明的過程,而不僅僅是簡單的收集。一個商業分析師不僅僅要干抄寫員的活。

7. 需求獲取的目的是讓客戶的聲音——即 VOC,voice of the customer——盡可能地貼近開發人員的耳朵——即 EOD,ear of the developer。商業分析師有助于縮小其中的溝通差距。

8. 對于需求獲取,人們通常寄希望于兩種方法:“心靈感應”和“千里眼”。但這兩樣都沒用。

9. 不管我們的文化怎樣宣稱,但客戶其實并不總是正確的。但是客戶總是有他自己的意見的,而你必須理解以及尊重這個意見。

10. 需求開發需要迭代。你不能指望在第一次討論中就 get 到所有的需求;要知道你可能永遠也無法完全 get 到。有效的需求開發涉及對細節和清晰度的逐步改進。

11. 不要害怕對需求進行記錄。與獲取知識的成本相比,記錄知識的成本很低。

12. 如果要求中未描述某些功能或特性,則沒人期望在產品中看到它。

13. 需求開發的可交付成果不僅僅是一組書面需求,而是一種共識和一致的預期。

14. 對于需求開發而言,比較實際的目標不是創建出的需求有多完美,而是創建出的需求足以使團隊以可接受的風險水平進行建設。這種風險就在于,由于被忽視的,不必要,不完整,模棱兩可或溝通不暢的情況下產出的需求,而不得不進行過多的計劃外返工的情況。

15. 我們有時在表達需求時會比較隨意,因為我們會假設讀者有一個跟我們自己類似的“理性過濾器”,但是對于一段相同的陳述,人們經常會以不同的方式解讀。這種模糊性會導致期望不匹配以及交付時的意外。

16. 把需求工作室和審核小組保持在一個較小的規模。一大群人連是否要離開一個起火了的房間的無法做到意見相同,更不用說在某項需求應該如何措辭上達成一致了。

17. 當有人提出新需求時,第一個要問的問題是:“這在我們的討論范圍之內嗎?”如果是的,那就必須解決。如果不是,那就不解決,或者至少不是現在解決。但是,如果答案是“不是,但我們應該關注這個問題”,那么你必須調整范圍來適應它。這對成本,進度,資源,參與度,優先級和效益折中都有影響。

18. 如果你沒有一個記錄在案且已達成共識的項目范圍,怎么能知道自己是否正在經歷范圍蔓延?

19. 在決定要在一個產品或迭代中包含哪些功能時,請避免“分貝優先級”的做法(俗稱按鬧分配)。聲音最大的那些客戶所要求的功能從業務角度來說并不一定是最重要的。

20. 項目的利益相關者們必須能夠理解,對可能的需求進行討論與承諾將其包含在產品中之間是有區別的。

21. 有兩個術語,你聽到時一定要提高警惕:“假定需求”和“隱含需求”。要力爭明確地交流需求的預期。


關于項目管理


22. “項目管理”指的不是一項具體活動。項目管理是人員管理,需求管理,風險管理,機會管理,預期管理,承諾管理,變更管理,資源管理,以及供應商管理的混合物。

23. 為什么有些公司永遠沒有時間來好好地做出軟件,而后續卻總能擠出時間,金錢和人力來彌補?這是一個謎。

24. 每個人都愿意認為自己的團隊擁有頂尖人才,但事實是在所有軟件開發人員中有半數的能力都低于平均水平。那么這些人都在哪工作呢?

25. 不要輕易地評估任何人。如果別人請你評估,最合適的回復是:“讓我先考慮一下,回頭再與您聯系吧。”

26. 無論別人施加給你多大壓力,都不要給出自己無法兌現的承諾。

27. 如果你手上有很有說服力的數據,而對方幾乎沒有任何數據的話,你在談判中就會占據優勢地位。

28. 除非你把評估記錄下來并將其與實際發生的情況進行比較,否則你將永遠是在猜測,而不是在評估。

29. 不能因為覺得對方喜歡聽好話,就影響到你對某人的評估。


關于質量與過程改進


30. 關于軟件質量:你可以現在就付錢給我,也可以以后再付給我,但是要付得更多。

31. 力求完美;追求卓越。

32. 永遠都別被老板或客戶說服去做壞事。

33. 質量應該是你的重中之重。高質量的自然結果就是長足的生產力,因為這樣團隊就不需要浪費太多時間進行返工了。

34. 力求能讓一位同輩,而不是客戶來發現缺陷。同輩技術評審是一種行之有效的技術,可以提高質量和生產力。

35. 如果和你打交道的人不講理,那任何軟件工程方面的技術都沒用。

36. 當人們被要求改變自己的工作方式時,他們的本能反應是問“這對我有什么好處?”但其實這個問法是不對的。正確的問法應該是“這對我們團隊有什么好處?”

37. 軟件開發人員永遠都在尋找出色的工具,但請記住,小傻瓜有了工具以后也只會變成大傻瓜。

38. 當人們不了解當前工作方式所導致的痛點在哪里時,進行流程更改是很難的。就像如果人們不知道自己家里有老鼠,就很難把更好的捕鼠器賣給他們。

39. 問:更換燈泡需要多少名軟件過程負責人?答:只需要一個,但前提是燈泡必須愿意被更換。

40. 在朝著新的工作方式發展的過程中,不要低估改變組織文化的必要性和困難程度。實行一套新流程比灌輸一種新文化更快。你需要在這兩方面都做到成功。

41. 不管是否是出于好意,改進計劃如果不能轉化為行動那都無濟于事。

42. 在許多情況下,常識,良好的判斷力,以及經驗應當比正式程序更重要。但是,有時候這個程序的存在是有充分理由的。在決定繞過它之前需要先調查一下。

43. 在領導組織采用新的工作方式時,請不斷輕柔地施以壓力。

44. 能促使人們改變工作方式的最好動力是痛苦。不是人為的,外部施加的痛苦,而是當前工作方式帶給團隊的非常真實的痛苦。選擇那些可以最終減輕痛苦的改善活動吧。

45. 除非你花時間進行回顧,學習經驗教訓并不斷改進團隊的流程,否則沒有理由來預期下一個項目能比上一個項目做得更好。

46. 你不能一下更改所有內容。找出那些能夠帶來最大收益的流程變更,并在下個周一開始實施。我沒有開玩笑:就是下周一!

47. 對文檔模板中采用“縮小以適應”的理念。先從一個豐富的模板開始,用來提醒你多考慮有哪些信息可以包含進去,然后再根據每個項目的規模,性質和需求來進行重塑。

48. 有許多團隊都被要求做到事半功倍。不過,通常情況下,他們并沒有能讓自己事半功倍的方法。如果沒有相應的培訓和過程改進來提高效率和效果,就不要期望更高的生產力會神話般地自己顯現。

49. 適用于四個在同一辦公室里工作的人的非正式流程是無法擴展到在不同大陸工作的多個開發團隊上面的。

50. 如果軟件行業有什么東西是可復現的,那就是在一個又一個的項目上重復地做同樣的蠢事。你需要通過回顧來學習,理解,以及不斷改進。

51. 當人們不遵循既定流程時,你面前只有三種選擇:(1)讓人們開始遵循流程;(2)調整流程使其更加有效和實用,然后讓人們遵循它;(3)放棄這個流程并不再假裝你遵循這個過程。


其他見解


52. 人工智能不能替代真實的事物。

53. 在技術界,如果你領先其他人一個星期,那么你就是大佬了。

54. 今天的“必須馬上搞定它”的那種開發項目會成為明天的遺留系統維護噩夢。

55. 軟件系統的許多問題都發生在接口上:軟件和軟件,軟件和硬件,軟件和人,人和人。這些接口需要好好研究。

56. 人們總是過多地談論自己的“權利”。而每項權利的另一面都是責任。要以協作的心態去思考以及行動。

57. 一盎司的設計相當于一磅的重構。

58. 要當心“商業周刊式的管理方式”——僅僅因為有人讀到了它所承諾的極好結果,就匆忙地在軟件開發中采用最熱門的新事物。

59. 在拇指和食指之間保持一英寸的距離。在大多數情況下,這就是質量和垃圾之間的唯一區別。只在于多聆聽一點,檢查一下你的工作,再次運行測試,參考清單,閱讀說明,再多問一個問題。通常,這是改善垃圾的唯一方法。

60. 你沒有時間去重新犯一遍那些軟件從業者之前犯過的錯誤。閱讀并尊重文獻。向你的同事學習。慷慨地與他人分享你的知識。

61. 軟件開發中計算技術可能占 50%,剩下 50%在于交流溝通。但商業分析是完全在于交流溝通的。我們在計算方面要占得更多。

62. 如果你想自立門戶做個獨立顧問或承包商,則你需要向全世界宣告自己有空。如果沒有人了解你,那不管你業務能力有多好都沒用。

63. 在軟件行業中,我們經常會假裝。我們假裝已經找到了合適的利益相關者,他們了解自己的業務目標,并且清楚自己的需求。我們假裝合適的人向我們傳達了正確的需求,?

作者: 華夏支點網絡
0
50 年的軟件開發經驗帶給我的 63 個啟示
技術圈能夠從業 50 年的開發者顯得彌足珍貴,本文作者 Karl Wiegers 就是這樣一位有著豐厚經驗的軟件行業從業者,在過去 50 年里,他積累了 63 條啟示,并將其梳理分享出來,希望對你有所啟發。
長按圖片保存/分享

相關設計案例

相關網站設計案例

建站資訊

.

Are you interested in ?

擼起袖子干,干之前,先說說您的要求吧!


網站制作咨詢電話

15285141318

18685842288


  微信客服


填寫網站制作,網頁設計,seo優化需求  * 請認真填寫需求信息,24小時內與您聯系。

  • 您的電話 *

  • 您的需求

  • 提交咨詢

? 2012-2020 華夏支點 版權所有 黔ICP備2020008579號  黔公網安備 01982109827101號    SITEMAP

專業的網站建設/推廣、微信小程序開發、軟件開發公司

服務熱線:15285141318 / 18685842288

建站郵箱:449180048@qq.com

? 2010-2020  華夏支點網絡  版權所有  SITEMAP

在線咨詢
TOP
在線咨詢
在線咨詢 聯系方式 二維碼
熱線電話
15285141318
E-mail地址
449180048@qq.com
二維碼
TOP
特区彩票论坛海南七星彩 湖北11选5前三组 内蒙古时时彩精准预测 内蒙古快3走势图今天开始 中国高频彩票官网 亿客隆官方APP 今天3d试机号和金马 足彩胜负彩投注技巧预测360 新时时彩大赢家 - 点击进入 _平码独平)公式规律 开发彩票平台违法 钱爷爷江西新时时彩 - 点击进入 六合彩二肖中特 澳洲幸运10的玩法 澳门百家乐官网_Welcome 冰球突破5个轮多少 体彩大乐透1机选号码