其他

  做了這麼長時間的敏捷開發，第一次對一個衝刺有這麼刻骨銘心的印象。我想主要有以下幾點造成的。第一，是有一個全新的團隊，非常年輕幾乎沒有經曆過任何正規化流程的人員構成的團隊。第二，是被迫把很多基礎性的工作拉進來還不得顯性的列在backlog中。第三是，從需求到技術再到部署，都沒有在一開始就定好準備好，都是隨著時間在迭代。  團隊。和任何一個經驗豐富的scrum

   隨著負責敏捷的VP來到中國，看板也成為了這次討論的熱點。很多團隊都在使用看板從而取代了之前的Scrum。   看板源於豐田，是豐田產生模式的經典代表，幾乎每個學習豐田TPS的企業都會不自覺的把看板當作第一個引入的模式，因為它直觀有效。而敏捷將可視化作為很重要的一個要素，自然而然的會想到向看板要概念。那麼看板有哪些特色呢？ 

  過年在家反思又反思，總覺得有個現象很奇怪，就是很多人都是喜歡讓高手去講東西，自己去聽。我覺得“聽”是一個很被動的學習習慣，其實大部分人都是在一種無目的意識去聽，其實這樣毫無效果或者效果很差。我更傾向於自己主動去學，高手去點播。所以，我下午發起號召成立.net俱樂部，讓每個人都去講都去學習如何當高手。  其實，上去講，是一個非常快的成長過程。在你講之前你需要充分的準備，需要非常努力的去思考，要達到能講出來的功力，基本上也是滾瓜爛熟了。而在講的過程中，會有不同的人從不同的角度去和你討論，又逼迫著

   為了今年的年會，我們組特地趕製了一個電影剪輯外加搞笑配音，大家忙碌了一周終於在晚會前2個小時完成。在匯出的過程中也經曆了無數艱辛，直到晚會前30分鐘才成功的將作品最終完成。沒想到，到了最後關頭，確發現酒店的投影儀根本沒法放視頻，一放視頻就黑屏了。徹底雷翻了。  其實在這之前，行政一直要求IT人員帶自己公司的投影儀到現場，可是IT人員拍著胸脯說全部沒問題，最後發現他啥也沒做就做出了如此承諾，結果到了最後開始前，不僅投影不能用，連音箱都不想了。真是悲劇啊。還好大家興緻較高，沒有繼續計較。 

   幾乎每個周末我都會去新街口的沃爾瑪。一來是帶小盆友去超市玩玩具，二來就是買些日常用品。這家沃爾瑪佔據兩層樓面，其中二樓的一部分劃給了KFC。KFC不大，十幾張桌子，憑藉沃爾瑪的人氣，生意不差。不過後來我才發現，裡面就餐的人很多並不是KFC的客人，而是在沃爾瑪買了便當後偷偷的在這吃飯的。不是KFC不給客戶吃內建食物嗎？為什麼這裡例外呢？  反覆的觀察，讓我確認了這一現象，在這裡確實沒有人來勸阻客人的這一行為，那麼這個現象說明了什麼呢？ 

    很多人都會走上專案經理這條路，不管你是否情願。而這個類似於城管一樣的頭銜，是沒有一個被公開承認的標準的。每個公司都可以按照自己的喜好，根據一定的或者不定的標準來把某個人放在這個位置上。被認可或者被利用，至少還能證明該體驗者有一定的被利用價值，也算是一種被認可把。那麼這樣的安排對於該使用者前後有啥分別呢？    管好自己是不夠的，還得帶著兄弟姐妹們一起沖。儘管領導未必給了你人事權，但是沒有人事權絕對不會被認可為出事後的理由。

  最近在幫一個銀行的朋友張羅招標的事情。這個哥們是高中同學同座位，關係自不一般。而且大學也在不同的學校都念了電腦系，共同語言也較多。不過他走的是學習路線，而我走的是社會路線。現在哥們脫離苦海，到了銀行作甲方去了，而敝人我還在苦熬。  這次招標的事情，也挺好玩，本來有個公司已經差不多定了，但是報價太高，銀行覺得他們太吊，我同學作為項目的負責人也覺得這家公司的態度太傲。那麼為了給自己留個後路，也為自己殺價留點底氣，於是希望我幫忙給他再找兩家備份著，一旦談崩了，則立刻又接班的，免得項目搞黃了，面子上

   事情是這樣開始的。。。  

  在敏捷中，每個產品的開發都是以john smith doc開始的，每個sprint都是以故事開始的。在以前，我通常會要求每個sprint開始前可以把需求確定下來，在衝刺的過程中發生的變更通常是不被輕易接受的，所有重大的改變都需要提交到後續的sprint中進行，但是在仔細琢磨之後，我覺得我應該改變對故事的看法。那麼故事在敏捷中的作用是什麼呢？  

  其實內心真的不想太談這個，可是每每碰到關鍵場合就越發讓人無法忍受。最近因為項目的緣故，來了很多老外，一方面是瞭解一下新成立的團隊，另一點是review一下前段時期的工作。這本身就是很早之前就知道的事情，可是不知道為什麼到了人家來到fice之後，突然加入了一堆事情，又是看代碼，又是安排人家給我們做一些培訓。不僅讓整個團隊措手不及，而且對方也很尷尬。人家四點起床，一臉的疲倦，估計他們也就是來看看南京Office而已，走走過場。結果卻搞的雙方都疲憊不堪。下周還要來更大的頭，結果下午下班前突然然我們

   最近一段時間，因為PO的挑事，我和公司負責Agile推廣的VP做了一次深入的討論。我向她提出了幾個在實踐中遇到的問題，她也耐心的作了回複，而且回複的詳細程度已經到了讓我感動的地步。我本身對流程高度興趣，也曾想過作一個職業的流程推廣者，不過每每想到這位VP，我都不由的感慨，作這行得有巨大的耐心和無比堅定的信心。對舊思想的破除是一項非常吃力而且不容易討好的，短期內很難看到效果的事情。而且，就從我們這邊的實行情況來看，還得無奈的面對陽奉陰違的局面。我不知道自己是不是可以說服自己接受這一切，起碼，

  可能在專案管理中，沒有什麼比半路接個項目更可怕了。幸好這次還有些底氣，是因為自己以前和這個團隊合作過，人頭還比較熟悉，另外就是在公司也算老員工了，各方面人頭比較熟，應該能調動的資源更全面一些。  如果放在傳統項目中，可能進入項目之後的第一件事情就是翻閱文檔。可是在敏捷這樣的大環境中，這些都是奢侈。唯一留下的就是人。所以第一件事情就是儘快評估分析誰是key person。一般來講，BA是整個off

  最近啟動的項目是關於微軟Reporting Service的。公司決定用這個技術取代之前的Crystal report，畢竟這個是免費的。考慮到公司內部沒有人精通此道，所以本著一貫認真謹慎的處理原則，從美國當地找了個顧問，做一些前期的研究和培訓。很長一頓時間內，我們都沒有拿到這個顧問的作品，所以只有憑藉自己的感覺自行研究。微軟的咚咚果然好用，一下子就做出了很多很炫的報表。而且基於自己的理解，對整體架構做了分析和設計。架構也基本成型。可就在這個時候，一次review讓我們頓感哇涼哇涼的。第一，

   事件的起因是每個衝刺最後需要作的回顧。考慮到整個團隊彼此之間實在是太熟悉，經常會出現所謂的集體無意識，我將回顧會議改為每個人事先發給我他的個人意見，我加以整理合并，然後在回顧會議上提出供大家討論補充解釋。這樣就避免了在會上都重複一句話，前面的都說過了，我同意。可是這次，印度那邊的文檔MM卻怒了，因為我們這有人說她前幾故事的文檔稍微延誤，而且都是再說開發與測試高效，從來沒人說過文檔高效，她一個人寫兩個產品線的文檔辛辛苦苦確不被人認可。。。 

  Scrum Master身上背負的一個很重要的職責就是讓回顧會議開的成功，不然就有虎頭蛇尾之嫌，更何談good to great呢？  長期以來我們的回顧會議都是這樣進行的，到點了，大家拿著筆記本進入會議室，一番閑聊之後，主持人開始開啟文件範本，簡單的介紹一下會議的流程，然後簡要的回顧一下這個衝刺我們都承諾了，實際作了什麼，期間發生了什麼。接下來順著座位順序，各自發感想。感想一般都是可以拿之前的拷貝。然後逼不得已的選一個root

   PO就是我們的客戶，客戶就是上帝，上帝的旨意就是天大的事情，我們人類一思考，上帝就忍不住想笑。但是，如果你的上帝會技術，那麼他就不那麼可愛了。  因為，懂技術的人在碰到問題的時候，就會抑制不住的暴露出他的技術情節。這不，當下的這個衝刺，我們的PO在面對介面上出現重複資料的時候，忍不住的要我們解釋SQL的邏輯。。。 

   因為工作性質的關係，需要經常和售後人員打交道。這幾年下來也和不同的售後人員有過溝通合作，期間有愉快也有分歧，對售後這個行業既敬畏又感慨。 

  敏捷也實踐了不少時間，做過的項目從新的feature的開發，到SP,維護，各種類型的項目都用敏捷運作過。每一類型的故事劃分都有其特色。最近新搞了一個團隊，對于敏捷所謂只聞其聲，為見其行。在一次plan

   軟體業發展數十年，開發過程也一代接一代的往前變革著，估計不久就會出現敏捷的下一代。從接觸敏捷開發開始，我的腦海裡就有一個疑問，敏捷開發與傳統製造業有關係嗎？它的理論依據是不是來源於傳統行業呢？直到最近看了一系列關於豐田模式的文章，才算是找到答案。  豐田的生產模式的核心就是精益生產，可以把它看作去除浪費，降低成本，提高效率的精神。時時刻刻以企業的系統性思考為理論基礎。 

最近，正和團隊做集團內A公司X平台向B公司移植，眾所周知，軟體移植項目必然少不了資料轉移——資料從一個地方複製到另外一個地方是再平常不過的需求了。然而B公司老X平台已經上線5,6年，單表上百萬的資料量真是家常便飯，如果僅說讓這些資料能妥善的“安置”到新的平台中，那也很easy，可是讓人頭痛的是海量資料的轉移需要多久？幾個小時？幾個工作日？——因為所有資料轉移的時間的總和等於最終新老平台切換時我們的服務需要停止的時間。拋開項目其它工程不說，如果整個資料轉移需求3,5個工作日，我想別說客戶，產品和業