1.解決敏捷管理者的困境
面臨的挑戰：
1.如何實現在敏捷社群所稱的可持續步調，保護團隊免受業務部門提出的無窮無盡的需求的困擾？
2.如何克服其中不可避免的變革阻力，將敏捷方法成功推廣到整個企業內？
敏捷社群將可持續步調簡單解釋為"每週工作40個小時"。敏捷過程強調可持續開發。出資人，開發者和使用者應共同維護乙個長期穩定的步調。
消極：一直以"不行"這種拒絕方式，抵擋來自業務方持續不斷和善變的需求。
軟體部門和it部門似乎總會遭遇被其他組織任意擺布的悲慘命運。大多數團隊則是既沒有透徹的分析方法，又沒有任何歷史資料支援，
在那些想要迫使他們承諾未知(甚至是不合理的)交付期限的權術手腕下，他們無疑是勢單力薄的。與此同時，軟體工程師也已經基本上接受了瘋狂的進度表和獻身精神，並對此
司空見慣。軟體工程師好像根本不該擁有社交活動和家庭生活似的。
乙個是要有積極的領導者，根據不同的環境裁剪框架，如果缺少這種指引，就很可能會基於自己盲目的信仰，主觀的將變化強加給團隊。這與因強行施加不適宜的流程模板而
招致更大的憤怒和反對。
每個團隊都是不同的：不同的技能要求，不同的團隊能力和不同的經驗。
每個專案也是不同的：不同的成本預算，進度，規模和風險情況。
每乙個組織也是不同的：不同的市場，不同的價值鏈環節。
簡而言之，脫離具體情境的變革建議，都會遭受身在其中，了解專案具體狀況的工作者的抵制和拒絕。
由消除乙個又乙個瓶頸來不斷演化發展出乙個新過程，是最好的做法。這是艾利.高德拉特的約束理論的核心主題。該方法的主旨是:識別並設法減少瓶頸因素，直到瓶頸因素
不再對效能產生約束；消除乙個瓶頸之後，又會湧現出另外乙個新的瓶頸，如此迴圈不已。這種方法以迭代方式，通過識別和消除瓶頸，系統性的提公升效能。
我認識到，可以將這項技術和精益方法中的一些理念合成在一起。首先以價值流對軟體開發的生命週期的工作流程進行建模，然後建立乙個視覺化的追蹤系統，此後，當新
工作"流"經該系統時，通過追蹤其狀態的變化，便可識別出瓶頸。在約束理論的基本模型中，具備識別瓶頸的能力是第一步。
鼓-緩衝-繩 被看成是拉動系統這類解決方案的乙個具體例項。看板系統是拉動系統的另外乙個例項。拉動系統是乙個有趣副效應是，它們通過將在製品限制在一定的數量範圍
內，來防止工作者的工作量過載。此外，只有在瓶頸區的工作者會滿負荷，其他人則應該會有富餘時間。
視覺化工作流程，工作項型別，節奏，服務類別，專門的管理報告和運營回顧等，共同定義了看板方法。
管理者的困境 放權或者崩潰
大多數管理者都會陷入放權的困境。你很忙，每件事都要親力親為。你很清楚自己需要別人幫忙，但你沒有足夠的時間尋找並培訓別人來幫你。所以，你更加努力地工作，直到自己崩潰。下面這個故事講述了我如何放權。2001年，cd baby成立三周年。我已有8名員工，但所有其他事情仍然需要我自己做。每週7天，從上午7點...
軟體管理隨想記 管理者的管理風格1
序 首先宣告一下，我不是乙個管理者，充其量也就帶過小小的開發團隊，這裡所寫都是根據平常的所見所聞加上我的個人觀點整理而成的，當然也有一些迷惑在裡面，希望各位讀者能夠指點迷津，共同討論一下。管理者的管理風格1 每個不同的管理者有不同的管理風格，不同的管理風格則帶來不同的效果。哪種風格更好一些呢？仁者見...
成熟敏捷組織中管理者的角色是咋樣的？
成熟敏捷組織中管理者的角色是咋樣的？敏捷團隊既然已經自組織了，那麼還要管理者幹嘛哪？管理實戰手冊對管理者的角色做了分析，有六個需要關注的領域，即便在自組織的團隊裡面也是一樣，所以總是會有工作要做。想象一下這樣的場景 你在一家公司裡面擔任管理者已經有些年頭了。情況變得越來越糟糕，但你知道還有改進的空間...