培訓多少是有些枯燥的，印象中那些關於專案管理的培訓大多是乙個經驗豐富的資深人士以授課或者討論的方式向在座的學員傳授知識、心得或者一些實踐技巧。最近參加了一堂別開生面的專案開發實踐課（樂高遊戲體驗），從名字上就能看出來，其實是在玩樂高積木，如果拋開遊戲背後的東西，單純玩玩積木也是很有意思的一件事，哈哈。
課程開始後，講師就道明了這次的兩個主題——價值驅動和迭代，隨後說明了遊戲規則：
需要額外說明的是第二階段開始前，每組會按照座位的順序選出一名組員「跳槽」到其他組，直至結束，第二第三階段開始前評委（就是其他的老師）會根據大家的作品選出乙個小組注入「資金」，額外給一袋積木。整個過程開始前，每組會拿到一張大紙，pm會在上面標上todo、doing、done、 sign（使用者代表驗收簽字欄），前三欄用來貼卡片，最後一欄使用者代表確認小組完成了他提出的要求就簽字畫押。
第一階段我自告奮勇去做了裁判，到其他組晃了一圈，這時卡片下來了，我看了下「要求單一顏色」、「有兩個頭的怪物」、「長超過15cm、寬超過 10cm」、「怪獸有4隻腳」等等，客戶代表選定了卡片交給pm，並根據這個提出自己的要求，pm協調開發人員用桌上的積木完成需求。
20分鐘很快就玩掉了，大家開始討論，隨後是作品展示，因為每組拿到的卡片並不一樣，而且有很大發揮空間，所以大家做出來的東西都不一樣（這個是肯定的嘛）。講師也提出了一些問題，例如，製作過程中有的小組把客戶代表晾在一邊，或者是客戶代表只是乙個勁地說「隨便」，小組成員之間缺乏溝通，只有一組完成了單一顏色這個需求，但是這也埋下了隱患，後面幾輪沒有這麼多同色的積木……
第二階段開始，我終於成了開發人員，可以玩了，但我們的一名主力開發不幸「跳槽」了。。。另外新加盟的開發成員顯然被我們其他幾個忽略了，剛開始時大家都沒有主動和他交流，只是各顧各地在那裡動手完成需求。這時需求的衝突出現了，第一次要求兩個頭四隻腳的怪獸，現在要求乙個頭兩隻腳了，衡量了一下分值，我們還是決定改。這次客戶提了很多要求，我們做的也很快，一口氣完成了3000+的分值（兩輪18張卡片只剩下1張單一顏色的沒有做），要知道上一輪最高的小組也只做了2700分，大家很興奮。這個階段結束後，我們拿到了第2筆投資，第一階段的獎勵給了另乙個組。在點評時，講師提出了他發現的問題，「 跳槽」過來的新成員大多沒有得到重用，不是做了觀察者就是做了裁判，當了開發人員的也就我們這組了。
第三階段開始，我們這裡上演了戲劇性的一幕，來我們這裡的裁判提出要幫我們做開發，原來他在之前的組做了一輪觀察者，然後就過來做了裁判，自己還沒玩過呢，我們倒是很樂意讓他來做，不過講師不同意，對不住了兄弟，你繼續看我們玩吧。這回我做了觀察者，坐在那裡看著大家熱火朝天的工作著——重構上一輪做的城堡和怪獸，為城堡新增兩層大門，怪獸有個孩子……一共是27張卡片，除了有衝突的基本都做了，整個專案完成後計算總分，各組比較最後結果。最後的討論結束後，每組都選擇了代表發言，並做了展示，大家交流了自己的感受及這次的收穫。
講師也向大家提了幾個問題，大家是憑什麼選擇需求卡片，哪些做哪些不做的？如果一次性給大家60分鐘，而不是像這樣分3個20分鐘，迭代3輪，還能做出現在這樣出色的作品嗎？其實整個的遊戲過程就是乙個專案，其中有真正專案中的各種元素，只是大家做的不是軟體。
最後秀一下我們組的作品：
從撲克牌看專案的需求管理
1 在撲克牌對弈中，各家的牌面是現實存在，不論我們是否知曉。在專案實施中，各方的需求是現實存在，不論我們是否知曉 2 不論牌面如何糟糕，我們只能依據牌面出牌，重要的不是牌面是否糟糕，而是各家的具體牌面。不論需求如何苛刻，我們只能按需求辦事，重要的不是需求是否苛刻，而是各方的具體需求 3 我們可以依靠...
從「土豆」看軟體
之所以用 代替，是因為我認為軟體設計 開發測試等方面太多了，我只說軟體需求這一方面。上篇文章中提到兩個 買土豆的故事 故事一中的張三和故事二中的甲，都屬於 聰明 的人，他們為老闆想得周到，老闆一句 看看市場上有賣土豆的嗎？和一句 買點土豆回來。引發了張 李和甲乙的不同的反應。但是給人比較統一的感覺就...
從生活看AOP
面向切面程式設計,首先面向切面程式設計是什麼?面向切面就是把邏輯 和處理瑣碎事物的 分離開,以便分離複雜度.面向切面有什麼用?舉個很簡單的例子吧,銀行去取款 取款之前會驗證使用者 輸入密碼,當客戶取款後想要檢視餘額,但是又要驗證一把輸入密碼,這樣不僅使用者體驗度極差,而且 繁瑣,所以仙子阿我們用到的...