PTT職涯區 / Soft_Job (軟體人)

[心得]軟體專案管理導入心得

看板Soft_Job (軟體人)作者 (dorgonman)時間7年前 (2017/04/03 19:04), 7年前編輯推噓13(13推 0噓 42→)
留言55則, 17人參與, 最新討論串1/1
前段時間換工作到新公司，發現新公司內部完全沒有任何的專案管理流程。為了說服老闆導入軟體專案管理以及建立好管理體制的好處，因此寫了下面這篇文章。 雖然我的觀點不一定正確，但這篇文章是我思索了好幾天的結果。 若有任何指教，歡迎一起討論 :) 部落格版本： http://dorgon.horizon-studio.net/archives/747 =============本文開始================= 最近陸陸續續的花了一些時間導入專案軟體開發工具跟流程進到現在的公司中，我想就藉由這次的機會來描述我想像中一個軟體專案應該要有的體制。當然，這些都是基於我過去在其他公司參與遊戲開發專案所得出的結論，或許很多並不是最佳解，但我想裡面應該有一些可以參考的觀點。 基本上，我所認為一個好的軟體專案開發體制需要能解決以下這三個主要的問題： 一、工作要能夠連續，不要輕易的被打斷：尤其是當一個人才剛進入工作的狀態卻被其他的臨時事項或溝通所打斷時，要再重新進入原本的任務內容所耗費的時間與心神勞力在無形之中都是個浪費。 二、任務內容要能夠有效傳達：由於軟體開發在本質上複雜與不可見的特性，很多時候口頭上所討論的內容每個人所理解的都不盡相同。又尤其開發過程中肯定會有不少任務內容展開，而開發人員肯定是一件一件的對於這些任務進行消化。而在這期間，軟體需求的各種修改與追加其實會是一種常態，特別是對於新創公司而言，要如何讓這些任務內容有效的傳達到所有相關的參與者身上，而不是藉由開會來佔用人員寶貴的開發時間，則是一件軟體專案管理上必須要思考的議題。 三、軟體設計過程要能夠追蹤：軟體開發不同於其他產業，它很難用任何量化的指標去評估。公司的價值基本上就是圍繞在裡面成員的技能與組成，因此，要如何將開發經驗傳承下去則是每個軟體公司都會面臨到的挑戰。這點在程式人員中通常都是使用版本控制軟體(如Git)，但只有這個是遠遠不夠的。程式碼無法體現想要達成的使用者經驗以及其他各種功能面上的決策與情境，因此如何為這些東西提供一個互相參照的機制，則會直接影響到公司的體質。體質好的公司，這些開發經驗是要能有系統的累積下來的。人員若能夠藉由這個機制而能簡單且快速的存取到跟手 邊任務相關的資訊，則能夠大大的提升軟體開發與維護的效率。 其實，上面這些問題在本質上都是怎麼「溝通」。要怎麼讓這件事更有效率的被執行，其實在軟體界中有一門叫「軟體工程」的理論專門在探討相關專案管理的開發議題，從各種從上千人參與的軟體開發專案到十人以下的小團隊都有提出一些方法論來解決各種軟體開發上所會面臨到的情境。其中一套被稱作agile的方法論普遍被世界上各個開發團隊所採用，其核心思想便是藉由每天不斷的溝通、頻繁的交付版本來快速的適應需求的變化。 然而，溝通是有成本的，因為溝通需求而被中斷的開發時間意味著時間的浪費。因此在agile中的 「scrum」框架下才會有每天的站立會議的出現。藉由每天在進入工作之前跟成員間互相分享彼此在任務上的狀況與需要協助的地方，以解決當面互相溝通的需求。 當然，就如同人月神話一書中所提到：「沒有銀彈」──軟體開發並沒有一套完美的方法論可以完美的套用。各個軟體專案管理必須要根據人員的組成與專案的特質進行不同的管理流程，一切都要以如何進行有效與簡潔的溝通為基礎來進行發展。 基於上面的需求，市面上其實也已經有幾套專案軟體系統可以用來協助我們減輕成員間溝通的負擔。 其中最有名的是jira( https://www.atlassian.com/software/jira )，它是目前公認做的最好的專案軟體管理工具，只是如果要完整的使用該公司的方案的話，在價格上會有些昂貴。 再來就是redmine( http://www.redmine.org/ )，由於這套解決方案是免費的，因此在市場上佔有不小的份量。只不過我個人用過的感覺是缺乏了不少關鍵性的整合能力，而且server必須要自己架設，適合有專門資訊人員在管理的團隊。 接下來便是微軟的vsts( https://www.visualstudio.com/team-services/ )，由於其完整度還蠻高的，各種整合跟服務都很不錯，而且5人以下免費，git跟git lfs的空間無上限，因此作為startup使用的專案軟體管理工具是蠻適合的。 另外也有不少小團隊採用Trello( https://trello.com/ )，只是我覺得這套系統作為個人使用的任務管理工具雖然還蠻完美的，但當團隊成員擴張到5個人以上的時候就會開始顯得有些零亂，到10個人以上時基本上就會呈現一種無法管理的狀態。 當然，除了使用專案管理系統之外，還是會有即時溝通的需求。基本上，市面上的專案管理系統會在每天匯整當天的任務資訊並寄到你的email，但若我們在專案管理上的任何更動或任務的指派都能夠即時通知到相關人員的話，那麼團隊就能夠更敏捷的去處理各種突發狀況。 通常大部份的人想到的都會是建立一個line或Skype群組並手動的通知對方相關的任務變更，但「手動」這件事其實是一件勞心勞力的事，若能夠自動化的話該有多好？而且建立line或skype群組意味著公司需要再去尋問員工私下個人的帳號資訊，這對於一些重要資訊的控管與流程的制度化其實是不好的。 這就是為何市面上會有slack、hipchat或microsoft teams……這些群組聊天軟體出現，它們不僅僅跟專案軟體系統有一些自動化機制上的整合，更重要的是如果這們軟體是直接跟公司的email帳號綁在一起，就能夠讓員工們做到公私分離，在公事上分享相關機密資訊時就不會有太多的疑慮。 最後，根據agile的精神，我們必須要頻繁的交付版本以達到快速適合需求變更。但交付版本這件事其實是一件勞心勞力的事，若是每幾天都要繳交一個版本的話，那麼就會必須要配置一個工程師整天都在做這件事。這其實也是一種浪費，若是這件事也能夠自動化的話該有多好？ 其實所謂的持續集成(Continuous Integration)就是在處理這件事。基本上要做的事情就是一套自動化建置與佈署的流程，撰寫自動化的測試程式以確保基本的軟體質量，並在每天晚上自動執行這些自動化出版的腳本。其中這套持續集成系統最有名的是jenkins( https://jenkins.io/ )。這套流程雖然一開始的建置需要花費一些時間，但是當整個機制完成之後，團隊成員每天能夠拿到一個最新的版本以檢視其前一天的工作成果，而且最大的好處是能夠讓各種潛在的議題在軟體實作的初期就浮現出來。一個好的CI流程能夠體現軟體專案的心跳聲，若是我們能夠越早傾聽出專案中各種潛在的病症，那麼便能讓我們後期專案的開發與維護成本降至最低。 -- Sent from my Windows -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 219.70.222.43 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1491217470.A.FD6.html
→
04/03 19:23, , 1F
體制那邊講的比較偏維運角度，第三點通常是用wiki like
04/03 19:23, 1F
→
04/03 19:23, , 2F
的系統。
04/03 19:23, 2F
→
04/03 19:26, , 3F
第三點談追蹤是你說的redmine或還有bugzilla這類的，但
04/03 19:26, 3F
→
04/03 19:26, , 4F
內文指的經驗傳承是偏知識性的。
04/03 19:26, 4F
推
04/03 19:47, , 5F
第三點bbs字跑掉了
04/03 19:47, 5F
※ 編輯: dorgonman (219.70.222.43), 04/03/2017 19:56:28
→
04/03 19:57, , 6F
修好了，不太習慣bbs操作
04/03 19:57, 6F
推
04/03 20:16, , 7F
好文, 建議可多強調時程的可控性與軟體品質, 老闆只想聽這個
04/03 20:16, 7F
推
04/03 20:21, , 8F
其實最難的是要怎麼開票、誰收票、誰催票。要工程師
04/03 20:21, 8F
→
04/03 20:22, , 9F
自動去用你開的專案管理平台很難的
04/03 20:22, 9F
推
04/03 20:24, , 10F
然後PM怎麼去畫WBS時程預估給老闆也很麻煩
04/03 20:24, 10F
→
04/03 20:27, , 11F
至少現在我少了很多臨時討論事項，可以專心的寫code :)
04/03 20:27, 11F
推
04/03 20:57, , 12F
想為新公司導入軟體管理流程+1 謝分享!
04/03 20:57, 12F
→
04/03 21:50, , 13F
用了agile + Jira = 天下無敵了. 君不見delphi
04/03 21:50, 13F
→
04/03 21:50, , 14F
的bug 之多.
04/03 21:50, 14F
推
04/04 01:34, , 15F
可惜搞這麼多都比不上老闆一句：我明天就要
04/04 01:34, 15F
推
04/04 07:49, , 16F
你們寫文件嗎？
04/04 07:49, 16F
在我主推並導入vsts後，目前團隊中的成員已經慢慢的開始會用開票的方式來指派任務了 之前是每想到一個想做的東西就直接跟跑過來問我能不能做 每次寫code寫到一半一直被打斷實在很不爽
推
04/04 07:50, , 17F
通常專案管理是要整個團隊都有想法，你說服老闆沒用
04/04 07:50, 17F
→
04/04 07:51, , 18F
這是整個 team 的問題，還是你是 CTO 可以決定要怎麼做?
04/04 07:51, 18F
雖然沒有CTO這個位置，但我是第一個加入公司的軟體工程師 基本上我們是新創公司小團隊，但就是因為小，所以我現在推動這些事沒什麼阻力
→
04/04 07:52, , 19F
台灣 team 都有的毛病，當然能掌握就等於團隊整合成功
04/04 07:52, 19F
→
04/04 07:52, , 20F
講錯，多數軟體 team 都有的毛病
04/04 07:52, 20F
→
04/04 07:54, , 21F
我到每個 team 都遇到這個問題，試圖解決團隊問題，最後
04/04 07:54, 21F
→
04/04 07:55, , 22F
都失敗，如果只有你一個人再用，變成你就是小組的秘書
04/04 07:55, 22F
→
04/04 07:55, , 23F
為了某項不合理的任務，然後在那邊上下爭論
04/04 07:55, 23F
→
04/04 07:55, , 24F
最後死的都是這種積極態度的有心人
04/04 07:55, 24F
→
04/04 07:56, , 25F
出張嘴的永遠不知道自己該負的責任
04/04 07:56, 25F
→
04/04 07:56, , 26F
因為他們不懂量化時間與自己嘴砲的能量
04/04 07:56, 26F
→
04/04 07:57, , 27F
懶得學習就交給別人學習<---不曉得就透露出自己的情緒化 XD
04/04 07:57, 27F
→
04/04 07:58, , 28F
不小心
04/04 07:58, 28F
推
04/04 08:19, , 29F
樓上完全說中現在工作的窘境
04/04 08:19, 29F
→
04/04 08:24, , 30F
那種人在嘴砲出他們解決方案時完全沒經過任何考慮，隨便
04/04 08:24, 30F
→
04/04 08:24, , 31F
在網路上看一看就認為應該要這樣做，完全沒考慮合適度，
04/04 08:24, 31F
→
04/04 08:24, , 32F
最後就是嚴重拖垮進度，而且還不知道問題
04/04 08:24, 32F
※ 編輯: dorgonman (219.70.222.43), 04/04/2017 08:54:37
推
04/04 18:55, , 33F
別導假scrum開發速度就快很多了
04/04 18:55, 33F
推
04/04 21:31, , 34F
想聽一下所謂的假scrum大概有什麼樣的特徵@@
04/04 21:31, 34F
→
04/04 22:54, , 35F
就是講自已在run scrum
04/04 22:54, 35F
→
04/04 22:55, , 36F
三不五時出現"因為scrum" "scrum就是這樣" 之類的字句
04/04 22:55, 36F
→
04/04 23:07, , 37F
我覺得跑scrum不能淪為型式，如果變成罰站會議就沒有意
04/04 23:07, 37F
→
04/04 23:07, , 38F
義了。重點是有沒有真正的溝通到
04/04 23:07, 38F
→
04/04 23:30, , 39F
需要刻意導入專案管理和強調溝通的團隊 基本不會成功
04/04 23:30, 39F
→
04/05 11:32, , 40F
@manaup 當你一天到晚老闆跟pm跑來跟你說要追加什麼功
04/05 11:32, 40F
→
04/05 11:32, , 41F
能的時候，你就會多麼希望有個專案管理機制了……根本
04/05 11:32, 41F
→
04/05 11:32, , 42F
沒辦法專心寫code。現在要老闆想加什麼功能，不急的我
04/05 11:32, 42F
→
04/05 11:32, , 43F
都請他先開issue票等我有空再評估，或者是等到每天的
04/05 11:32, 43F
→
04/05 11:32, , 44F
早上的scrum meeting再提出來討論。
04/05 11:32, 44F
推
04/05 16:53, , 45F
daily scrum真的很崩潰= =每日崩潰邊緣的工程師++而且我們
04/05 16:53, 45F
→
04/05 16:53, , 46F
公司的scrum真的很浪費時間，無法準確掌握專案進程，然後
04/05 16:53, 46F
→
04/05 16:53, , 47F
兩週一個單位寫計畫…問題他們全部被前案卡，PM整個也狀況
04/05 16:53, 47F
→
04/05 16:53, , 48F
外(pm連我是f2e都有認知障礙)，我怎麼有辦法規劃兩週的工
04/05 16:53, 48F
→
04/05 16:53, , 49F
作項Orz
04/05 16:53, 49F
→
04/05 18:23, , 50F
我覺得scrum早上的站立會議是工作遇到困難時有個當面向
04/05 18:23, 50F
→
04/05 18:23, , 51F
相關人員求援的機會，而不是做進度報告用的。
04/05 18:23, 51F
→
04/05 18:26, , 52F
會議的氣氛應該是輕松的，不然久而久之大家都不想參加(
04/05 18:26, 52F
→
04/05 18:26, , 53F
除了主管跟老闆)
04/05 18:26, 53F
→
04/05 21:44, , 54F
觀念正確，求援/互補/互助/互相學習的好機會
04/05 21:44, 54F
推
04/06 20:31, , 55F
沒經驗的去拆解細分工作 無論用什麼模式都是悲劇
04/06 20:31, 55F
‣ 更多 dorgonman 的文章
文章代碼(AID): #1OuYm-_M (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 dorgonman 的文章
文章代碼(AID): #1OuYm-_M (Soft_Job)