對於敏捷, 大家常常會有個誤解, 認為用了敏捷, 就會讓開發過程變得比較快. 事實上, 敏捷不是要做得比較快, 還是要讓你的團隊有因應改變的能力.
 
可是有人說敏捷可以比較快, 那到底是怎麼回事? 是他們騙人嗎? 我想他們可能做到了, 敏捷宣言內某一條原則: Simplicity--the art of maximizing the amount of work not done--is essential.
 
simplicity1  
 
如果你能夠最大化未完成的量, 也就是範圍變小了, 自然就能讓團隊做得比較快. 可是這要如何達到呢? 我想可以從這三個做法出發:
 
1. 排出優先順序
Agile 要求重要的先做, 頻繁交付後, 以得到客戶的回饋. 在幾個 sprint 之後, 客戶會有機會覺得, 這樣的東西好像已經夠用了, 因此可以考慮停止. 或者老闆覺得, 這樣的版本已經可以拿去賣了, 不用等全部做好. 
 
像這樣的狀況, 因為你已經做了足夠需要的東西, 你便可以讓這個版本發佈, 其他剩下的東西, 不是捨棄, 要不就算到下一個版本中, 這個版本便可以到此就算結束了.
 
 
2. Pretotyping
沒錯, 我沒寫錯字, 這是一個新的東西, 告訴你如何利用一些方法, 在系統未開發前, 就可以驗證這東西是否有人要. 詳細的介紹, 大家可以參考之前我寫的一些文章:
 
 
3. 排除風險
在開發初期, 我們需要先驅釐清以下風險:
business risk: 是否這個東西有人要? 我們是否做正確的東西?
social risk: 我們是否找正確的人做這件事?
technical risk: 技術上是否可行?
cost/schedule risk: 時程上是否來得及? 以及成本上是否值得?
 
這些風險如果可以及早被處理, 我們才能知道是否要及早停止, 或者是及早提出解法. 尤其確定成本的投資報酬率這一項更為重要, 當你發現再多做功能, 已經沒辦法再多賺錢, 或者是無法回本, 這時候便要停止.
 
 
 
不過乖乖把事情做完是老中的特色, 不管做出來的東西有沒有用 XDD
 
 
arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()