大家好，我是華為DevCloud?項目管理服務的產品經理?恒少：）（https://bbs.huaweicloud.com/blogs/adf71fa5bbf811e89fc57ca23e93a89f）

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

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

<恒少出品，必妥妥干貨，必理論聯系實踐>

-----------------------干貨分割線--------------------------------------

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

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

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

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

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

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

1.如果正在使用Excel管理需求。軟件產品的需求永遠是需要管理的，而需求往往是需要分配給不同的成員去交付，并且希望跟蹤需求的進展，是不是在開發中了？是不是可以部署到現網了？因此這個場景是一個多人協作，集中呈現管理的場景，需求管理切忌你看到的和我看到的不一樣，所以不能使用本地的任何文件來管理，因為你改了，別人可能就不是最新的。因此這個時候，應該優先選擇一個云端的敏捷需求協同管理軟件、項目管理工具，不要小瞧現在業界的主流需求協同管理工，類似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中一步步走出來。

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