eric-1001c

            BlogJava :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
            3 隨筆 :: 45 文章 :: 12 評論 :: 0 Trackbacks
          Form: http://blackanger.blog.51cto.com/140924/66305

          今天和一個在諾基亞工作過的朋友聊Scrum,諾基亞推廣Scrum有兩年多,和他交流學(xué)到了很多東西,給大家分享一下:

          ---------
          一段寒暄之后。。。

          (19:58:23) i: 諾基亞用Scrum有多長時間了阿
          (19:58:24) he: 算是用過.呵呵
          (19:59:06) he: 整個公司推行這個大概也有兩年的樣子
          (19:59:18) he: 不過具體到我這邊大概是一年多
          (19:59:21) i: 時間也不算短
          (19:59:58) i: 那你給我說下那邊的情況怎么樣:D
          (20:00:36) he: 其實怎么說呢...N記以前的風(fēng)格都是作坊型的
          (20:00:49) he: 每個產(chǎn)品組就是個小作坊,所以風(fēng)格各異
          (20:01:01) he: 有的適應(yīng)Scrum就快一些,有的就有些走樣
          (20:01:16) i: 那你所在的小作坊怎么樣
          (20:01:19) i: 呵呵
          (20:02:06) he: 不過不管最后是不是有些走樣,還是有些好處
          (20:02:20) i: 具體流程呢
          (20:02:31) he: 其實主要原因是它原來還有一套標準的產(chǎn)品立項, 開發(fā), 測試,
          發(fā)布流程.
          (20:02:41) he: 然而又要把Scrum硬套到中間去
          (20:02:55) he: 這中間其實就得看執(zhí)行的團隊和個人權(quán)衡了
          (20:02:58) i: 這樣是好還是不好。
          (20:03:17) he: 是這樣
          (20:03:56) he: 簡要的來講,原來的發(fā)布流程是: 可行性研究 -> 立項 -> 開發(fā)
          -> 測試 -> 試用 -> 發(fā)布
          (20:04:26) i: 使用scrum以后是。。
          (20:05:08) i: 具體流程是否嚴格按Scrum的規(guī)則來做的呢
          (20:05:37) he: 那么...想把Scrum嵌入到開發(fā)這個階段去
          (20:06:00) i: 恩
          (20:06:00) he: 對外面來說原來的那套流程就不變...
          (20:06:08) he: 所以有些地方就被框得很死
          (20:06:24) i: 比如。。
          (20:06:39) he: 如果團隊只在開發(fā)這個周期做一兩個迭代...那么就退化得跟原
          來的流程差不多了

          (20:07:05) i: 我感覺Scrum可以替代這整個流程吧。
          (20:07:20) he: 嗯:)不過那不是我能改變的
          (20:07:43) i: 那你個人認為流程該怎么改變才比較好
          (20:07:55) i: 就拿N以前的這個為例子
          (20:08:07) he: 前四個其實都可以
          (20:08:24) he: 不過因為剛推行的時候大家都對Scrum沒有底
          (20:08:38) he: 上邊也不愿意去把新東西搞得那么激進
          (20:09:53) i: 可是我感覺把開發(fā)那個環(huán)節(jié)采用scrum也算是正確的吧,因為前
          面的可行性研究方面如何去scrum呢
          (20:10:33) he: 嗯,可行性研究的意思
          (20:10:44) he: 其實就是抽兩三個最精干的人
          (20:10:51) he: 組成一個預(yù)研的小team
          (20:11:08) i: en
          (20:11:17) he: 然后在給定的時間內(nèi)把PM還沒有把握的功能作出demo來驗證一
          條路能不能走通
          (20:11:23) he: 其實是滿適合Scrum的
          (20:11:32) he: 個人覺得:)
          (20:11:38) i: 恩,有道理
          (20:12:05) i: Scrum這個概念到是不僅僅拘泥于開發(fā)
          (20:12:16) he: 然后這些小feature的demo就會支持之后的立項申請,才能拿到
          經(jīng)費
          (20:12:42) i: 那現(xiàn)在諾基亞的scrum還是在開發(fā)環(huán)節(jié)上嗎
          (20:13:02) he: 是的
          (20:13:21) i: 那現(xiàn)在是算成功呢,還是。。。
          (20:13:26) he: 據(jù)我了解多數(shù)是
          (20:13:45) he: 嗯,不管怎么說, 它并不像一個原來標準的樣子, 作了某些妥協(xié)
          (20:13:45) i: 對了,和你分享一本書
          (20:13:55) he: 但我覺得還是提高了效率的:)
          (20:14:16) he: 雖然,很大程度上取決于團隊和個人自覺程度
          (20:14:56) i: 你說,假如讓你在一個下團隊里去實施Scrum,你會如何做呢
          (20:15:22) i:
          http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
          今天在infoq看到這本書。
          (20:15:41) he: 呵呵, 這本我有PDF
          (20:16:10) i: 噢。。。
          (20:16:13) i: hehe
          (20:16:26) he: 不過沒看完:)
          (20:16:33) i: 說說你的想法,關(guān)于我剛才那個問題
          (20:17:41) he: 是這樣, 我以前帶的團隊通常都是在預(yù)研之后接手的
          (20:18:08) he: 所以在這個階段之前, 主要還是和Product Manager討論他的需

          (20:18:24) he: 您可以把N記的Product Manager看作一個內(nèi)部客戶
          (20:18:30) i: 恩,那些backlog要列出來嗎
          (20:18:46) he: 還不到Backlog那里....
          (20:18:53) i: 好,你繼續(xù),呵呵
          (20:19:06) he: Product Manager會提出從他自己的角度出發(fā)最看重的需求
          (20:19:26) he: 這些需求也許是很簡短的表述,就像一個帶場景的user story
          (20:19:33) i: 恩
          (20:19:47) he: 因為他不會很關(guān)心技術(shù), 他更多的代表市場
          (20:20:58) he: 所以他的需求也許是這樣子的:
          節(jié)點A將支持靈活的存儲設(shè)備, 自動監(jiān)測客戶給與的存儲設(shè)備數(shù)量并作出按比例
          xx:xx的空間占用

          (20:21:21) i: 對,只是個user story
          (20:21:31) i: 下一步呢
          (20:21:55) he: 或者當(dāng)用戶B的voice傳輸?shù)焦?jié)點C時,將自動監(jiān)測其媒體類型并
          做出質(zhì)量和編碼的變換
          (20:22:27) he: 這些user story, 我們通常會在他的會議上先記下來, 整理成
          一個list
          (20:22:50) he: PM會給出他看重的優(yōu)先級
          (20:23:07) i: 客戶給出優(yōu)先級 ?
          (20:23:38) he: 對的, 比如說, 就相當(dāng)于問他: 您最希望在第一個demo day中
          看到的是哪一個feature?
          (20:23:43) i: 而不是我們分析需求去列出優(yōu)先級,明白
          (20:23:48) he: 或者您最希望推向市場賣的是哪一個
          (20:23:54) i: 恩
          (20:23:58) he: 是的,它首先是面向feature的
          (20:24:04) he: 然后...我們不能全都答應(yīng)
          (20:24:27) i: 為什么
          (20:24:44) i: 可以分迭代來做吧
          (20:24:59) he: 我們需要與做feasibility study的team溝通,看看他所提出的
          要求是不是都能實現(xiàn),或者能否以可以接受的代價實現(xiàn)

          (20:25:22) i: 噢
          (20:25:48) i: 怎么又回到第一環(huán)節(jié)了
          (20:25:59) he: 如果不能實現(xiàn), 我們可以進一步跟他確認: 您看, 你所說的
          feature是A, 但是我們覺得您更需要的可能是A+
          (20:26:28) he: 或者, 您看, 在給出的開發(fā)周期內(nèi)A不能全都實現(xiàn), 是否可以先
          實現(xiàn)A- ...
          (20:26:58) he: 或者當(dāng)前的平臺對于實現(xiàn)A有所限制, 我們可以給您提供兩個參
          考: A1 或者A2
          (20:27:11) he: 有的時候他或者她都會咆哮...
          (20:27:13) i: 恩,應(yīng)該是增量式開發(fā),一步步完成客戶的需求
          (20:27:28) i: 呵呵
          (20:27:30) he: 或者我們雙方都在咆哮...
          (20:28:17) he: 那么也許最后達成的結(jié)果可能會是我們需要在第一個demo中作
          出a, 然后同時等待另外一個team的組件b的效果, 如果不行,那么backup可能是
          c...
          (20:28:57) he: 這個妥協(xié)后的結(jié)果通常被稱為product feature backlog
          (20:29:24) he: 它對于技術(shù)細節(jié)關(guān)注很少,主要關(guān)注最后能完成的feature
          (20:29:34) i: 噢
          (20:30:02) i: 這個時候到sprint計劃會議來細分這些backlog了吧
          (20:30:06) he: 客戶在交貨或者中間確認進度的時候看的通常都是feature
          backlog
          (20:30:45) he: 是的, 通常之后每個feature team都會召集起來開會
          (20:30:55) he: 也就是Scrum team
          (20:31:08) he: 將每個feature都分解為技術(shù)上實現(xiàn)的步驟
          (20:31:32) i: 然后細分出來交給團隊。
          (20:31:35) he: Scrum Master 會將這些步驟作為一個個TASK紀錄
          (20:31:45) he: 不是細分出來交給團隊...
          (20:32:01) he: 這個時候每個團隊都參與進來看自己的那部分feature backlog

          (20:33:05) i: Scrum Master 記錄那些task做什么。
          (20:33:07) he: 成員王小花可能會說...我覺著吧,要實現(xiàn)feature A 可能我們
          需要先在后段存儲s上實現(xiàn)一個抽象層InfA
          (20:33:22) he: 它需要routine A1 A2 A3來做
          (20:33:31) he: 王二麻子可能反對...
          (20:33:46) i: 呵呵。
          (20:33:59) he: 說我覺著我們只需要服用組件B和組件C提供的服務(wù)接口InfB1和
          InfC2...
          (20:34:20) he: 然后給一個帶路由表的配置文件...
          (20:34:30) i: 那這個會議最終目標是要干什么,或者說要得到什么結(jié)果
          (20:34:53) he: 最后的這些task, 就會形成一個周期內(nèi)的sprint backlog
          (20:35:13) he: 能力越好的團隊, 所能細分出來的task越精確
          (20:35:19) i: 噢,是指定backlog的過程
          (20:35:27) he: 通常粒度控制在20h
          (20:36:28) i: 如果需求有變的情況如何處理
          (20:37:02) i: 在迭代的時候
          (20:37:14) he: 嗯...我記得上次某大師來講座的時候我們也問過
          (20:37:35) i: 呵呵,怎么回答的
          (20:37:45) he: 他的答案是標準做法是繼續(xù)把sprint做完,然后在接下來的一個
          sprint中完成變動
          (20:38:11) i: 明白了。。。
          (20:38:37) i: 那迭代期間你們有每日例會吧
          (20:39:02) he: 是的, daily meeting
          (20:39:25) i: 對了,你們是不是也這樣處理需求的變化,放在下個sprint里
          (20:39:47) he: 不是
          (20:39:53) he: 我們的sprint 周期長達一個月..
          (20:40:10) i: Scrum里規(guī)則是一個月。。。
          (20:40:17) i: 那。。。
          (20:40:19) he: 所以通常我們有drop一個舊的和add一個新的
          (20:40:42) he: 除了通常比較簡化的Not Started. On Going和Done 三個狀態(tài)
          之外
          (20:40:56) he: 我們有Dropped和Added
          (20:42:07) i: 噢,這樣處理也很科學(xué)
          (20:42:46) he: 呵呵:)因為有時候一個月還是太長
          (20:43:00) he: 因為對于兩地或者三地之間的協(xié)同開發(fā)
          (20:43:06) he: 一個月可以發(fā)生的事情太多了
          (20:43:23) he: 尤其是這幾個地方都有時差的時候
          (20:43:47) i: 不過迭代沒有完成的話,也許客戶不清楚自己需求的變更是好
          是壞,大師那么說也有道理吧。迭代完成,讓客戶看了以后他再看是否變化需求。
          (20:44:02) i: 我說的有沒有可能 ?
          (20:44:30) he: 是的:)
          (20:45:06) he: 但是有時候需求確實很急...
          (20:45:09) i: 具體應(yīng)用具體處理吧,起碼有了處理的辦法。
          (20:45:13) i: 恩
          (20:45:19) he: 比如突然拿某移動的單
          (20:45:27) he: 而該客戶以需求怪異著稱
          (20:45:34) i: 呵呵
          (20:45:38) he: 這種情況不一定非得等到下一個...
          (20:45:45) i: 確實
          (20:45:55) i: 擁抱變化
          (20:46:29) he: 其實我覺得很依賴團隊成員的
          (20:46:36) he: 如果團隊成員很不積極
          (20:46:36) i: Scrum的規(guī)則也應(yīng)該是符合實際情況的經(jīng)驗性方法才能發(fā)揮能
          量。
          (20:46:47) i: 個人敏捷性
          (20:46:55) he: 那么sprint planning就會死氣沉沉變成任務(wù)指派...
          (20:47:09) i: Scrum里面說自我管理
          (20:47:31) i: 如何調(diào)動成員的積極性來更好的團隊自我管理
          (20:49:18) he: 其實原來我?guī)У膖eam比較實際一點....
          (20:49:23) he: 每個sprint都有demo...
          (20:49:29) i: 那天在infoq上看了一篇文章,關(guān)于這個問題,是說團隊成員的
          主人翁精神不夠
          (20:49:38) i: 恩,你繼續(xù)
          (20:49:53) he: 大家通常都很期望demo day那天PM發(fā)話說: 嗯,對的,我就是想
          要這個
          (20:50:10) he: 如此以來...整個team就能申請預(yù)算出去大吃大喝了
          (20:50:20) he: 因為整個team都比較好吃...
          (20:50:23) i: 呵呵
          (20:50:29) he: 成都好吃的地方很多,也不很貴
          (20:50:39) i: 好吃不懶做
          (20:50:58) he: 嗯,總的來說,就是得有promotion:)
          (20:51:05) he: 我個人覺得
          (20:51:29) i: 一些物質(zhì)激勵
          (20:52:10) he: 呃..其實也不限于這個...物質(zhì)
          (20:52:28) he: 您說:)
          (20:53:06) i: 比如一起出去游山玩水,放松個一兩天
          (20:53:19) he: 嗯
          (20:54:10) i: 對了,你們用看板沒有
          (20:54:39) i: 是有專門的系統(tǒng)還是手工看板
          (20:55:38) he: 哦.有一間屋專門換了玻璃板的...
          (20:55:50) i: 常用嗎
          (20:55:53) he: 四面墻可以亂涂亂畫....
          (20:56:03) he: 嗯,經(jīng)常:P
          (20:56:08) i: 呵呵
          (20:56:21) i: 我們這方面做的不太夠
          (20:56:25) he: 針對team里年輕人表現(xiàn)欲都比較強的特點
          (20:56:31) he: 我們劃出一面墻來
          (20:56:40) he: 當(dāng)月sprint完成的最好的年輕人
          (20:56:46) he: 有權(quán)占有那面墻...
          (20:56:53) i: 呵呵
          (20:57:02) he: 只要不寫的太反動...隨便他怎么規(guī)劃
          (20:57:04) i: 涂鴉嗎
          (20:57:08) he: 嗯.差不多
          (20:57:25) he: 對羞澀性隊員的效果可能就差一些
          (20:57:33) i: 挺有意思
          (20:57:54) he: :)
          。。。
          end
          posted on 2008-08-20 15:56 Eric-1001c 閱讀(232) 評論(0)  編輯  收藏 所屬分類: Agile

          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導(dǎo)航:
           
          主站蜘蛛池模板: 射阳县| 揭阳市| 仪征市| 资溪县| 皮山县| 兴城市| 宿松县| 通河县| 溧水县| 阜城县| 石楼县| 革吉县| 庆云县| 巴彦淖尔市| 平南县| 三明市| 时尚| 江川县| 台州市| 承德市| 武冈市| 临汾市| 乐昌市| 额敏县| 镇江市| 弋阳县| 息烽县| 孟连| 山东省| 德兴市| 台山市| 许昌县| 略阳县| 龙井市| 大冶市| 江津市| 六枝特区| 西畴县| 韶山市| 瓦房店市| 唐海县|