Scrum框架下的跨界開發

June 28 09:48~11:50

 

這禮拜三下午Teddy剛好有機會與「Apps跨界交流協會」的Ryan與ezScrum團隊討論「跨界開發」的議題。跨界開發不是說要鄉民們跑到人家家裡去開發程式，也不是要原本在當水電工的你去報名電腦補習班之後就可以「跨過界」變成軟體工程師。而是Ryan很熱心地想要搭起一座橋梁，讓UI設計師與開發人員可以找出一個合作模式，能夠很順利地做出美觀又好用的軟體。

軟體跟人是一樣的，「外表」和「個性」都很重要。豬哥一般鄉民們很容易被長相甜美的「正妹」給吸引，但是如果在正式交往之後，才發現這個正妹有很嚴重的「公主病」，或是做人很自私外加沒有愛心，這樣的交往關係就不容易持久。軟體也是一樣，以手機應用程式來講，在App Store上面隨隨便便都是幾十萬個軟體可供鄉民們選擇，如果App的介面沒有設計的漂漂亮亮，是很難吸引鄉民們的眼光。但是，光是漂亮只算成功了一半，如果軟體本身的操作流程不易使用，或是軟體不穩定，動不動就跟你搞什麼「重新啟動中」的把戲，那麼這樣的軟體也很難長久占用鄉民們手機裡面那一點點有限的空間。

Ryan已經成功號召了許多在UI設計界有名的公司或組織，也接觸了幾個軟體開發社群與公司，此次與ezScrum團隊的會議（Teddy單純是因為「個人原因」跑去插花的），是想討論Scrum在這種「跨界開發」的模式上，能不能幫上什麼忙。講到「跨界開發」，Teddy腦海中就冒出象棋棋盤上那條分隔紅子與黑子的「楚河漢界」。回想起10幾年前Teddy剛工作的時候（年紀大了，好像很多回憶都發生在10幾年前…Orz），也是遇到「跨界開發」的難題。當時Teddy帶領一個10人左右的團隊開發一套網路教學系統，團隊中有兩位專職的「UI設計師」。在10幾年前網際網路剛開始流行沒多久的那個年代，網路教學系統對於UI設計的要求其實不多，大該只有以下幾項：

• 設計漂亮的icon或是按鈕。這一點算是基本款，一般的UI設計師都應該有能力可以勝任。
• 設計網頁系統的整體觀感。設計整個網頁系統的風格、layout、配色等等。這一點就比單純地設計icon要困難不少，功力強一點的UI設計師才有辦法做得好。
• 設計網頁系統的操作流程。這是最困難的一點，也是當年許多UI設計師的挑戰。要設計一個網頁系統，不就是設計一堆網頁，然後再用超連結把這堆網頁給連起來就好了嗎？當然不是，因為很多應用程式的工程，其實是需要控制狀態與操作流程。這樣的系統如果只是分析好一堆畫面，然後把這些畫面直接實做成一頁、一頁的網頁（不管是靜態網頁或是動態網頁），那麼使用者在操作系統的時候便很容易在網海中迷路，不知今夕是何夕，此「頁」是何處。使用者也經常遇到不小心按到瀏覽器的「上一頁」按鈕之後，整個系統就爆掉的 杯具 悲劇。

除了UI設計師能否達成Teddy心目中期待他們達成的任務以外，另一個困擾Teddy的問題就是：如何知道UI設計師有沒有認真地好好工作？這個問題聽起來很可笑，但是實際上這是一位身為程式設計出身的技術主管當時在帶領團隊最大的困擾。因為關於系統分析、設計、實作等等的問題Teddy與另外三位資深的工程師都有能力可以搞定，而且Teddy「大致上」也都很清楚每一件coding的工作需要多少時間。但是，在當時UI設計師對Teddy來講基本上就跟一個「黑盒子」差不多。

Teddy：什麼，畫一個icon要半天的時間？

UI設計師：對啊…不然你自己來畫…

***

Teddy：這個網頁操作的流程不太對喔，是不是應該用Wizard的操作模式這樣使用者比較容易上手？

UI設計師：這是網頁不是桌面應用程式耶，你不要用桌面應用程式的操作模式來思考網頁應用。

Teddy：問題是不管是桌面應用程式還是網頁應用程式，對使用者而言，一個繁瑣的操作流程，系統就應該要逐步分段引導使用者去完成才對啊。

UI設計師：那你就是要把網頁系統做成桌面應用程式的樣子就對了？！

準備開打…Orz

***

當年根本都還沒有什麼Scrum，Teddy採用的是看書學來的RUP（Rational Unified Process），但是書上並沒有說UI設計師要如何跟程式設計師一起合作啊。當時Teddy對於HCI的了解很少，與UI設計師的合作方式基本上就是請他們先把系統的prototype做出來，然後大家一起開會集思廣益，之後UI設計師再去修改，一直到做出一個大家可以接受的版本，或是大家都受不了為止XD。

不過這樣的經驗還算好的，Teddy也有遇過那種在大公司裡面，UI設計師與程式開發人員分別隸屬不同的部門。在這種情況之下的合作，只能用一個「慘」字來形容。UI設計師覺得程式開發人員「不識字又兼不衛生」，怎麼可以設計出這麼醜又難用的程式出來。而程式開發人員覺得UI設計師也高明不到哪去，而且做事超級會拖延的。只是要一個icon，可以拖個2-3天才給我；程式的「動線（操作流程）」還都必須要經過UI部門畫押才可以動工。這邊卡一下，那邊又需要幾天，我的程式到底還要不要寫啊。這些也都算了，另程式開發人員最不爽的是：啊你們UI設計大師搞出來的東西比我自己設計的還要難用啊。算了，既然是公司規定軟體操作流程必須要由UI設計師來負責，那我（程式開發人員）就不管了那麼多了，把程式寫出來就對了。總之到時候系統不好用不關我的事，都是UI設計的爛。

UI設計師內心獨白：我精心打造的UI簡直是藝術品啊，交給這些「大老粗們」一定沒好下場。總之到時候成品有問題就是這些程式開發人員實作能力太差啦。

Teddy內心獨白：不是你的錯，也不是他的錯，都是月亮惹的禍XD。

有這樣的團隊，公司還需要敵人嗎？

***

扯了這麼多，Teddy想講的只有一件事，那就是：跨界開發的問題不是技術的問題，而是溝通與心態調整的問題。

回到Scrum框架下去思考Teddy剛剛提到的那兩個例子所遭遇的問題：

• 兩派人馬的誤會，有沒有可能藉由sprint planning meeting而減少或是擺平？
• 藉由sprint planning meeting雙方是否可以更加理解對方工作的內容？
• 雙方的工作進度是否變得更加透明？
• 有沒有能力或是辦法組成一個cross-functional team？
• UI設計師加入Scrum team之後，要如何與程式開發人員分工合作？
• 在cross-functional team中，story要如何挑選，task要如何認領才不會造成「勞逸不均」的問題（有人忙得要死，有人無事可做）?
• 同處於一個Scrum team，是否可以提升團隊成員對於所共同開發產品的歸屬感？

Teddy覺得Scrum不只是一個持續改善的框架，也是一座橋梁。橋搭的好，跨界開發的問題便可逐步地被解決。橋搭的不好，不用土石流或是颱風，光是人在上面走來走去，沒多久就自己斷掉了。

***

友藏內心獨白：Software development is all about communication。