将团队迁移到可视化项目管理软件
自2000年代中期，“Scrum”項(xiàng)目管理（PM）一直統(tǒng)治著軟件開發(fā)方法。它的迭代結(jié)構(gòu)、頻繁會議和清晰的層次結(jié)構(gòu)使其成為受頻繁變化的客戶需求和條件管制的行業(yè)的明顯選擇。因此，大多數(shù)團(tuán)隊(duì)習(xí)慣基于 Scrum項(xiàng)目管理應(yīng)用管理開發(fā)過程。?
\\但是，有新玩家——可視化項(xiàng)目管理軟件進(jìn)入該領(lǐng)域，盡管沒有那么普及但是帶來很多功能。可視化項(xiàng)目管理是精益生產(chǎn)的現(xiàn)代表現(xiàn)，是早期 Kanban工具，盡管它不等同于兩者中的任何一個(gè)。不像人工方法，可視化項(xiàng)目管理軟件從多個(gè)方法中吸收元素，以便自動化和簡化現(xiàn)有工作流程。打包成虛擬系統(tǒng)，同時(shí)提供實(shí)時(shí)更新、自定義訪問控制、數(shù)據(jù)分析等等相對應(yīng)的優(yōu)勢。
\\對采用可視化項(xiàng)目管理感興趣的團(tuán)隊(duì) Leader往往欣賞其價(jià)值，但是不能確定如何克服遷移帶來的挑戰(zhàn)。本文將為團(tuán)隊(duì)平滑過渡和最大化新系統(tǒng)價(jià)值羅列最佳實(shí)踐。
\\它如何不同于 Scrum
\\隨著 Scrum的發(fā)展，團(tuán)隊(duì)成員在 Sprint階段往往真正以筒倉的形式開發(fā)項(xiàng)目。他們在 Sprint結(jié)束時(shí)或者每日站立會議中協(xié)作、分享進(jìn)度，這需要每天抽出時(shí)間。通過實(shí)時(shí)進(jìn)度的使用和任務(wù)可視化，可視化項(xiàng)目管理為整個(gè) Sprint提供徹底的透明度。雖然這不能徹底消除對專用會議的需求，但是將會減少多余或者不必要的會議——那些僅僅用于讓人們“了解最新情況”的會議。
\\同樣可視化項(xiàng)目管理不太強(qiáng)調(diào)完成可交付的產(chǎn)品增量，更強(qiáng)調(diào)在時(shí)間盒內(nèi)工作在一個(gè)合理生產(chǎn)力水平。這意味著單個(gè)故事質(zhì)量重于絕對進(jìn)度。許多時(shí)候，可視化項(xiàng)目管理軟件甚至?xí)拗颇扯螘r(shí)間特定團(tuán)隊(duì)成員擁有的在制品（WIP）的數(shù)量（這能在許多基于? Kanban的系統(tǒng)中發(fā)現(xiàn)，他們用“卡片”移動單個(gè)任務(wù)通過可復(fù)用的工作流程）。重要的是，每次 Sprint生產(chǎn)出可工作的 Backlog項(xiàng)目，但這并不意味著數(shù)量勝過質(zhì)量；團(tuán)隊(duì)成員應(yīng)該能夠以最佳生產(chǎn)力工作，給予每個(gè) Backlog項(xiàng)應(yīng)有的時(shí)間和關(guān)注度。
\\為什么一些開發(fā)人員不喜歡
\\可視化項(xiàng)目管理其根源在于“精益生產(chǎn)”—— Toyota開發(fā)的管理系統(tǒng)，廣泛用在制造業(yè)，用于減少浪費(fèi)。鑒于流水作業(yè)線制造業(yè)跟軟件開發(fā)行業(yè)之間的細(xì)微差別和復(fù)雜性，兩者之間的隱式并行令很多開發(fā)人員感到厭惡。并且這是事實(shí)：強(qiáng)迫一些變化無常的事情比如軟件開發(fā)，使用嚴(yán)格的模型不會生產(chǎn)出積極的成果。
\\過分簡單化的 Kanban平臺往往是單維度的，不能提供開發(fā)團(tuán)隊(duì)需要的復(fù)雜度，從而保持對用戶體驗(yàn)、應(yīng)用、產(chǎn)品測試結(jié)果和不斷重新定義商業(yè)價(jià)值的市場的響應(yīng)。
\\這些肯定是有效關(guān)注點(diǎn)，但重要的是，需要注意并非所有可視化項(xiàng)目管理應(yīng)用都受限于基本 Kanban。許多已經(jīng)證明在軟件行業(yè)（比如 Atlassian JIRA、Microsoft Visual Studio和 Axosoft）有用的可視化工具，在開發(fā)團(tuán)隊(duì)習(xí)慣使用的 Scrum的基礎(chǔ)上，結(jié)合了 Kanban和精益生產(chǎn)最好的方面，這也是一些用戶稱它們?yōu)椤癝crum-ban”的原因。這些混合的項(xiàng)目管理系統(tǒng)結(jié)合強(qiáng)大的可視化工具給團(tuán)隊(duì)提供了 Backlog、特性測試、代碼庫和用戶故事的全面控制，和從一個(gè)集中、響應(yīng)式的接口工作的能力。?
\\但是即使你熱衷可視化項(xiàng)目管理理論，實(shí)施一個(gè)新系統(tǒng)可能看上去令人生畏。需要完成授權(quán)、數(shù)據(jù)傳輸和集成，更別說培訓(xùn)你的團(tuán)隊(duì)適應(yīng)新的工作管理風(fēng)格。這不是在公園散步，但是如果有一個(gè)可靠的策略，切換到可視化項(xiàng)目管理就不會妨礙團(tuán)隊(duì)的生產(chǎn)力。
\\這里有六個(gè)技巧可以實(shí)現(xiàn)無縫和無痛過渡。
\\案例研究
\\很多組織已經(jīng)在使用可視化項(xiàng)目管理工具，以改善他們的團(tuán)隊(duì)工作流程和提高品質(zhì)和吞吐量的質(zhì)量。下面是最新的案例：
\\西門子醫(yī)療服務(wù)
\\西門子醫(yī)療服務(wù)是全球企業(yè)醫(yī)療保健 IT解決方案的供應(yīng)商，包括軟件開發(fā)、安裝、托管、集成和為醫(yī)院跟較大型聯(lián)合執(zhí)業(yè)團(tuán)體（group practice）的外包服務(wù)。他們的開發(fā)運(yùn)營集中在賓夕法尼亞州，橫跨約50個(gè)團(tuán)隊(duì)，同時(shí)在印度和歐洲也有資產(chǎn)。
\\2005年，西門子 HS開始使用 Scrum和極限編程框架來實(shí)現(xiàn)自己的目標(biāo)，包括 Scrum團(tuán)隊(duì)、Sprint、評審、回顧和一套成熟的 Backlog流程。他們把敏捷/Scrum作為主要的項(xiàng)目管理工具，經(jīng)過六年的使用后，在沒有巨大加班壓力的前提下，他們?nèi)匀粫龅桨l(fā)布截止日期的麻煩。
\\西門子敏捷開發(fā)負(fù)責(zé)人 Bennet Vallet說，他們決定在工作流程中引入 Kanban技術(shù)以解決這些挑戰(zhàn)。“雖然常規(guī) Scrum/XP提供了很多優(yōu)秀實(shí)踐，西門子仍然在有能力實(shí)現(xiàn)可預(yù)測成果方面面臨關(guān)鍵差距，運(yùn)行效率中持續(xù)改進(jìn)的勢頭和質(zhì)量步履蹣跚，”他去年二月寫道，“再者，基于相對故事點(diǎn)數(shù)的度量指標(biāo)和速度圖不能為該規(guī)模的版本開發(fā)管理提供足夠的洞察力。”
\\他們在轉(zhuǎn)型中賭上了一切，在跨團(tuán)隊(duì)和時(shí)區(qū)并在項(xiàng)目管理層面部署了 Kanban。
\\西門子團(tuán)隊(duì)確實(shí)可以在 Sprint期間利用一些溫和的可視化工作，比如速度圖和燃盡圖，但是他們發(fā)現(xiàn)由于故事類型的不同，這些工具給出的都是不準(zhǔn)確的讀取。另一方面 Kanban通過專注持續(xù)流和在制品，帶來了可預(yù)測性和“整個(gè)價(jià)值流系統(tǒng)性問題和模式的洞見。”
\\Vallet發(fā)現(xiàn) Kanban有助于他們更好地具體化持續(xù)改進(jìn)心態(tài)，通過限制在制品滿足發(fā)布截止日期，并促進(jìn)協(xié)作環(huán)境的建立。即使是他們的海外團(tuán)隊(duì)在 Sprint期間也感受到了更高的參與度和緊跟步伐。他們的周期時(shí)間降至43天或者更少——提高了40%——并保持在一個(gè)可預(yù)測的范圍內(nèi)。
\\Vallet告訴 InfoQ在第一年中他的團(tuán)隊(duì)成果是如此的正面以至于他說服領(lǐng)導(dǎo)將所有產(chǎn)品線遷移至可視化項(xiàng)目管理，這會影響三個(gè)不同大陸的40個(gè)團(tuán)隊(duì)。
\\重要的是要注意西門子實(shí)施的是 Kanban的混合和更多傳統(tǒng)敏捷技術(shù)，比如增量故事開發(fā)，頻繁測試，持續(xù)集成（CI），和跨職能 Scrum團(tuán)隊(duì)以實(shí)現(xiàn)其積極的成果。盡管備受詬病，“制造業(yè)”心態(tài)有時(shí)已經(jīng)融入到軟件開發(fā)中，西門子 HS的一個(gè)重大發(fā)現(xiàn)是：流程改進(jìn)需要可預(yù)測性。
\\BBC全球
\\這一里程碑式的2009年的研究是由9人團(tuán)隊(duì)完成的，在 BBC全球內(nèi)12個(gè)月內(nèi)審查精益生產(chǎn)和 Kanban對軟件開發(fā)流程的影響。該研究由 IEEE工程管理贊助，由 Peter Middleton和 David Joyce指揮。Peter Middleton是 Lean Software Strategies的作者，David Joyce是 ThoughtWorks的首席顧問和系統(tǒng)思考家。
\\BBC團(tuán)隊(duì)——從歷史上來講習(xí)慣敏捷/Scrum開發(fā)——從使用兩個(gè)中央 Kanban板和四個(gè)“信息輻射器”開始，這些都是開發(fā)團(tuán)隊(duì)進(jìn)度的大型可視化顯示工具。團(tuán)隊(duì)被指揮在這些板上記錄所有進(jìn)行中的故事，并不再從事任何未記錄的任務(wù)。
\\跟西門子團(tuán)隊(duì)類似，BBC全球團(tuán)隊(duì)開始注意到從基于推的時(shí)間盒方法向新方法轉(zhuǎn)變是緩慢的，在新方法中只要生產(chǎn)力允許他們就會挑選 新的工作——換句話說就是限制在制品。Joyce和 Middleton注意到周期時(shí)間更加一致，和更好的實(shí)現(xiàn)持續(xù)改進(jìn)的能力，因此他們認(rèn)為新可視化項(xiàng)目管理框架是成功的。
\\可測量的成果：
\\- 交付時(shí)間提升37%\\t
- 交付的一致性上漲47%\\t
- 客戶報(bào)告的缺陷下降24%\
與之前 Scrum-only方法（回顧僅僅提供不確定的項(xiàng)目交付的總結(jié)）相比，BBC團(tuán)隊(duì)實(shí)現(xiàn)了傳說中的“持續(xù)改進(jìn)（Kaizen）”天堂。
\\盡管不是對每個(gè)團(tuán)隊(duì)而言，但是可視化項(xiàng)目管理工具可以提供開發(fā)生命周期內(nèi)更大的靈活性和通過更智能的任務(wù)分配提高整個(gè)產(chǎn)品的品質(zhì)。成功的遷移并不需要工作流程和業(yè)務(wù)優(yōu)先級的全面檢修——只有仔細(xì)、有意識的策略和自發(fā)的意愿才能收獲回報(bào)。?
\\關(guān)于作者
\\Aleksandr Peterson是 TechnologyAdvice的技術(shù)分析師。他涉及 gamifiction、CRM、項(xiàng)目管理和其它新興業(yè)務(wù)技術(shù)。你可以在 LinkedIn上聯(lián)系他。
\\\\查看英文原文：Migrating Your Team to Visual Project Management Software
總結(jié)
以上是生活随笔為你收集整理的将团队迁移到可视化项目管理软件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 长字串与短字串
- 下一篇： Eclipse简单字体设置