敏捷開發----專案管理工具和實踐方法
原文地址：https://www.zhihu.com/question/54626462
管理工具：
1.需求管理工具
confluence 是一個基於java企業知識平臺，基本上是一個企業部落格，他有一些工作流管理功能，也支援很多外掛（如UML、思維等等），容易定製。
2.基於敏捷管理的sprint、backlog、開發task、bug管理工具
jira 是一個基於java的issue(問題、事項)管理器，類似的產品有禪道，github也有簡單的issue管理，支援很多外掛，而且可定製。
3.程式碼管理
gitlab 是一個類似於github的東西，它是採用ruby開發的，支援自己的一套智慧提交，並且非常開放，易於整合。
4.部署打包
jenkins 是一個java實現的持續整合工具，圖示是一個紳士小老頭很搞笑，在我這邊一般它會工作在觸發後執行打包指令碼，進行自動化的整合部署，完成後會發送郵件提示，通知結果。後期我這邊將它和nexus進行了整合，改變了一些使用方法，但是大致還是這樣子。雖然這個是java寫的，但是完全可以用作其他語言的持續部署，它很神奇，很省心，也很易用。
費用？
jira & confluence & 外掛
也應該看到了，我這邊用的是正版，不推薦D版，請支援正版。
官方有費用的介紹，國內有代理，可以開發票是可以比較方便走賬的，價格相對而言還是比較可觀。
最低有10人10美元授權，其實巧妙分組使用此授權可以在更多人數的團隊中使用(就是說不是一套JIRA)，但記得其實人家授權協議中是不同意這樣子做的（其實我也沒仔細看）。
對硬體的要求？
記憶體：
在實際使用中發現，jira 和 confluence 很吃記憶體，分配小記憶體使用起來效果並不好，我在內部伺服器上配置了48G記憶體，給亂七八糟的服務去使用，使用起來體驗還可以。
處理器：
對於cpu等吃的並不厲害。
硬碟：
對於硬碟 iops 相對於記憶體次要敏感，我這邊是配置了兩張 ssd 做的 raid1（mdadm做的），使用中感覺還可以。
網路：
延時還是要低些吧，你放到美國的vps上300多ms的延時估計用起來是不會開心的。
在實踐中需要應用的其他工具或產品？
linux伺服器 應該不是必須的？據說可以用windows？我沒考證過，所以寫在這裡吧。
tomcat 這是apache下的開源專案，是一個 JSP/Servlet 容器（就是跑java網站用的服務端），另外還有jboss等，但是我們用不到ejb，所以tomcat是個好選擇。
nginx web服務端，也可以作為反向代理（實際上用作反向代理比較多）
postgresql 一款學院派風格的關係型資料庫（雖然也支援nosql），效能很不錯，使用起來坑也比較少，對於一些特性他比mysql相容的好，我這邊大量在使用。這個不是必須的，用mysql，sqlserver（這個我沒試過）是可以替代的。雖然他支援nosql資料庫，但還是不要用的比較好。
雙向證書驗證 一般的https是單向的，即服務端裝證書，客戶端驗證，而雙向證書顧名思義就是雙向的，客戶端也要有，服務端會驗證客戶端的證書，沒證書，訪問不了。
我這邊吧服務都放在了公網，雖說程式碼本身是不怕同僚離職時帶走，但是考慮到其他方面這顯然不太安全，所以採用了雙向認證的方案。
在實施中吧個人證書與自建CA的根證書分發給同僚，進行安裝後即可訪問，但是沒有證書訪問頁面就會404，製造出沒有這個頁面的假象。
自建CA 因為採用了公網部署雙向證書驗證的方案，口袋裡又沒有錢都去用正規CA的證書，所以這個基本不可少。
可選技術？
docker 這個當下非常火，不必多說了。在實際使用中我嘗試過吧這幾個專案部署到docker裡，但是就體驗來說效果不好。在實際使用中主要是吧 docker 來結合 spring cloud 來使用。
nexus 一個開放的自建maven，可以代理中央伺服器，也可以上傳內部的包讓團隊成員共享與使用，做java方面的開發這個可謂是不可不用。
ss-local 這個我不展開了，畢竟你懂的。這是一個神奇的梯子工具的客戶端，我在內部伺服器（即跑這些應用的伺服器，而不是內網中的伺服器）中進行了部署，連線到東京的linode，來給nexus加速。在安裝這一堆亂七八糟的過程中使用此神器可以大大加速下載速度，如果你在國外應該用不到這個。
privoxy 一個代理伺服器，ss-local提供的是一個socks5代理，但是畢竟用socks5很多地方不方便，比如終端下並不能簡單的使用，而很多應用也只支援使用http代理，所以就用它來進行socks 到 http 的轉換。
jira git 外掛 一個可以和git庫進行整合的外掛，對雙向證書支援不好，只能在nginx給此外掛開小灶不走雙向認證。
jira gantt-charts 外掛 一個jira展示甘特圖的外掛，體驗很不錯，排版容易混亂，但並不影響使用。
confluence http://draw.io 外掛 畫圖用的，基本上常見的圖都支援，但是體驗一般，可以安裝其他外掛進行優勢互補。
jira 和 confluence 中文漢化包 顧名思義，對於像是我這種只有小學英語水平的人尤為重要。
zsh 一個神奇的shell，用他來增加終端使用git的體驗
oh-my-zsh 顧名思義，用zsh幾乎必備
如何使用這一堆亂七八糟？
至於整合與賬號建立等我會在配置安裝章節進行闡述，在此只提供一個用例。
感覺碼字好麻煩，只寫基於預設的情況下一種符合大多數情況的案例吧，供大家參考：
專案定下來後首先用 jira 建立專案，首推：
這個使用起來效果是很不錯的。另外你也可以很方便的建立自己的型別，讓他符合自己的需求，但在此不展開了。
然後進行必要的專案配置，這裡的甘特圖選項請設定好，要不甘特圖有些功能會有問題。
建立版本
然後跑到 confluence 建立庫，推薦選擇這個：
同理也可以建立自己的來用（不復雜，摸索下即可）。選好專案關聯好，並建立:
這時候一般會開個會議大家考慮下戰略、任務怎麼分配以及怎麼下手去幹，這時候建立一個會議記錄。
對會議內容進行記錄。
在參會內容中對參與人員進行'@'即可：
其他按照模板項進行填充，其中行動項請務必填寫，這個很實用。
這樣子儲存後參會人就會收到提示，如果配置了郵箱提醒還會看到郵件。
然後掃中展示的行動項，建立jira任務：
此時會看到已經關聯。
jira中也已經有了
分配好經辦人，新建一個sprint並且把任務拖進去將經辦人分配好，在此例中分配給我了我自己。如果要拆分子任務也請此時進行。
然後開始sprint，這時在甘特圖中已經可以看到了，在active sprints中也可以拖動任務了。
任務拖動到其他階段後，confluence就會更新，
大家都能看到做到哪裡以及做的怎麼樣了。
在這裡因為要求做需求，建立一個產品要求在裡面。左側 產品要求->Create product requirement 把需要的專案都填好。
問題過濾器中這裡就直接獲得所有沒結束的，實際使用中可以按需要獲得，比如獲得屬於這個需求的，等等。
我採用的是列表展示20條，這會導致排版不好看，但是實用些，如果感覺不舒服可以換形式，或者減少展現欄位。
剩下的按照模板填寫。
儲存後就會看到呼叫的問題
一個比較可用的方案是自定義模板，但是在此就不展開了，有需要可以檢視官方教程。決策日誌，和回顧等大同小異我不再贅述。
開發過程中，一定要使用jira的智慧提交，這非常好用。
在gitlab中建立版本庫，並且新增必要的README等等，另外就是配置好 Project services 整合好jira
點選 test 試試看是不是配置正確。點選issues 來試試是否能跳到展現頁面。
在gitlab裡給這個專案加入一個JIRA的新成員
去jira git 外掛中檢視webhooks 
吧webhooks給設定好（在你的jira中git外掛裡面檢視，就上面那個）
儲存測試成功了才可以。回到JIRA去更新下GIT外掛的索引
把專案克隆到本地然後測試一下智慧提交，確定ok。
為了方便演示智慧提交加上這個專案還沒README，所以就拿加入README來演示，首先在JIRA建立一個任務並且開始做這個任務。
然後我們來做這個任務（這裡你也看到我用了zsh和oh-my-zsh，其實是可以用ga gp 之類的，你也可以用用看）這裡很顯然我配置過key，沒有配置請先配置。
（平時我使用了ssh的~/.ssh/config 配置檔案來設定伺服器的，此處可以直接使用常見的git形式，不必像這裡一樣去ssh://，此處僅為演示，實際使用推薦還是採取ssh config配置檔案+遠端地址無關的形式比較好，因為這樣子換域名換埠，同僚可以不必一個一個去修改git的config，而是改一個 ssh config 即可）這時如果你在另外一個螢幕上開著JIRA的話應該已經自動移到Done裡面了（並不需要重新整理）
甘特什麼的也已經更新了，要是關注過問題的人也會收到提醒。這種神奇的效果就是剛剛那句 commit 命令，這個就叫做智慧提交，gitlab-shell會去呼叫gitlab，gitlab又去通過剛剛設定的web鉤子去拽一下jira，jira去重新整理庫（以下不再贅述執行過程，不必要的感覺），這個實際使用中體驗還是不錯的。這裡用的這個是改變當前狀態的。格式是：
git commit -m "JIRA的任務KEY #目的狀態 解釋"
如果你有多個任務可以用空格間隔重複前半部分，不需要提交多次。
對於智慧提交jira官方是有詳盡說明的，我放連線，需要的可以去慢慢研究，一般在使用中我是會弄個環境變數或者指令碼來方便提交 issue key ，畢竟有的專案會把KEY搞得很長，輸入起來並不是很方便，有的同僚是採取IDEA中設定ISSUE的方式，這些都是比較好的辦法。
Atlassian Documentation
（如果沒有設定過本地 git 的 config 請按照gitlab下面的步驟來做一下，不去設定的話會發現提交後不會關聯到對應使用者，它是按照郵箱進行的索引，所以郵箱是尤為重要的）
（另外扯一句題外話，我曾經見過一些同行，不知道程式碼潔癖還是有要求怎麼的，git提交錯了，push了，消尖了腦袋去改git的提交，莫非跟績效掛鉤？在我看來這是大可不必的，提交錯了重新提交一次即可，大可不必在這裡鑽牛角尖，要不天天改提交，哪天手抖輸敲錯了就心塞了反而麻煩。至於程式碼稽核也請不要基於提交為單位展開，要不真會逼人去改提交，而且程式碼稽核這種事最好是上下文都要看到才好，不知道上下文的話突然插進來不要談稽核，哪裡是那裡都不知道。）