在與一些人交流時經常碰到對方說，你的方法好是好，就是不如現在的方式效率高，因此並不願意作出改變。我們來分析下，為什麼說這樣的思維方式是有害的。
有些團隊包括技術背景出身的po不願意按可交付的方式拆分需求，原因是原來的方式雖然不能頻繁交付，但最節省時間，效率最高。
這種思維是有害的，首先：頻繁交付的一大目標是通過快速反饋確保探明真正的需求，構建和交付的是正確的產品，而不是為了更高效率地在給定時間內完成更多的需求內容。do the right things, 花費的代價可能更高，但避免了南轅北轍式的整體錯誤或陷入進退兩難的焦油坑中無法自拔。通過頻繁交付，即便在給定時間內不能完成全部需求，缺失的也不過是價值較低的特性，對客戶價值的損害有限。歷史經驗也表明，專案中最大的浪費不是多花了10%－20%的時間來開發，而是構建了錯誤的產品，新增了根本沒人會去用的特性。
從另外的角度來看，在大多數專案中，真正開發的時間只佔整體專案時間的20-30%， 即便省出了開發時間的20%，佔總體專案時間的比例也只是 30%＊20% ＝ 6%， 為了這個6%卻去冒不能及時獲得有效反饋的風險，長遠來看並不值得。
在非常自信不拆分的特性就是真正想要滿足的需求時，整個一大塊不拆分，也可稱之為「衝坡式開發」，團隊必須具有足夠的能量衝過去，否則就有可能造成溜坡，不僅所有努力白費，還可能造成其它嚴重後果。在某些特定情況下，「衝坡式開發」還是必要的，這時就要注意集聚足夠的能量，以及在技術上採取必要措施，比如通過臨時分支等方式避免對主幹的干擾，盡量做到可以隨時叫停（止損策略）而不會對整體造成影響。
因此我們說：
因為團隊技能的問題，很多組織還是習慣按元件或者架構層次來劃分團隊負責領域，這樣在拆分需求時，乙個團隊內的使用者故事顯然無法覆蓋端到端，如果迭代計畫也缺乏協調，後果就是各種互相依賴，很難做到持續交付。
結論：wate***ll效率高的幻想出現在專案早中期，後期往往陷入焦油坑中無法自拔，喪失應對變化的能力，一旦決定捨棄一部分產品特性時，很大部分的努力也白費了。
我們常常看到，關鍵時期，乙個系統出了嚴重bug，一堆經理層層發布指令，號召必須在最短時間內搞定，最後我們可以發現，所有的焦點集中在乙個開發人員身上，其他人即便想幫忙，短時間內也無法貢獻太多，這個開發人員如果成功將bug搞定，則會被視為英雄，否則，便會成為替罪羊。
如果我們按模組把責任細化到每個人頭上，互相交叉太少，需要投入更多人員協同作戰短時間內把問題搞定的時候，就很難辦到了。 單人打法，就像是巷戰，全憑個人能力，而不是全方位立體團隊協作模式，短時間內區域性也許效率確實很高，缺點也很明顯：質量能否保證，取決於個人，個人的微小錯誤可能會被放大，系統中的各個模組質量差別可能很大。
考慮各種情景，長期看單打獨鬥模式在關鍵時刻往往會出嚴重問題。比如需要協同作戰的時候，效率可能無法提高；人員一旦變化，對整體的影響也會比較大。
更多敏捷教練經驗觀點見 www.uperform.cn/blog-articl…
有害的「這樣效率最高」思維
在與一些人交流時經常碰到對方說，你的方法好是好，就是不如現在的方式效率高，因此並不願意作出改變。我們來分析下，為什麼說這樣的思維方式是有害的。有些團隊包括技術背景出身的po不願意按可交付的方式拆分需求，原因是原來的方式雖然不能頻繁交付，但最節省時間，效率最高。這種思維是有害的，首先 頻繁交付的一大目...
判斷數字最高效率的演算法
這是以前csdn上乙個經典的帖子，我當年剛學 net的時候學習的，不知道有沒有朋友有不同意見 q 怎樣判斷是數字？例如 12345 是數字，12345t 不是數字 12345年 不是數字 非常感謝各位，我以前也曾試過用正則式 和 異常法來做 但用的正則式中的另乙個方法，可沒這麼簡單哦 呵榀，這個不錯...
Macbook 上使用頻率最高的三款效率工具
一年多前趁著京東 加上十二期免息券，入手了macbook pro。當初入手mac，最大的原因是它的顯示屏完勝其它電腦。作為半個程式設計師，眼晴的負荷本身就大，若是配著普通的顯示屏豈不是自己找罪受。有個奇怪的現象。就拿籃球鞋說，最初我都是穿著平常的鞋子打籃球的，後來買了一雙很普能的球鞋。剛開始穿著也沒...