從接觸scrum到現在已經快一年了。
在這一年裡，組內一直使用scrum的流程進行開發管理，雖說有些山寨，但看上去還是像那麼回事的：blog分解、計畫分解、立會、發布、回顧，該有的都有了，自己對於敏捷也從開始的新鮮到了現在的。。怎麼說呢，不那麼新鮮了。。。。
這次的產品是乙個公升級版，功能比較單一，但由於原來的**主要來自於專案，1.**質量不是很好 2.各個專案的功能也不太一致
這次公升級的兩個目的：
1.提高**質量、優化架構
2.把已經在用的幾個專案的需求抽煉出來，固化到產品中。
由於發版日期提前，我所在的小組全部都過去支援，我們去的時候，開發已經進行了3周。正好第一次迭代結束。
到昨天，第二次迭代也結束了。
在這中間發現了一些問題，權且記錄在此，以後可以有個參考。
1.由於時間緊，任務多，並且大部分功能在專案上已經用了很長時間，所以我們去的時候看到的情況是：大部分的業務**都是直接從專案拷貝的，改動很少；這樣**質量基本沒有提公升。
2.拿這次發布來說，昨天加班不說，加班的時候乙個白天基本就在搭環境上了，而且自測到了晚上9點才完成，而環境更是到了11點才正式搭好---而且還不完全好使。
3.立會時間太長，原因主要是人多 --13人，而劃分小組也比較困難，另外乙個原因就是有時會糾纏到細節上面，浪費了時間。
4.對**質量的意識不高，由於團隊成員普遍比較年輕，設計、編碼經驗尚有欠缺，再有就是不重視重構。
對於以上的問題，自己目前想到的解決方案（有待進一步驗證）：
1.加強人員能力培養，其實每天花不了多少時間就重構的很好
2.加強自測意識、使用自動部署工具，簡化部署，每天早上立會說完成某個功能的時候，必須在部署後的環境而是不本地開發環境測試完成；加強交付標準的制定--培養意識。
3.這個目前還沒想到辦法，我的想法是根據業務型別分為兩組，並且要求每個人在表達問題的時候，清楚、簡介。
4.能力培養；關於重構的問題，是個普遍現象了，原因主要有兩點：一是不重視或者懶 二是害怕改出問題。對於一，只能加強大家的意識了，讓大家重視起來；對於二，還得靠自動化測試來保證改動後的正確性。
寫完這些後，發現目前遇到的問題主要是兩個：
1.人員能力/意識問題
2.自動化工具（部署/測試/**檢查等等）
我在想，這兩個是不是阻礙我們敏捷起來的原因呢？我們的山寨敏捷是否就山寨在這了呢？
對策也比較容易了：
1.人員能力培養，這個話題可太大了，目前是採用專案+導師的機制。。。
2.找工具，不行就寫一些輔助工具，不能全自動還不能半自動麼。。。
我不知道自己想的這些時候跑偏了，只能摸索著前進了。。。
就拿這兩點當做乙個突破點吧。
IT人 為什麼快樂不起來
擁有著120多年歷史的英國倫敦城市行業協會 city guilds 日前發表的乙份調查報告顯示 只有不到1 7的it從業者認為自己的工作是令人愉快 同時，在 行業快樂指數 排行中，it業排在了非常靠後的第19位。無獨有偶，在近日國內一些有關it人心態調查的結果竟然與英國的調查結果相仿。今年4月5日開...
為什麼我不推薦敏捷開發？
當專案成員越多，我越不推薦敏捷開發，原因在於 當連自己要做什麼事 為什麼這樣做 這樣做為了解決什麼問題 都搞不清楚前，就跳下去玩敏捷開發，那和比通靈還慘，通靈起碼還有個目標物在前面，搞不清楚狀況的人只能陪他跳世界迷霧開地圖了 敏捷開發 mba智庫百科 最下方有段 對敏捷開發的誤解 可順便參考 敏捷軟...
IT人 你為什麼快樂不起來呢？
it人 你為什麼快樂不起來 擁有著120多年歷史的英國倫敦城市行業協會 city guilds 日前發表的乙份調查報告顯示 只有不到1 7的it從業者認為自己的工作是令人愉快 同時，在 行業快樂指數 排行中，it業排在了非常靠後的第19位。無獨有偶，在近日國內一些有關it人心態調查的結果竟然與英國的...