敏捷方法的成功密技(四):Scrum 的理想與現實的障礙



    在上一篇文章《敏捷方法的成功密技(三):Scrum如何擺脫「產品客戶不愛,團隊熱情不再」的窘境?》中,我們談到了Scrum架構可以協助「部份」解決溝通斷層的問題。若是想徹底一點改善溝通斷層的問題,則還需要把在更前端「產品定義階段的相關活動」也都納入Scrum的架構內來運作才行。

    除了流程架構這個「外功」,還有一個更為重要的「內功」,那就是團隊成員的組成。不僅團隊成員的能力要夠多元,多元到團隊能夠獨立交付出產品或服務,團隊成員間的互動也需要緊密融合為一體。唯有具備這樣的「內功」,然後搭配Scrum的流程架構這個「外功」,團隊所建立的產品,才能最忠實地貼近客戶/用戶的需要,為客戶/用戶解決問題,並同時也為組織創造最大的價值。

    接下來,我們就來看一下內外功該怎麼來融合運作。

    理想:讓實作者直接面對客戶

    請想像一下,如果「實際動手實作」出產品或功能的各類開發人員,包括研發、測試、架構師等,都可以直接和客戶/用戶「面對面」地對談討論需求,不清楚對方意思的時候,就在白板上塗鴉畫圖,然後大家看著圖,比手畫腳地說明彼此的想法,這裡補充一點,那邊改掉一點,漸漸地,你會發現到,白板上的圖跟最早的原始圖差異開始愈來愈大,也許一半以上都被翻盤掉了!這到底是好事還是壞事?

    最後,因為時間的限制,在場的人一定都會同意,白板上的圖和補充的資料,即便不是「最完美」的解決方案,卻也已經是個「足夠好」的解決方案。然後,這張白板圖被翻拍成照片,做為會議紀錄的一部份,寄發給所有的與會者(當然還可同時知會其他相關人員),並再次限時確認一次。

    這樣的在需求「提出者」與需求「實做者」之間「直接溝通互動」所形成的「共識」,您覺得還有可能會被實作者誤解、做錯,最後導致客戶不同意驗收嗎?我想大家應該都會同意,這樣的機率應該是微乎其微了吧!不過,事情真有這麼簡單美好嗎?

    現實:人性的障礙

    要讓上述的溝通模式能夠被落實,還需要解決「人」的「意願」和「能力」!我們就來看看,有哪些障礙需要先被突破。

    首先是客戶的態度。客戶出錢將專案發包給你的公司,為什麼還得常常花費大量時間(甚至可能會超過50%的工時都得花在這個專案上)來陪你討論需求、釐清需求、甚至是設計方案?很多客戶(應該說窗口)並不想花這樣的effort,可是卻期望只透過幾次的文件討論,就能溝通好需求。這是標準的「既要馬兒好(需求被100%了解),又要馬兒不吃草(又不想花時間好好討論)」的狀況。

    其次是實作的工程人員的態度。一般來說,工程師們比較習慣和電腦、儀器設備做溝通,要他們與客戶端做頻繁的溝通,他們往往會不太適應。最常聽到的就是「太浪費時間」,頻繁的溝通導致他們沒有足夠的時間去實作產品或服務的功能!

    第三是需求規模的龐大。一個產品或服務往往包含許多的功能和實作細節,軟體產品尤其是如此。在這種狀況之下,想要每個功能都能讓「客戶/用戶」和「實作者」直接溝通討論清楚,似乎真的是非常耗時的一件事情。況且,也不可能有這麼多、這麼大的白板來讓我們一直畫畫下去。

    Scrum的三種角色

    既然「人性」是上述三個主要障礙中的兩大部分,尤其軟體產品或服務的品質,與人的素質和心態又是極度地緊密相關連,那麼,我們就先來看看,Scrum到底定義了哪些角色,來試圖「緩解」(注意我用這字眼,不是用解決)這些理想與現實之間的差距。

    Scrum其實總共「只」明確定義了三種角色,就是所謂的Product Owner產品負責人、Scrum Master 大師,以及Development Team開發團隊,分別負責對外溝通、對內管理、以及實際實做和驗證。然而內外之間總得有交流互動,方可能進入實作,實作又得有規有矩,方能有效產出成果,於是簡單的角色定義,和實務上的複雜,開始出現衝突!這部分因篇幅過長,我們就待下篇文章來繼續探討囉!

    待續...
    圖片來源:www.inc.com


    更多相關文章:《敏捷方法的成功密技》系列文章總覽