一、使用敏捷開發

敏捷開發,這是現在非常時興的一個詞,聽起來挺牛的,敏捷,讓我們感覺用了它就會“快”。在被這種開發模式折磨了一年多的我想說,其實它跟其他所有的事情都一樣,它有自己適用的領域,假如錯誤的以爲任何專案用敏捷開發都能敏捷,那就是自找苦吃。

爲什麽?敏捷開發的特點就是根據用戶的需求迭代,一個迭代解决一個迭代的問題,對於一個對於架構清晰的專案來說,這樣每一個迭代都會有一些成果。而對於有些專案而言,比如說殺毒軟體,磁盤分析器等等,對於這種産品類的專案,很多時候它的需求都是一開始需要定義清楚的,客戶名義上是廣大的PC用戶,實際上是PM或是PGM,PM說這個專案裏面我們要做3個功能,那我們就需要做3個功能,多一個不行,少一個也不行,如果PGM在你做了3個功能後告訴你,要加一個功能,而且這個功能在舊的架構上是很難實現的,那麽這個PGM就是不合格的,爲什麽?因爲他加大了專案的成本。

所以,我想說的是,如果需求是由我們自己定義,而且我們很清楚要做一個什麽東西的時候了,采用敏捷開發的風險可能會加大,因爲它過多的依賴於“迭代”,認爲迭代可以解决大多數的問題,可是實際情况遠不如此樂觀!當你的PM對你我們要加這個新功能,之前的定義的功能不行這個迭代要改的時候,作爲一個程序員,我們能做什麽呢?去跟PM說,對不起,我們之前的底層架構不支持這種變態的需求,PM會告訴你,我就是代表客戶,這個功能就得這麽做,我說了算,爲什麽不支持,我們不是採用的敏捷開發嗎,敏捷開發的特點不是迭代來解决問題嗎?

PMA

老實說,瀑布模型的好處之一,就是你的PM可以少幾個變需求的理由,PM一個星期變一次需求,我們程序員就沒有幸福可言了,所以,我想勸有些專案經理,別拿需求的變更當做理所應當的,你不是一個嬌生慣養的小孩,沒有必要變的需求就不要變,如果你把敏捷開發的需求變更當做是你隔三差五變需求的理由,那下個專案,當你的程序員聽說你要用敏捷開發,肯定想抱頭痛哭。你是産品的設計師,這個産品的外觀功能,應該一開始就定義好,不要前一個月說要做個電飯煲,這個月又說要在電飯煲加個微波爐的功能,如果你手下的程序員任勞任怨,把微波爐的功能真的加進了電飯煲,那只能說PM幸運,碰到了技術牛人,並且技術確實是可行的,但是如果功能實現不了,那麽PM可能就怪開發者,覺得他們技術不行,心想我用的是敏捷開發,爲什麽我給了你們時間缺不能解决問題呢?

時間確實是可以解决問題,但是作爲開發者更希望把時間多花在需求分析階段,而不是修改舊的代碼上。開發模型只是一種工具,依賴敏捷開發這個工具,並不是解决所有問題的萬金油。

作爲專案經理,你不光要對客戶負責,更需要對産品負責,對你手下的程序員負責。其實,假如做不到後面兩點第一點也不好做到,因爲專案很可能經常delay,到最後客戶不滿意,或者産品上綫的時候早已經落於市場上其他的産品。

PMA1

二、角色分配

角色分配的問題在整個軟件開發過程也是很重要的,說簡單點就是分工要明確,按照博弈論的觀點,假如我們每個人的目標都是合理的,那麽我們通過相互的制約很好的推進專案的周期,但是如果角色分配的不合理,比如說職責重複,缺少角色等等,那麽開發的過程中就會遇到很多利益衝突,解决不好,就容易導致團隊不和諧,沒有凝聚力等等,最嚴重的情况就是大家各自爲政,都聽不進別人的意見,大家都是會爲別人著想的人,但是有時候想得太多,總是會覺得不合理,不公平,難免影響工作情緒。

在我現在這個專案就有類似的問題,首先,就是沒有一個架構設計人員,經驗豐富的開發和經驗較淺的開發做的事情是差不多的,整體架構的設計名義上是大家一起來做,但是在開發過程中就發現了問題,對於一個架構變動,沒有人有决策能力,TM只會說,有問題跟我說,然後你發現了問題告訴他,他却不知道和誰來商量,經過和一個個的開發者進行了討論,認爲這個架構的變更確實是必須並且可行的時候又要開一次會,來討論怎麽來做這個變更,由誰來負責這個變更,所以說,SD是必須的。而在一次會議上我聽別人說做SD必須要有10年的經驗,我覺得有點可笑,有很多優秀的開發在很早就做上了架構師,我認識的人裡面就有一個,其實我覺得邏輯思維能力較强,有整體架構思想,並且對專案中使用技術有一定研究就可以做SD了,倒是我不明白現在爲什麽很多軟件公司都特別在乎工作年限,認爲做了10年IT就是萬金油了,什麽事情都可以解决,真是大錯特錯。

ˋ

我認爲,做什麽事情都有一個精與不精的區別,假如那句什麽語言不重要,重要的是思想,一通百通的話我覺得真是沒什麽意義。我們都知道C和JAVA.NET的側重點不一樣,一個偏向底層,一個偏向應用,讓一個做C做了10的人去做一個網站可能都做不好,爲什麽?因爲他沒有對網站應用根本就不瞭解,用戶需要什麽他都不知道,他腦袋想的只是如何使用戶體驗更加的絢,但是卻不知道網頁上能不能實現這個效果,網頁上上傳做個進度條能不能實現,實現的難度大不大,他都不知道,這樣的架構師能做好網站嗎。同樣讓NET程序員去做JAVA的事情也不一定做的好。聞道有先後,術業有專攻,這句話是有道理滴。

PMA3

角色分配的問題還體現在我們不能越庖代厨,如果你是RD,你就不要過多的去擺弄需求,覺得需求不該這麽做,因爲這個問題不該你想,想這個問題只是浪費時間,如果你是PM,你就不要過問架構和技術細節,因爲你始終不如開發瞭解實際的問題,如果你是一個做了十幾年開發的PM,自己手下的技術不如自己,硬要按照自己的想法去做事,那麽不要做PM,你可以做個SD。我以前就碰到過這樣一個PM,讓我去做一個圖片處理的程序,他想讓我把一張圖變清晰,我覺得一張從100K壓縮成了10K的圖你還想讓他變清晰仿佛是不可能的事情,用脚趾頭想問題也知道那丟的90K是幹什麽的,PM要我多測試幾次,經過測試確實是不可行的,但是PM不相信,因爲他做了一年多的開發,於是中午不吃飯跑到我的機器上寫代碼,口中還念念有詞的,等我吃完飯睡好午覺,他終於認輸了,雖然如此,但是從這件事上我就覺得有點不痛快,多的就不想說了。

 

文章截錄:中國項目管理者聯盟

圖片來源:1 2 3

 

ProjectClub 專案俱樂部為一群專案經理人組成的平台,網站分享專案運作的各種專案管理手法與實用專案工具,並分享如何提昇職場人的軟技巧與硬實力。

comments
標籤:

登入

會員消息

🔵免費註冊會員可以換範本!

🔵舊生耍特權~任三堂可免費複訓一堂!

🔵怎麼註冊?怎麼輸入點數序號?

🔵忘記密碼嗎??快點來信

🔵找文章請善用搜尋功能!

🔵每天登入就有一點!!!

🔵FB註冊的朋友,帳號是你的FB姓名

🔵搶點數!

🔵範本軍火庫