打造Worktile敏捷開(kāi)發(fā)管理工具的思與惑

作者：Terry

從2019年初，我們團(tuán)隊(duì)準(zhǔn)備開(kāi)發(fā)一款適合研發(fā)團(tuán)隊(duì)使用的敏捷開(kāi)發(fā)管理工具，那時(shí)候我們也在思考，到底什么樣的工具才算是優(yōu)秀的研發(fā)管理工具，研發(fā)管理的場(chǎng)景、方法和流派有很多，市面上關(guān)于研發(fā)管理工具的產(chǎn)品也是層出不窮，我們從哪里入手才能真正幫助研發(fā)團(tuán)隊(duì)提高研發(fā)效能?基于以下兩點(diǎn)考慮，我們選擇了從敏捷開(kāi)發(fā)管理進(jìn)入：

1. 敏捷開(kāi)發(fā)自1999年以來(lái)，經(jīng)過(guò)20多年的發(fā)展，已經(jīng)被大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)所接受，近幾年DevOps的流行，更是把敏捷推向了更高的位置，國(guó)內(nèi)太多的團(tuán)隊(duì)需要做敏捷轉(zhuǎn)型。

2. 敏捷開(kāi)發(fā)在中國(guó)落地的專業(yè)度還不夠，以至于出現(xiàn)了“中華田園敏捷”的說(shuō)法，中國(guó)的開(kāi)發(fā)者需要一款簡(jiǎn)單易上手的、專業(yè)的敏捷開(kāi)發(fā)管理工具，來(lái)幫助他們?cè)趫F(tuán)隊(duì)中更好的落地敏捷。雖然只靠一款敏捷開(kāi)發(fā)工具并不能幫助企業(yè)在敏捷轉(zhuǎn)型中成功，但好的工具卻能讓企業(yè)敏捷轉(zhuǎn)型事半功倍。

專業(yè)的Scrum流程管理

在Scrum Guide中已經(jīng)對(duì)于Scrum過(guò)程中的活動(dòng)、事件、產(chǎn)出等定義的非常清晰，這里不再重復(fù)，只想重點(diǎn)解釋一下在落地Scrum過(guò)程中經(jīng)常被忽視的兩個(gè)問(wèn)題。

1. 絕大部分團(tuán)隊(duì)在實(shí)施Scrum過(guò)程中只重視迭代管理，不重視版本管理，當(dāng)然這已經(jīng)超出了Scrum本身的范疇，但是好的研發(fā)管理中應(yīng)該是迭代管理和版本管理并存，他們之間是一個(gè)互相依賴的關(guān)系。

迭代管理是針對(duì)Scrum團(tuán)隊(duì)的，它定義的是一個(gè)時(shí)間盒的概念，用于團(tuán)隊(duì)容量管理和進(jìn)度管理，對(duì)于不同的團(tuán)隊(duì)來(lái)說(shuō)，明確在一個(gè)迭代的時(shí)間盒內(nèi)的產(chǎn)出，這個(gè)產(chǎn)出最終以迭代Review為標(biāo)準(zhǔn)，通過(guò)了Review并不意味著一定發(fā)布出去。

版本管理是針對(duì)產(chǎn)品的，它定義的是一個(gè)批量的概念，用于版本進(jìn)度管理和交付風(fēng)險(xiǎn)管理，明確在一個(gè)版本中最終的交付物。目前市面上大部分敏捷開(kāi)發(fā)管理工具，都能夠很好的支持迭代管理，卻忽視了版本管理。

圖1 Worktile Agile中的版本管理

2. 在Scrum Guid中定義一個(gè)迭代中的四個(gè)活動(dòng)，即迭代計(jì)劃會(huì)議、每日立會(huì)、迭代評(píng)審會(huì)和迭代回顧會(huì)，我們發(fā)現(xiàn)在大部分敏捷團(tuán)隊(duì)中其實(shí)只有前三個(gè)活動(dòng)，而自動(dòng)忽略迭代回顧會(huì)議，恰恰相反，迭代回顧會(huì)是Scrum迭代實(shí)踐中的最后一環(huán)，也是最重要的一環(huán)，迭代回顧會(huì)將整個(gè)迭代形成了閉環(huán)。Scrum小組都是自組織的，只有通過(guò)迭代回顧會(huì)不斷的總結(jié)問(wèn)題，提出改進(jìn)項(xiàng)，才能幫助團(tuán)隊(duì)不斷精進(jìn)。

圖2 Worktile Agile中的迭代回顧面板

什么才是真正的Kanban

Kanban理論已經(jīng)存在了很長(zhǎng)的時(shí)間，其適用范圍也從最初的車間管理，到現(xiàn)在的硬件制造、軟件開(kāi)發(fā)。在軟件開(kāi)發(fā)領(lǐng)域內(nèi)，很多團(tuán)隊(duì)都在使用Kanban管理自己的團(tuán)隊(duì)，有的使用電子看板，有的使用物理看板。Worktile團(tuán)隊(duì)在做電子看板上已經(jīng)有了7年的經(jīng)驗(yàn)，一直以來(lái)我們也在探索，到底什么樣的看板才是真正的Kanban。在我看來(lái)，一個(gè)真正意義上的電子看板系統(tǒng)，要能夠幫助團(tuán)隊(duì)達(dá)到以下三點(diǎn)：

幫助團(tuán)隊(duì)可視化整個(gè)鏈條的價(jià)值流動(dòng)

幫助團(tuán)隊(duì)識(shí)別價(jià)值流動(dòng)中的風(fēng)險(xiǎn)點(diǎn)

幫助團(tuán)隊(duì)度量?jī)r(jià)值流動(dòng)中的各種浪費(fèi)，并加以消除

基于以上考慮，在一個(gè)可視化的電子看板系統(tǒng)中，至少要具備以下一些能力：

能夠清晰定義在制品WIP

能夠清晰定義在制品限制WIP Limit

明確定義DoD

支持多泳道分割

在制品流轉(zhuǎn)中某些操作自動(dòng)化

達(dá)到某些風(fēng)險(xiǎn)點(diǎn)時(shí)，在制品能夠高亮顯示

圖3 Worktile Agile中的Kanban管理

需求管理如何做

不管是采用哪種敏捷方法實(shí)踐，需求管理都是敏捷開(kāi)發(fā)中非常重要的一環(huán)。Scrum中定義了兩個(gè)重要的概念：產(chǎn)品待辦事項(xiàng)Product Backlog和迭代待辦事項(xiàng)Sprint Backlog;Kanban中一般采用在制品WIP的概念。

在Worktile Agile中，我們決定采用業(yè)界大家共識(shí)的三級(jí)需求管理體系，這種表示方式并沒(méi)有一個(gè)真正意義上的標(biāo)準(zhǔn)：

Epic：史詩(shī)，表示比較大的特性，開(kāi)發(fā)周期一般是1-3月，用于產(chǎn)品路線圖的規(guī)劃

Feature：特性，表示相對(duì)小一些的特性，開(kāi)發(fā)周期一般是1-3周，用于產(chǎn)品版本的規(guī)劃

User Story：用戶故事，最小的開(kāi)發(fā)粒度，開(kāi)發(fā)周期一般是1-3天，在Scrum中用User Story來(lái)作為Backlog，在Kanban中可以用User Story作為WIP。

圖4 Worktile Agile中的Epic、Feature、User Story三級(jí)需求管理

聯(lián)動(dòng)起來(lái)才有價(jià)值

在研發(fā)場(chǎng)景下，對(duì)于團(tuán)隊(duì)成員來(lái)說(shuō)經(jīng)常整理需求/缺陷是個(gè)常態(tài)，另外在基于單個(gè)工作項(xiàng)溝通時(shí)，往往會(huì)提及另一個(gè)工作項(xiàng)，作為高效的研發(fā)管理工具，要能夠清晰的定義工作項(xiàng)之間各種可能的關(guān)系。Worktile Agile中我們定義了超過(guò)10種工作項(xiàng)之間的關(guān)系：

parent：定義工作項(xiàng)之間的父子關(guān)系

duplicates：表示兩個(gè)工作項(xiàng)之間的重復(fù)關(guān)系

blocks：表示兩個(gè)工作項(xiàng)之間的阻塞關(guān)系

其他的如mention、clone、causes關(guān)系等

只能夠定義關(guān)系還不夠，Worktile Agile還做到了在發(fā)生某些操作的情況下，自動(dòng)生成他們之間的關(guān)系，如果團(tuán)隊(duì)成員在某個(gè)工作項(xiàng)評(píng)論中提到了另外一個(gè)工作項(xiàng)，則會(huì)在他們之間自動(dòng)建立一條mention關(guān)系。

圖5 Worktile Agile中定義工作項(xiàng)之間的關(guān)系

工程化不可或缺

在研發(fā)管理過(guò)程中，項(xiàng)目管理是很重要的一塊，但項(xiàng)目管理本身并不會(huì)關(guān)注工程化的過(guò)程，在我看來(lái)，項(xiàng)目管理和工程化實(shí)踐是確保研發(fā)順利的兩個(gè)支柱，缺少哪一個(gè)都會(huì)造成不可預(yù)知的影響，把工程化數(shù)據(jù)與管理過(guò)程結(jié)合起來(lái)，將會(huì)極大的減小管理成本，提升研發(fā)效率。

工程化的過(guò)程環(huán)節(jié)眾多，涉及到的工具數(shù)量龐大，如代碼托管、單元測(cè)試、代碼掃描、流水線、打包、制品、部署等等，在Worktile Agile中可以通過(guò)REST API的方式，把工程化數(shù)據(jù)發(fā)送到工作項(xiàng)上面并與之關(guān)聯(lián)，這樣對(duì)于開(kāi)發(fā)人員可以清晰的看到每一次提交涉及到的工作項(xiàng)是哪個(gè)，觸發(fā)了哪些構(gòu)建，構(gòu)建的結(jié)果如何，以及當(dāng)前工作項(xiàng)部署在了哪些個(gè)環(huán)境。(注：REST API正在內(nèi)測(cè)中，目前還未對(duì)外正式發(fā)布。)

圖6 Worktile Agile中接入DevOps數(shù)據(jù)

讓一切皆可測(cè)試

在User Story的INVEST原則中，明確表示一個(gè)好的用戶故事要必須是可測(cè)試的Testable。敏捷開(kāi)發(fā)過(guò)程本身是頻繁迭代、周期性強(qiáng)并且能夠及時(shí)、持續(xù)地響應(yīng)客戶的反饋，如何正確建立測(cè)試策略，確認(rèn)客戶的需求能得以實(shí)現(xiàn)并且確保及時(shí)的交付最終產(chǎn)品是值得思考的一件事。

在Worktile Testhub中，測(cè)試人員可以輕松編寫(xiě)測(cè)試用例并且制定相應(yīng)的測(cè)試計(jì)劃，同時(shí)每個(gè)測(cè)試用例也可以用Worktile Agile中的User Story關(guān)聯(lián)，讓開(kāi)發(fā)人員和產(chǎn)品經(jīng)理知道這個(gè)User Story會(huì)如何測(cè)試，同時(shí)測(cè)試的結(jié)果也會(huì)及時(shí)的與Worktile Agile同步。

圖7 Worktile Testhub自動(dòng)生成的測(cè)試報(bào)告

關(guān)于未來(lái)的一點(diǎn)想法

最后，簡(jiǎn)單的談?wù)剬?duì)于未來(lái)的一些想法。對(duì)于當(dāng)下來(lái)說(shuō)最重要的事情把現(xiàn)有的產(chǎn)品進(jìn)一步打磨好，關(guān)于未來(lái)我們也在探索以下幾個(gè)可能的思路：

1. 簡(jiǎn)化手工操作，未來(lái)一定是智能的世界，在研發(fā)管理工具中，要盡可能的簡(jiǎn)化手工操作，讓工作自動(dòng)化起來(lái)，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)更是如此，他們寧可編寫(xiě)一段自動(dòng)化腳本，也不愿一遍一遍的執(zhí)行重復(fù)性的操作。

2. 擴(kuò)大人員覆蓋，目前Worktile研發(fā)產(chǎn)品矩陣已經(jīng)覆蓋了需求人員、產(chǎn)品、設(shè)計(jì)、研發(fā)和測(cè)試等人員，未來(lái)我們還會(huì)進(jìn)一步加大人員的覆蓋面，讓更多的團(tuán)隊(duì)角色可以在Worktile中完成他們的工作，比如對(duì)于中高層管理人員、PMO等。

3. 擴(kuò)大場(chǎng)景覆蓋，當(dāng)下我們的關(guān)注點(diǎn)在于如何做好敏捷項(xiàng)目管理和測(cè)試管理這兩個(gè)場(chǎng)景上，未來(lái)不排除還會(huì)延伸到別的場(chǎng)景，比如多項(xiàng)目組合管理等。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。