大家好，我是華為DevCloud 專案管理服務的產品經理 恆少：）

 作為佈道師和產品經理，出差各地接觸客戶是常態，線下和華為雲的客戶交流、佈道、技術沙龍。

 但是線下交流，覆蓋的使用者總還是少數。我希望借助線上的平臺，和使用者持續交流華為在研發效能提升上的思索和實踐。

<恆少出品，必妥妥乾貨，必理論聯絡實踐>

-----------------------乾貨分割線--------------------------------------

開篇小段子：業界有個小段子，研發不是請客吃飯，是傾家蕩產。

是的，研發人員，尤其是從事軟體的工程師門，普遍是比較傲嬌的，在軟體產品沒有賣出去形成收入前，軟體工程師的投入都是剛性成本。所以，為什麼很多軟體企業的老闆對於敏捷，DevOps其實並沒有深入瞭解，但是依然很歡迎呢，因為“快”這個詞吸引了他們，早一點把軟體交付給客戶，形成收入，才能讓他們早點給軟體工程師付工資和薪水啊。對了，軟體工程師需要的基礎設施（空調，辦公位，伺服器，計算機，雲主機，雲端儲存，各種研發工程工具）也都是很大的一塊剛性成本。交付晚了，可能真的傾家蕩產，血本無歸的。。。

 軟體工程師是寶貝，所以華為其實一直堅持，儘量讓這些傲嬌的寶貝疙瘩們，不要做一些低價值，重複性的工作，浪費錢，也浪費軟體工程師建造數字化世界的激情。^_^

我相信，沒有哪個軟體工程師希望整天整Excel表格的，因為整Excel表格其實挺無聊低效的。

如果不幸在用Excel管理軟體專案了，本文希望能提供一些方法來一步一步遷移

根據筆者的經驗，可以分場景來看看現在專業的敏捷協同管理的工具具備哪些能力，是如何替代覆蓋Excel的。 

1.如果正在使用Excel管理需求。軟體產品的需求永遠是需要管理的，而需求往往是需要分配給不同的成員去交付，並且希望跟蹤需求的進展，是不是在開發中了？是不是可以部署到現網了？因此這個場景是一個多人協作，集中呈現管理的場景，需求管理切忌你看到的和我看到的不一樣，所以不能使用本地的任何檔案來管理，因為你改了，別人可能就不是最新的。因此這個時候，應該優先選擇一個雲端的敏捷需求協同管理軟體、

a.可以像Excel那樣過濾，排序，還可以多欄位過濾，過濾條件可以儲存為常用，換任何電腦都能繼續使用；

b.需求作業流是可以流動的，可以從一個狀態換到另一個狀態，一個處理人再交給另外一個處理人，這個用Excel這樣平面表格處理起來有些麻煩；

c.需求的分解很輕鬆，快速新建子需求/子工作項，父子需求關聯，需求依賴一覽無餘，通常還預置了業界通用的需求型別（Epic/Feature/Story/Task）;

d.修改需求的狀態，分配成員，簡單勾選即可，自動聯想或搜尋，很高效；

e.還可以線上的社交評論，對需求的意見都可以公開線上討論；

f.需求的狀態變化，處理人或專案經理還可以收到站內信或郵件通知；

g.同時還可以檢視操作記錄，誰在什麼時候改了，改的啥一目瞭然。

這樣，辦公室再也聽不見“那誰誰，你最新的需求Excel給我發一下了“，因為最新的永遠在雲端，你在任何有瀏覽器的地方開啟就可以了，也包括手機。無圖無真相，以華為雲DevCloud為例，有可拖拽的需求卡片模式，還可以隨心切換列表模式。

2.如果正在使用Excel管理迭代計劃。無論敏捷迭代，還是瀑布里程碑，軟體的開發總是需要一個計劃的，給老大，投資者，客戶以期望，在這個Big  Bang的時代，軟體工程師好貴的時代，不可能讓你一個勁的放飛自我。計劃管理無非就是什麼時候交付什麼需求或解決那些問題，軟體的計劃至少得有個開始時間、結束時間和計劃交付的內容。Excel可以做的，但是每個計劃時間內的需求或缺陷，要引用其他Sheet頁，表格引用挺麻煩的，而專業的敏捷軟體，很簡單的，建立專案的迭代計劃，將需求安排到迭代計劃，很簡單就知道每個迭代計劃要交付哪些了。我使用一個華為雲DevCloud的迭代圖當例子，如下。作為曾經的Excel的掃地僧，我是真喜歡這樣的迭代計劃：）

3.如果正在使用Excel管理缺陷。軟體的不可見性和複雜性，決定了軟體缺陷是軟體生命週期管理永遠需要妥善管理和跟蹤的。<插個話，不知道AI出來後，能不能破軟體不可見性和複雜性的這個百年困局，啥時候有集中的大段時間，是可以寫寫AI對於軟體開發可能帶來的正面和負面影響>。扯回來，一般用Excel管理缺陷，就是一行行的記錄缺陷，列都是描述定義缺陷的欄位：誰發現的？什麼型別的缺陷？計劃什麼時候解決？由誰解決？缺陷當前的進展。

4.如果正在使用Excel開回顧會議之類的。記錄一些遺留問題啊，風險啊。這還是一個多人協作的場景，遺留問題總得跟蹤解決吧，Excel只有進入多人協作場景就會有些不便利，這時候，可以使用wiki這樣的多人協作，輕量級的線上文件協作，團隊成員看到的都是同一份，遺留問題的進展自己更新自己的。當然也可以使用很多敏捷協同管理軟體提供的看板，建個跟蹤任務，管理團隊的日常事務也妥妥的方便。華為雲DevCloud也提供很豐富華為實踐的Wiki模板，有了通用的模板，格式和標準就可以批量繼承重複使用了，如下圖：

5.如果正在使用Excel管理測試用例。測試用例至少需要用例名稱，編號，執行用例的責任人，前置條件/後置條件，測試步驟，測試預期結果等，而且很多時候自動化的測試用例要能快捷的生成測試執行的指令碼的，執行一個測試用例很多時候需要執行很多測試指令碼，因此通過Excel管理的測試用例除了記錄測試用例外，幾乎不具備執行的可能。所以測試管理使用Excel其實並不是適用，現在很多研發工具軟體都有專業性很強的測試用例管理，並和測試執行打通。如下圖是華為雲DevCloud提供的手工測試用例截圖，肯定還是比Excel管理起來要人性化多了

6.如果正在使用Excle管理程式碼提交。通過Excel管理程式碼提交，我最初聽到時，是非常震驚的，絕不誇張，下巴還好沒有掉。我這大半年跑了國內很多軟體企業的客戶，還真聽說有客戶就是在用Excel管理程式碼提交的，因為沒有專門的程式碼配置管理工具，開發人員也不多，就直接把程式碼合併到程式碼檔案伺服器上，因為是檔案伺服器，不知道誰提交了哪些程式碼段/程式碼行，就讓開發人員填寫Excel。毫不留情的說，我個人是非常反對這種做法的，應該儘快使用專業的程式碼配置管理工具或程式碼託管的雲服務。程式碼是軟體的核心，程式碼的關聯是嚴肅、嚴謹、嚴格、嚴苛的。任何商業化交付的軟體，都應該尊敬程式碼。別再用Excel管理的程式碼提交記錄，來嚇我了：）

寫在最後，誠然Excel依然是目前最好用的表格辦公軟體之一，但是在軟體研發這個專業的領域內，把自己花費在Excel上的時間交給更專業軟體工具，是更尊重自己這麼多年摸爬滾打的正確姿勢。

而且，時代真的在變化，現在市場上的各種專業的敏捷、DevOps的工具服務，已經在很多企業得到廣泛的應用了，如上面介紹的主要Excel場景，都已經穩穩的支援得更好了。

為了讓你的價值得到更大的發揮，可以嘗試從Excel中一步步走出來。

軟體工程師是數字世界的構建者，加油，致敬！