去年，對門部門的同事喊我一起去開scrum的研討會，分享一些他們的經驗。雖然他們確實在用scrum的流程和方法，但是我發現他們還是沒有看到問題的本質：(1)關注人，別只關注專案。(2）雖然流程可以阻礙生產力，但是流程不能提高生產力。提高生產力唯一的方法是請好的人 (3)軟體行業中，沒有用的文件和ppt最浪費時間 (4) scrum可以做成ppt為你的年終考評加分，但是實際上你只是回歸了人類最原始的想法，這沒什麼好驕傲的。
其實你是不是scrum沒關係，你開不開stand up meeting也沒關係，但是最重要的是，你的團隊是一群有戰鬥力的人，他們彼此信賴對方，他們相信最好的文件是**，他們很少需要email來溝通彼此的介面。最重要的是，專案可以延期或者需求可以改變，但是人不能盲目的加班加點，為了去meet那一點都不合理的進度。
我認為scrum裡最值得推薦的實踐過程（當然，有些其實不是scrum獨有的)：(1) feature按優先順序實現，大家可以在開始前「討價還價」 (2) 可以更早的反饋 (3) 單元測試，持續整合 (4) face2face > email，可以工作的軟體 > 文件 我最不看好的實踐過程是 (1) pair programming (2) tdd
上訴，我覺得agile, scrum沒有什麼好開座談會的，更沒有什麼諮詢的必要。它就是一種最本質的軟體開發流程思想，絕對比什麼瀑布要更深入人心。怎麼說呢，如果你沒有學過什麼軟體工程，你天生就是agile的。我就不明白這麼簡單的過程我們需要研討什麼，諮詢什麼？算了，我把它稱為樸素的agile觀(參見樸素的唯物主義）
實戰中的Agile開發
開始本篇之前先來大致看看敏捷開發的內容 首先敏捷開發的宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過 遵循計畫 再來看一下，敏捷開發需要遵循的一些原則 以上那麼多內容，簡言一下，相對於標準化的cmmi開發，敏捷開發的優勢是快速和變化...
末日帝國 Agile公司的困境
接下來的幾天，阿捷滿懷信心地等待著agile的 等袁郎通知自己去拿offer，想象 著自己在座位旁的小白板寫些什麼，畫些什麼。可乙個禮拜很快就過去了，還是沒有任何資訊，阿捷幾乎想主動打 過去問問到底結果如何？但最終還是放棄了這 種念頭，因為如果agile公司想要自己的話，肯定會主動跟自己聯絡的。沒辦...
CMMI跟Agile之間的衝突
infoq 剛才在別的討論組上，你還提到了cmmi跟agile之間的衝突，能不能再多講一下你的看法？bas 我認為cmmi一點用都沒有。infoq 呃 bas cmmi關注的是管理和組織，而不是開發本身。在cmmi的一大堆關鍵過程域 key process area 中，只有乙個是跟開發有關係的。大...