from http://forum.javaeye.com/viewtopic.php?t=1499
said by dlee：
一個合格的 PM 至少要身兼 3 個角色，對于客戶他是技術(shù)專家，幫助客戶使用技術(shù)手段解決各種業(yè)務(wù)問題。對于程序員他是業(yè)務(wù)專家，幫助程序員理解客戶的需求，與程序員一道做設(shè)計。做好各種輔助工作（建立和維護(hù)開發(fā)環(huán)境，尋找適合的開發(fā)工具），便于程序員以最高的效率完成工作。PM 其實(shí)起到的是一個業(yè)務(wù)知識與技術(shù)知識之間的橋梁作用（很多公司并沒有 PreSales 這個職位，因此 PreSales 的工作其實(shí)是由 PM 來擔(dān)任的）。同時 PM 還是一個管理者和督導(dǎo)者，要以最有效率的方式組合各種資源，合理安排進(jìn)度、計劃和目標(biāo)，按時交付具有一定質(zhì)量保證的產(chǎn)品。
from http://forum.javaeye.com/viewtopic.php?t=1407
said by dlee:
我大致看了一下，感覺這本書的內(nèi)容非常棒。而且我認(rèn)為 FDD 是比 XP 的 TDD 更適合于中國的軟件開發(fā)過程。
我讀過 XP 的教材后的想法是：別急，先等等看。
讀過 FDD 的教材后的想法是：還等什么，明天就做起來。
said by o6z:
最近經(jīng)?？吹接懻摂?shù)據(jù)建模和對象建模的問題，還看到業(yè)務(wù)建模的問題。而我覺得我們說了這么久，真的沒有color UML那么幾頁紙對我觸動大。雖然uml with color不是設(shè)計的解決方案，但是你會看到它對于需求了領(lǐng)域的把握是非常出色而令人經(jīng)驗(yàn)的。趕快學(xué)習(xí)，不要耽誤。
簡單的令人吃驚，有效的令人吃驚的東西。我實(shí)在是佩服together的創(chuàng)意，和他們邏輯嚴(yán)謹(jǐn)?shù)乃季S方式。它用4個原型概況了很多讓人迷惑的東西，用12個組件推出了經(jīng)常出現(xiàn)的一些場景模式。我想如果誰有時間，把那200頁左右的《Java Modeling in UML with Color》翻譯成中文就好了。
from http://forum.javaeye.com/viewtopic.php?t=5055
said by o6z:
我讀書還喜歡讀那些可以放下不管，沒有事情再拿起來翻的書。比如gof，你完全就可以看過前面的原則的部分，然后瀏覽一下后面的具體的東西，然后就放下，等你覺得一個地方可以使用一個什么模式，再去查，查完又放下。
其實(shí)寫用例也是如此。為什么會覺得困難，我想大概多數(shù)人總是追求一個詳細(xì)的用例說明，而忘記用例是拿來用的，而不是拿來寫的。用不到的部分就可以暫時不那么精細(xì)，等你開發(fā)到那個地方再去細(xì)化。這個也是自己練習(xí)增量迭代的一個步驟。
from http://forum.javaeye.com/viewtopic.php?t=5481
said by o6z:
本人接觸日本人的開發(fā)方式還算早。他們的V模型其實(shí)還是很好的，但是除此以外日本人的東西可以說全都是反面教材。而對于敏捷在日本的流行也比我們這里熱的多。但是我不想給大家介紹這些，因?yàn)檫@些不是問題的核心?，F(xiàn)在我們面對的不是不是5年前，以至于不是一年前?，F(xiàn)在我們面對的是變化多端的市場體系，是一種對成本核算和質(zhì)量標(biāo)準(zhǔn)要求近乎苛刻的市場。那些讓你可以溫文爾雅的按部就班的方法論，都不能讓你適應(yīng)這樣的環(huán)境。XP在我看來都不夠極端，都不能面對這樣的場景。日本人的小兒科就更加讓人覺得可笑。
現(xiàn)在我們即將面對的情況是你必然會失敗，成功只是一展偶然的運(yùn)氣。我們所能做的，也不是那些以前些年軟件工程研究的減少錯誤，優(yōu)化流程就可以讓你成功的了。我們將面對的環(huán)境要惡劣的多。在這樣的條件下生存就將按照一種另外的形式進(jìn)行，那些不能及時專橫跋扈思維方式的人面對的就只有死亡。軟件開發(fā)將從新成為一種個人英雄主義的活動，任何一種試圖依靠所謂的方法和過程學(xué)說都會被認(rèn)為是腦筋錯亂的產(chǎn)物。組織高度自管理自控制，扁平的組織成為唯一的形式。動態(tài)和高變化成為首先要考慮的，所謂的以需求為驅(qū)動的開發(fā)將被徹底的拋棄。
我不知道誰能生存在這樣的環(huán)境中，但是我知道日本人肯定不能生存。
said by dlee:
o6z 兄的話深合我心。以前軟件工程一類的書中舉的案例動輒就是數(shù)十人、上百人的團(tuán)隊，開發(fā)時間持續(xù)一年以上。但是事實(shí)上我做過的項目很少有 6 個人以上、持續(xù)時間超過半年（我確實(shí)沒有實(shí)施大項目的經(jīng)驗(yàn)，沒有什么好慚愧的，也許以后會有這樣的經(jīng)驗(yàn)）的。軟件工程在這里不適用（實(shí)用）是非常明顯的。我考慮的問題根本就不是如何中規(guī)中矩地實(shí)施軟件工程或者某種軟件過程，而是如何在這個項目結(jié)束的時候還能夠幸存下來。非常幸運(yùn)的是我做過的項目客戶都真正用起來了，并且在后期的維護(hù)中我們基本上滿足了客戶對系統(tǒng)的絕大部分期望。我不知道這是不是某種成功，我只知道我現(xiàn)在仍然健在，這似乎不是一件偶然的事情，然而我居然沒有依靠任何軟件工程！
————————
PM的職責(zé)，F(xiàn)DD，UML with Color，文本形式的用例，實(shí)踐中的XP
幾個蠻關(guān)鍵有用的問題。多謝兩位前輩的精彩討論。
said by dlee：
一個合格的 PM 至少要身兼 3 個角色，對于客戶他是技術(shù)專家，幫助客戶使用技術(shù)手段解決各種業(yè)務(wù)問題。對于程序員他是業(yè)務(wù)專家，幫助程序員理解客戶的需求，與程序員一道做設(shè)計。做好各種輔助工作（建立和維護(hù)開發(fā)環(huán)境，尋找適合的開發(fā)工具），便于程序員以最高的效率完成工作。PM 其實(shí)起到的是一個業(yè)務(wù)知識與技術(shù)知識之間的橋梁作用（很多公司并沒有 PreSales 這個職位，因此 PreSales 的工作其實(shí)是由 PM 來擔(dān)任的）。同時 PM 還是一個管理者和督導(dǎo)者，要以最有效率的方式組合各種資源，合理安排進(jìn)度、計劃和目標(biāo)，按時交付具有一定質(zhì)量保證的產(chǎn)品。
from http://forum.javaeye.com/viewtopic.php?t=1407
said by dlee:
我大致看了一下，感覺這本書的內(nèi)容非常棒。而且我認(rèn)為 FDD 是比 XP 的 TDD 更適合于中國的軟件開發(fā)過程。
我讀過 XP 的教材后的想法是：別急，先等等看。
讀過 FDD 的教材后的想法是：還等什么，明天就做起來。
said by o6z:
最近經(jīng)?？吹接懻摂?shù)據(jù)建模和對象建模的問題，還看到業(yè)務(wù)建模的問題。而我覺得我們說了這么久，真的沒有color UML那么幾頁紙對我觸動大。雖然uml with color不是設(shè)計的解決方案，但是你會看到它對于需求了領(lǐng)域的把握是非常出色而令人經(jīng)驗(yàn)的。趕快學(xué)習(xí)，不要耽誤。
簡單的令人吃驚，有效的令人吃驚的東西。我實(shí)在是佩服together的創(chuàng)意，和他們邏輯嚴(yán)謹(jǐn)?shù)乃季S方式。它用4個原型概況了很多讓人迷惑的東西，用12個組件推出了經(jīng)常出現(xiàn)的一些場景模式。我想如果誰有時間，把那200頁左右的《Java Modeling in UML with Color》翻譯成中文就好了。
from http://forum.javaeye.com/viewtopic.php?t=5055
said by o6z:
我讀書還喜歡讀那些可以放下不管，沒有事情再拿起來翻的書。比如gof，你完全就可以看過前面的原則的部分，然后瀏覽一下后面的具體的東西，然后就放下，等你覺得一個地方可以使用一個什么模式，再去查，查完又放下。
其實(shí)寫用例也是如此。為什么會覺得困難，我想大概多數(shù)人總是追求一個詳細(xì)的用例說明，而忘記用例是拿來用的，而不是拿來寫的。用不到的部分就可以暫時不那么精細(xì)，等你開發(fā)到那個地方再去細(xì)化。這個也是自己練習(xí)增量迭代的一個步驟。
from http://forum.javaeye.com/viewtopic.php?t=5481
said by o6z:
本人接觸日本人的開發(fā)方式還算早。他們的V模型其實(shí)還是很好的，但是除此以外日本人的東西可以說全都是反面教材。而對于敏捷在日本的流行也比我們這里熱的多。但是我不想給大家介紹這些，因?yàn)檫@些不是問題的核心?，F(xiàn)在我們面對的不是不是5年前，以至于不是一年前?，F(xiàn)在我們面對的是變化多端的市場體系，是一種對成本核算和質(zhì)量標(biāo)準(zhǔn)要求近乎苛刻的市場。那些讓你可以溫文爾雅的按部就班的方法論，都不能讓你適應(yīng)這樣的環(huán)境。XP在我看來都不夠極端，都不能面對這樣的場景。日本人的小兒科就更加讓人覺得可笑。
現(xiàn)在我們即將面對的情況是你必然會失敗，成功只是一展偶然的運(yùn)氣。我們所能做的，也不是那些以前些年軟件工程研究的減少錯誤，優(yōu)化流程就可以讓你成功的了。我們將面對的環(huán)境要惡劣的多。在這樣的條件下生存就將按照一種另外的形式進(jìn)行，那些不能及時專橫跋扈思維方式的人面對的就只有死亡。軟件開發(fā)將從新成為一種個人英雄主義的活動，任何一種試圖依靠所謂的方法和過程學(xué)說都會被認(rèn)為是腦筋錯亂的產(chǎn)物。組織高度自管理自控制，扁平的組織成為唯一的形式。動態(tài)和高變化成為首先要考慮的，所謂的以需求為驅(qū)動的開發(fā)將被徹底的拋棄。
我不知道誰能生存在這樣的環(huán)境中，但是我知道日本人肯定不能生存。
said by dlee:
o6z 兄的話深合我心。以前軟件工程一類的書中舉的案例動輒就是數(shù)十人、上百人的團(tuán)隊，開發(fā)時間持續(xù)一年以上。但是事實(shí)上我做過的項目很少有 6 個人以上、持續(xù)時間超過半年（我確實(shí)沒有實(shí)施大項目的經(jīng)驗(yàn)，沒有什么好慚愧的，也許以后會有這樣的經(jīng)驗(yàn)）的。軟件工程在這里不適用（實(shí)用）是非常明顯的。我考慮的問題根本就不是如何中規(guī)中矩地實(shí)施軟件工程或者某種軟件過程，而是如何在這個項目結(jié)束的時候還能夠幸存下來。非常幸運(yùn)的是我做過的項目客戶都真正用起來了，并且在后期的維護(hù)中我們基本上滿足了客戶對系統(tǒng)的絕大部分期望。我不知道這是不是某種成功，我只知道我現(xiàn)在仍然健在，這似乎不是一件偶然的事情，然而我居然沒有依靠任何軟件工程！
————————
PM的職責(zé)，F(xiàn)DD，UML with Color，文本形式的用例，實(shí)踐中的XP
幾個蠻關(guān)鍵有用的問題。多謝兩位前輩的精彩討論。
浙公網(wǎng)安備 33010602011771號