傳統軟體估算人天的方式, 有的使用 functional points, delphi....等等。
敏捷開發, 使用數學**比例; 1, 2, 3, 5, 8, 13; 以各 user stories 之間 "相對" 的複雜度, 估算各 user stories 所需的人天。
然而,僅僅是改變個演算法
, 是毫無意義的……
軟體開發
, 存在著很多的誤區
,使得軟體開發的效率與質量無法獲得提公升。當中之中的乙個的誤區便是
:期望用各式的人
/天估算方法
,使得開發者
, 可凖時的交付符合預期的軟體。
我時常在提的一件事便是:
現今人類的科技再進步
,但軟體開發對很多人來說
, 仍舊是件
「純手工打造
」的活。既然是 "純手工打造"
,怎樣能用所謂的
「人/天
」去預期符合期望的軟體何時能交付?
所以,真正的重點
, 不在於用何種方式去「
估算」人天。
真正的重點在於
: 怎樣利用各
user story
的人天,
使得product owner
能充分掌握, 每乙個
sprint
的重點事項為何
? 團隊的風險為何
? 某個團隊成員究竟出了什麼問題
? 該制定何種有效的策略
, sprint
計畫,
才幹帶領團隊公布出真正有價值的版本號。
人/天,
是用來供
product owner做「
決策」用的,
不是用來
「簡化管理
」；將全然充滿人類行為的軟體開發
,簡化為制式
, 單一的機器運作
。
敏捷開發下平衡質量和進度
敏捷軟體開發團隊必須確保他們開發出來的產品質量能夠滿足要求，管理團隊也經常希望開發團隊能夠提高速度以實現為客戶提供更多的功能。本篇文章中多個作者 了質量和速度之間的關係，並提出了一些既能提高質量也能加快進度的方法。bob galen曾今在他的部落格中發表了讀懂我的唇語 敏捷並不快速的文章，在其中寫到...
敏捷開發般若敏捷系列之八 敏捷的未來會怎樣？
這是敏捷開發般若敏捷系列的第八篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 任何事物，都會經過這三個階段，有的短至幾年，有的長達幾千年。正法時代一般是原創者掌握話語權的時期，因此能正確地解釋和傳播。正法時代傳播的是智慧型和般若，而不是知識 方法，具體的實踐等 本人先是學習了敏捷開發的方法...
敏捷開發一千零一問系列之三十 敏捷怎樣估算（中）？
這是敏捷開發一千零一問系列的第三十篇。在這裡提問，之一 之二，之三 問題總目錄 續前文，預計未來還要有一篇，暫時做為中篇。這個在之前談到過很多次了，具體可以 參考敏捷開發績效管理系列 的之六 之七。另外在敏捷開發使用者故事分類與組織結構 一期 整個活動1期 中有詳細描述。這個是國際上迄今為止唯一被大...