敏捷大會――會後反思
週日 12月18號的敏捷大會上，主要參加了敏捷實踐分會場。
在聽的時候，我一直在腦海中，一直試圖把演講老師的經驗模式，往自己的團隊上「套」。一直以來，在工作交付，需求**方面，相應的質量方面，我們都有很多頭疼的地方。引入了敏捷，公司的管理層，尤其是高層，肯定希望，能帶來改變。但是，我們的原生環境到底帶來了哪些束縛，聽了分享後，多少有了些頭緒。
我們所在的大組織的需求，大部分不是直接來自市場，也就是說，我們輸出的模組，或者服務，最終在更高的層面上，被整合了。這很容易導致我們只見樹木，不見森林。
我們的「客戶」，或者說需求方，有自己的利益宿求，首先，他們有自己的開發任務，對於他們來說，第一要務是完成自己的工作，他們丟擲的需求，有時候，自己也拿不準，這個時候，他們自己的策略，肯定是延遲決策了。
這也是在聽的過程中，特別感受到的。可是就算搞清楚了小環境，也沒什麼用啊。得解決問題啊。還是3個大方面，「需求」（到底做啥），「溝通」（不只是上下溝通，還有左右溝通，有互相依賴咋辦），「質量」（做出來的東西，客戶不認可，就是白做了。）
先說下印象深的，就是聽ibm的spootify的時候，她們提到（隱約是乙個金融類的專案），人數，大概要上千人左右。她們，分了不同的層次，小分隊－》。。。－》部落。不同的層次，由不同的影響力的人來協調。這麼橫向比下來，我們組，也就算是個最低層次的小分隊。
但是不同的是，我們這樣的結構裡，每個小分隊，貌似乙個小麻雀，還5髒具全。這就帶來乙個問題，每個人之間的工作，經常有依賴，有人快，有人慢，模組大小也不可能切的很均勻，這該怎麼辦？
她們的乙個技巧是dark release，做好了就發布，但是，相關的還沒做好，就設定個開關，對外先不可見。
我問了乙個問題，這種依賴，最後誰來協調。演講人提到，整合測試的時候，會發現很多問題，反向牽引相關的人改進，誰做的模組誰負責，最後由整合測試人員，來負責最終質量。
豁然開朗！
王明蘭老師，曾經輔導過我們，這次，她帶來了一些方**上的新思想。促使我回顧下，我們這種complex型別的工作（也就是不知道做下去之後，帶來什麼後果的），還是很適合kanban方法的。
「PMO大會」會後總結
6月16 17兩天參加了 專案管理大聯盟 主辦的首屆pmo大會，兩天的時間，16位專家的精彩分享，讓人有點目不暇接。因為是pmo的大會，所以主題自然是專案管理辦公室，當然也有p3o，專案集 專案組合 專案管理辦公室。聽過所有專家的分享之後，對pmo得出了這樣乙個結論 pmo就是為了解決那本 家家有本...
英雄會，會英雄，CSDN大會有感
今天應csdn之邀參加csdn英雄大會。自己不敢妄稱英雄，但是還是很想認識一下慕名已久的英雄們。也很想念一些老同事。藉此機會與大家聚一聚。早上匆忙起來，穿上csdn為專家們準備好的紅色襯衣。感覺非常的合身與精神。感謝小查同學昨晚幫忙選擇很合身的襯衣。呵呵，女孩子在這方面就是有天賦。從昨天到今天他們這...
csdn 英雄大會後記
csdn 英雄大會後記 核心裡面還有核心，找到最核心的方向 csdn總裁蔣濤 我參加csdn英雄大會的過程可以用 遲到早退四個字來概括。遲到的原因dbanotes的大輝已經說了，汗 早退則是因為要趕公司的班車，參加週末的會議。時間雖然倉促，收穫倒是滿滿的。我的 csdn技術英雄會流水帳 是這樣的 我...