顯示具有 人月神話 標籤的文章。 顯示所有文章
顯示具有 人月神話 標籤的文章。 顯示所有文章

人月神話//建議閱讀方式及順序

撰寫日期 沒有留言:
人月神話，是經典之作，經典到我不唸，都覺得怪怪的，自己唸，又覺得可惜，所以最後找了一群伙伴們一起唸，真是奢華的幸福。

建議：
有經驗的時候，再來看
什麼經驗呢？軟體團隊開發經驗
這本書談到的，不外乎就是溝通、管理的問題
與自己的溝通就是設計
與別人的溝通就是文件、會議
團隊內的管理、團隊間的管理、和經理之間的管理

這些複雜的哲學問題，必須要有經驗，才會有所體會。
不過，若即將會有經驗的人，可以先看也不錯。

最不好的就是看了，沒有實踐，要等「溫故知新」的時候，才會有所收獲。

章節順序
人月神話二十年
沒有銀彈
再論沒有銀彈
人月神話是真是假
再從第一章開始看到最後

在人月神話二十年中，說了一些以前說錯的事，必須要看到最後，才可以得到的寶藏。
另外，有第五章的第二系統，和第十一章的第二系統的語意問題，也可以先知道

再來看沒有銀彈，是因為時代的變遷，實在很難知道作者當年的專案開發使用的工具和環境是如何，所以...看了沒有銀彈之後，才發現，那時的新技術如：高階語言和物件導向，都是目前這時代有點舊的主流技術，對於再回頭去看人月神話主要的內容，談論的預估時程，也比較好明白，它究竟是拿什麼東西打怪，才估計要花多久的時間打怪，又用什麼單位（指令）預計呢？

再論沒不有銀彈，是在談沒有銀彈的部分，多年以來被反駁的部份
也是時代演進與新技術開發的討論（當時的時代），可以看見，有很多東西現在都不知道跑去哪了！（笑）
主要是對本質性與附屬性的討論更深入，可以在從頭看一次時，有更棒的體會。

人月神話是真是假，是前面十幾個章節的摘要，另外有加上重新詮釋的部份。
這部份也可以在看完全書之後，再看。
不過建議是同步看，每看完一個章節，就來看一次摘要，可以補完也可以修改，為未來複習做準備的好地方。


文章分類：

人月神話//二十年延伸書單

撰寫日期 沒有留言:
對於Brook定律的修正。
《Software Project Dynamics: An Integrated Approach》（一篇論文）

對於用人的智慧

Peopleware： 腦力密集產業的人才管理之道




















對於勞工激發創意和樂趣

外文：

文章分類：

人月神話//《沒有銀彈》之前章節的摘要

撰寫日期 沒有留言:

第1章焦油坑
    寫程式，是件麻煩事
第2章人月神話
    寫程式像生小孩，一個媽花十個月，十個媽還是要十個月（如果同時受孕的話）
第3章外科手術團隊
    要各司其職，支援主程式設計師的工作
第4章專制、民主與系統設計
    功能性vs概念整體性 的管理問題
    設計師與工匠，架構師規劃架構與確定概念整體性，程式設計師實現系統
第5章第二系統效應
    功能性vs概念整體性
    使用者中心設計，概念整體性才是最重要的
第6章意念的傳達
    專案人員的資訊管道，手冊、會議...
第7章巴別塔為什麼失敗？
    組識vs溝通 管理問題
    溝通的重要性，技術和管理，誰聽誰的？
第8章預估
（作者以組合語言專案的紀錄解釋）
    寫程式費力的程度=（常數）×（指令數量）^1.5
    不可以用跑一百公尺的速度預估跑一公里的速度
第9章地盡其利，物盡其用
    功能性vs硬體限制
    充份利用硬體，做好「軟硬體整合」
第10章文件假說
    為了決定人錢時地物，以及與人溝通，要準備什麼文件？
第11章失敗為成功之母
    第一次的系統失敗是專案一定要規劃進去的流程
    軟體維護的失敗及崩潰
第12章神兵利器
    講外科手術團隊裡提到的工具專家
    為團隊打造工具（或找到適合的工具）
第13章化整為零
    改版、測試與除錯的制度，建立好之後就只要一直run
第14章釀成大災難
    預防專案發生無法挽回的延遲，建立偵測進度小組
    主管、PM或老闆的定位及管理方法
第15章一體兩面
    文件寫在程式裡（自我說明程式），要怎麼寫？
 

第16章沒有銀彈——軟體工程的本質性與附屬性工作
    軟體創作工作分成本質性工作
第17章再論「沒有銀彈」
    幾年以來被反駁的反駁
第18章《人月神話》的主張：是真是假？
    整本書的摘要（REVIEW這本書）
第19章《人月神話》20年

後記
文章分類：

人月神話//《沒有銀彈》摘要

撰寫日期 沒有留言:
軟體創作工作
    本質性工作
        創造出一種抽象的軟體實體所組成的複雜概念結構。
    附屬性工作
        用程式語言來表現這些抽象的實體，並在某些空間和速度的限制下，將程式對應至機械語言。
（人為的artificial）
建議：
    ．利用大眾市場，避免開發現成買得到的東西
    ．利用rapid prototype反覆制定軟體需求
    ．讓軟體像生物一樣發育，在執行、使用、測試中擴充功能
    ．培養新一代的偉大設計人員

繼續看下去....
文章分類：
訂閱： 文章 (Atom)