談禪論道第四期:敏捷如何應對變化的需求-短周期迭代

2011-01-14 09:55:05
禪道社區
轉貼
11695

談禪論道第四期于2011年1月13日12:30 - 14:00順利舉行,andy老師就敏捷如何應對變化的需求給大家做了精彩的分享,andy老師對scrum在中國的實施有很多自己獨到的經驗和觀點,請細細品味。

聊天記錄:

2011-1-13 12:29:46 青島-王春生<[email protected]>

談禪論壇第四期,正式開始。:)

2011-1-13 12:30:13 青島-王春生<[email protected]>
本期我們榮幸的邀請到敏捷專家袁斌老師來和大家互動。袁斌(Andy Yuan)先生,是工學碩士,MBA,Scrum、AUP、Agile modeling、XP、Kanban等的實踐者。迅思威爾咨詢總監。10余年中就職于全球性公司從事軟件和產品的開發。曾任Anoto產品中國區開發總監和Mino中國區軟件開發總監,利用Scrum成功實現產品快速交付,在電信行業、外包團隊、互聯網產品的敏捷開發,Scrum團隊建設,Scrum在小型、大型團隊的應用等方面積累了豐富的經驗。

2011-1-13 12:30:41 青島-王春生<[email protected]>
呵呵,本期交流的話題是: 敏捷如何應對變化的需求-短周期迭代

2011-1-13 12:31:07 袁斌<[email protected]>
大家好,叫我andy,或者老袁,都是OK的

2011-1-13 12:31:22 袁斌<[email protected]>
工作照了,呵呵

2011-1-13 12:31:23 青島-王春生<[email protected]>
形式是這樣:哈哈,先有袁老師給大家分享他的心得體會。

2011-1-13 12:31:44 青島-王春生<[email protected]>
然后是互動環節。:),下面有請袁老師。

2011-1-13 12:32:04 袁斌<[email protected]>
那我們開始了

2011-1-13 12:32:41 袁斌<[email protected]>
主要的內容都在我發的那個pdf文件中

2011-1-13 12:32:57 袁斌<[email protected]>
我現在對每一頁做相應的說明

2011-1-13 12:33:08 袁斌<[email protected]>
任何問題,可以隨時交流

2011-1-13 12:33:16 袁斌<[email protected]>
第一頁說明需求為什么會變化,例如互聯網產品,游戲產品,需求是和市場反饋反復交互而得,也有人說:游戲不是做出來的,是改出來的,獲得市場反饋的頻率和更早的時間對產品至關重要右下角的圖,說明我們需要更關注business value更高的需求,否則會影響我們的開發成本,系統維護以及關鍵的上市時間。我們經常加班是否在為那些不為客戶重視的可有可無的功能?

2011-1-13 12:34:00 袁斌<[email protected]>
大家有這個文檔吧:敏捷如何應對變化的需求-短周期迭代-禪道.pdf

2011-1-13 12:34:13 青島-王春生<[email protected]>


2011-1-13 12:35:38 青島-葉文濤(709808807)
有了

2011-1-13 12:34:52 袁斌<[email protected]>
第二頁舉例,有12個需求要完成,時間為6個月,按照傳統的瀑布方法有一些問題,開始編碼的時候被要求增加兩個需求,同時被告知R5可以不做了(或者在二期),客戶參加測試階段說R9要改一些,后發布的時間到了,但有兩個需求測試的bug處于發散狀態,無法發布. 發散狀態,是指改了一個bug,引發了兩個bug要緊的是,在第三個月,發現競爭對手有動作,我們需要提前發布一些功能,以提前占領市場,但此時我們無法在第三個月發布一個產品,因為我們還沒有做任何測試。

2011-1-13 12:35:17 青島-王春生<[email protected]>


2011-1-13 12:37:17 袁斌<[email protected]>
第三頁是說明敏捷的方式如何短周期迭代發布,以解決第二頁的問題左邊一列還是初的需求左邊第二列是按照優先級排序后的需求列表R2'是在第一個迭代周期結束時,客戶要求將R2改成R2',即R2的需求有一些變化,R9同理紅色是為了表示在第一次按照business value排列優先級的需求優先級的改變藍色是第二次迭代時需求優先級排列后的改變綠色是第三次迭代是需求的排列變化

2011-1-13 12:37:41 青島-王春生<[email protected]>
  

2011-1-13 12:39:32 袁斌<[email protected]>
從第二次迭代開始,每一次迭代的交付物都是可以上線的軟件每一次迭代,可以在1~4周選擇這個是迭代周期,如果測試成本比較大,或者第一次用敏捷,建議4周為迭代周期因為迭代的交付物是100%完成的,即測試是沒有問題的可以看到,在第二次迭代結束后,我們可以交付R1,R2',R9'Ra,Rc5個需求的產品此時我們對其他需求沒有編碼第二個迭代中包含了優先級高的需求,同時還有用戶改變的需求,重要的是,如果在第二個月需要上線,我們也可以做到

2011-1-13 12:41:30 深圳-李劍(574799707)
第二個迭代中包含了優先級高的需求?

2011-1-13 12:41:41 袁斌<[email protected]>
第三個迭代,用戶或者產品經理要求增加2個需求(R10,R11),這兩個需求是至關重要的,可能是競爭對手的壓力,也可能是政策壓力OK,其他的需求先不考量,就做這兩個以上的迭代開發內容選擇一個是需求優先級排列后的列表一個是開發團隊的工作能力,這兩個是參考因素

2011-1-13 12:42:18 袁斌<[email protected]>
to 李劍,是的,每一次迭代都是包含優先級高的需求

2011-1-13 12:42:36 青島-王春生<[email protected]>
對的。每個迭代都是當下優先級高的需求。:)

2011-1-13 12:43:15 袁斌<[email protected]>
可以看到,第二次迭代開始,product backlog是重新排序的

2011-1-13 12:43:38 袁斌<[email protected]>
Ra的優先級提高了

2011-1-13 12:45:36 袁斌<[email protected]>
第三次迭代,R5需求刪除了

2011-1-13 12:45:31 北京-許進義(14917275)
剛才那幅圖沒完全理解,第一次迭代包含的需求從哪里看出來?

2011-1-13 12:45:52 袁斌<[email protected]>
好在我們沒有effort在R5上

2011-1-13 12:46:13 青島-王春生<[email protected]>
  

2011-1-13 12:46:19 青島-王春生<[email protected]>
我的理解,應該是這個吧。

2011-1-13 12:46:22 北京-W(13808432)
春生,將袁老師的講解和應征的PPT關聯起來吧

2011-1-13 12:46:22 袁斌<[email protected]>
是的

2011-1-13 12:46:47 袁斌<[email protected]>
第一次迭代,需求列表已經做了優先級的排序

2011-1-13 12:46:55 青島-王春生<[email protected]>
  
左邊是原始的需求,右邊是第一次排序的結果。

2011-1-13 12:47:07 青島-王春生<[email protected]>
我理解沒錯吧?:)

2011-1-13 12:48:31 青島-葉文濤(709808807)
覺得這個形式就好理解 了

2011-1-13 12:47:20 北京-許進義(14917275)
哦,這樣就明白了,謝謝

2011-1-13 12:47:31 袁斌<[email protected]>
完全正取:)

2011-1-13 12:47:33 青島-王春生<[email protected]>
所以選擇了前面三個,作為第一次迭代的需求列表。

2011-1-13 12:47:35 袁斌<[email protected]>
正確

2011-1-13 12:47:52 33(598920549)
那第一次對需求的排序應該非常重要

2011-1-13 12:48:07 袁斌<[email protected]>
迭代開發內容選擇一個是需求優先級排列后的列表一個是開發團隊的工作能力,這兩個是參考因素

2011-1-13 12:48:31 青島-王春生<[email protected]>
排序應該是每次迭代都要做的。:)而且需求列表也是在不斷的變化的。

2011-1-13 12:48:32 青島-王春生<[email protected]>
  

2011-1-13 12:49:03 青島-王春生<[email protected]>
這是第二次迭代開始的時候,左邊是新的需求列表,增加了幾個新的需求。重新排序,然后選擇了r2', r9',ra, rc

2011-1-13 12:48:59 北京-許進義(14917275)
嗯,在一次迭代的過程中,需求以及優先級可能發生變化

2011-1-13 12:50:03 青島-王春生<[email protected]>
這一頁應該沒有啥問題了吧。andy,繼續?:)

2011-1-13 12:50:13 北京-許進義(14917275)
如果在Sprint 1過程中,R1發生了變化,該如何處理?

2011-1-13 12:50:23 袁斌<[email protected]>
第四頁,由于4周內要完成可以工作的軟件,所以必須盡早的發現bug敏捷希望代碼的bug發現盡可能早圖中綠色的是敏捷在推薦圖表示發現bug的時間和修改bug的成本關系結對編程和持續集成是有效的結對編程褒貶不一我們實踐的推薦是:2個人負責兩個需求而不是一個人負責一個需求

2011-1-13 12:51:36 青島-王春生<[email protected]>
  

2011-1-13 12:52:19 青島-王春生<[email protected]>
>>>如果在Sprint 1過程中,R1發生了變化,該如何處理?先記下來。一會討論。:)

2011-1-13 12:52:37 袁斌<[email protected]>
北京-許進義(14917275) 12:50:13如果在Sprint 1過程中,R1發生了變化,該如何處理?如果是小的變化,例如排序原則改一下,是OK的,但如果是業務邏輯發生大的變化,需要重新估算工作量。如果不能在這個sprint內完成,則和PO商議在下一個sprint完成。

2011-1-13 12:53:09 北京-許進義(14917275)
謝謝,請繼續

2011-1-13 12:53:22 青島-王春生<[email protected]>
我翻譯下綠色:結對編程,持續集成,測試驅動開發,下面三個就不知道了。

2011-1-13 12:54:04 袁斌<[email protected]>
是其他敏捷方法推薦的,例如Agile Modeling等

2011-1-13 12:54:13 袁斌<[email protected]>
其實前兩個實用

2011-1-13 12:54:17 北京-許進義(14917275)
關于Model Storming了解不多,能否介紹一下?

2011-1-13 12:54:33 青島-王春生<[email protected]>
客戶積極參與?

2011-1-13 12:54:36 袁斌<[email protected]>
TDD的推廣還是有很大難度的,在國內應用也不多

2011-1-13 12:55:26 青島-王春生<[email protected]>
是的,tdd的理念太具有挑戰性了。

2011-1-13 12:55:24 北京-許進義(14917275)
Stakeholder我理解的是業務人員,實際使用系統的人或他的領導,

2011-1-13 12:56:21 青島-王春生<[email protected]>
stakeholder是利益相關者.應該可以對應到敏捷宣言里面的客戶合作。[表情]

2011-1-13 12:56:28 袁斌<[email protected]>
  

2011-1-13 12:56:24 北京-許進義(14917275)
從我所在的銀行核心系統項目來看,傳統的開發成本比TDD一點都不少,但是推廣TDD確實有很大難度

2011-1-13 12:56:42 袁斌<[email protected]>
一些stakeholder的例子

2011-1-13 12:57:13 北京-許進義(14917275)
跟UML里面的定義是一致的?

2011-1-13 12:57:28 青島-王春生<[email protected]>
呵呵,學習了。

2011-1-13 12:57:51 袁斌<[email protected]>
沒有本質區別,都是項目干系人

2011-1-13 12:57:56 青島-王春生<[email protected]>
andy, unitesting是否可以單獨列出來?

2011-1-13 13:01:00 青島-葉文濤(709808807)
是不是bug及時發現后,針對bug所涉及的利益相關權重進行優先修復啊

2011-1-13 12:59:56 袁斌<[email protected]>
unittesting是非常常用的一種做法,在實際中UT用的很多

2011-1-13 13:00:39 青島-王春生<[email protected]>
通過敏捷的一些實踐,盡可能早的發現bug,這樣解決的成本就會很低。accepting tetstingsystem testingpreview or 后面的那個單詞認不出來了。這幾個階段里面發現的bug,成本就會大大增加。

2011-1-13 13:00:44 青島-王春生<[email protected]>
這是我的理解。hoho

2011-1-13 13:01:36 袁斌<[email protected]>
bug是分優先級的,一些critical的bug一定要先處理,有時候minor的bug放在以后的版本再處理也是可以的

2011-1-13 13:02:04 北京-許進義(14917275)
傳統的開發流程中,往往是critical的是難發現,也是后才發現的

2011-1-13 13:02:35 南京-張小狂(54518545)
對于管理類應用系統,領導的需求變化,不夠明確,要求比較多,要求快速應對,有時感覺不知所措了

2011-1-13 13:03:44 南京-張小狂(54518545)
對于敏捷開發,TDD,需要測試與架構設計師,業務人員共同構建業務框架,然后由開發人員向里面塞代碼

2011-1-13 13:04:16 袁斌<[email protected]>
to 張小狂, 先做一個版本,包含領導總念叨的幾個需求,讓領導先用一下,引導他的思路,試試

2011-1-13 13:04:16 南京-張小狂(54518545)
由測試、業務人員判斷輸入與輸出的符合性

2011-1-13 13:04:46 青島-王春生<[email protected]>
to小狂,咱們先繼續。一會可以展開討論。:)

2011-1-13 13:04:59 青島-王春生<[email protected]>
andy,繼續后一頁?

2011-1-13 13:05:08 袁斌<[email protected]>
第五頁,是敏捷理論和國內現狀沖突的解決方案PO和團隊之間的溝通不主動,需求理解的不同導致迭代結束時無法交付符合需要的軟件原因分析:Scrum建議在每一個迭代結束前有一次交付演示,團隊向Product Owner(以下簡稱PO)演示此次交付的功能,由PO決定交付是否滿足需求。PO和團隊在開發周期內的主動溝通是交付滿足需求的一個重要前提條件,而在國內項目組中雙方的主動溝通意愿都不是很強烈,這是導致需求理解不一致的重要原因,而一次演示會讓這個風險在迭代結束時才被發現。解決方案:完成一個需求即向PO演示,判斷交付和需求的切合度,并同時分析其它需求的理解PO和團隊是否有不同之處,及時改進。解決方案的好處是增加演示的頻率來“強迫”溝通需求的意愿,逐步形成較好的溝通習慣,同時盡早發現被忽略的需求細節。

2011-1-13 13:06:00 青島-王春生<[email protected]>


2011-1-13 13:08:15 袁斌<[email protected]>
我要描述的內容就這些了, free talking...

2011-1-13 13:08:22 北京-許進義(14917275)
實際項目中很多PO不一定能完全明確需求,在有客戶業務人員參與的情況下,PO的范圍是不是也可以包含客戶的業務人員?即每次演示都邀請客戶業務人員參加?

2011-1-13 13:08:39 青島-王春生<[email protected]>
呵呵,大家估計都攢著好多問題,來吧!

2011-1-13 13:09:10 北京-許進義(14917275)
包括客戶的業務人員,也需要在引導下才能說出真實的需求;這時的演示,就是一種引導,是不是可以這樣理解?

2011-1-13 13:09:38 袁斌<[email protected]>
實踐中PO往往是弱的一環,所以“每次演示都邀請客戶業務人員參加”,太可以了

2011-1-13 13:09:51 北京-許進義(14917275)
O(∩_∩)O

2011-1-13 13:10:24 袁斌<[email protected]>
很多時候,“Scrum master”和業務分析人員也會和PO一些分析需求

2011-1-13 13:10:19 北京-許進義(14917275)
原來大牛也覺得PO缺... ...

2011-1-13 13:10:35 青島-王春生<[email protected]>
演示其實很多人都可以參加,但po就只能是就是那個角色吧。

2011-1-13 13:10:51 青島-王春生<[email protected]>
po應當來整理放方方面面的反饋,形成story 列表。

2011-1-13 13:11:08 袁斌<[email protected]>
PO有時候會有一個組,共同決策,特別在新的行業產品。例如移動互聯網,變化很快

2011-1-13 13:11:20 北京-許進義(14917275)
嗯,這下明確了,

2011-1-13 13:11:39 青島-王春生<[email protected]>
恩,很好的方案。

2011-1-13 13:12:19 青島-王春生<[email protected]>
大家有問題,趕緊問[表情]

2011-1-13 13:12:15 北京-許進義(14917275)
與產品經理這一角色的區別?

2011-1-13 13:12:38 袁斌<[email protected]>
“這時的演示,就是一種引導,”,可以這樣理解,客戶看到實際的系統后思路才會更清晰

2011-1-13 13:12:54 袁斌<[email protected]>
同時在這個時刻,也容易改變需求

2011-1-13 13:13:39 北京-許進義(14917275)
嗯,項目中發生過幾次這樣的情況;這時開發人員就會感覺業務人員說了不算,當初明明說的不是這個意思,業務人員就覺得他就是這個意思,是開發人員理解錯了,

2011-1-13 13:13:49 袁斌<[email protected]>
讓“改變需求”的事情發生越早,風險和成本越小

2011-1-13 13:15:27 項目管理(397528046)
大家好

2011-1-13 13:15:34 項目管理(397528046)
請問開始討論了么?

2011-1-13 13:15:30 北京-許進義(14917275)
通過以上問題,對PO的理解更深刻了,謝謝Andy。是不是可以開始下一個問題?

2011-1-13 13:15:52 袁斌<[email protected]>
  

2011-1-13 13:16:15 袁斌<[email protected]>
這是PO和傳統產品經理的一些區別

2011-1-13 13:16:59 沈陽-海岸
[表情] 為什么這些資料都是英文的。

2011-1-13 13:17:03 袁斌<[email protected]>
包含了一些個人理解,和大家分享,討論

2011-1-13 13:17:14 項目管理(397528046)
我剛進來 沒有看到之前的內容

2011-1-13 13:17:28 項目管理(397528046)
不知道討論的進程是怎樣的

2011-1-13 13:17:21 北京-許進義(14917275)
嗯,這個還需要多理解一下,

2011-1-13 13:18:37 青島-葉文濤(709808807)
可以用中文點一下重點么,袁老師?

2011-1-13 13:18:06 青島-王春生<[email protected]>
1. 傳統的要擔任多個角色,scrum里面的 PO單一角色。

2011-1-13 13:18:11 袁斌<[email protected]>
哦,我做的培訓資料是英文的,主要是因為有一些外企的客戶,我自己偷懶了

2011-1-13 13:18:30 袁斌<[email protected]>
沒有做中文的:)

2011-1-13 13:18:31 青島-王春生<[email protected]>
2. 傳統的和開發團隊脫離,scrum里面和sm和團隊緊密合作溝通。

2011-1-13 13:18:51 青島-王春生<[email protected]>
3. 不理解。hoho

2011-1-13 13:18:45 北京-許進義(14917275)
個人英語也不好,但是我贊同使用英文

2011-1-13 13:19:16 大連-Flashing(908222)
SM需要coding嗎

2011-1-13 13:19:30 青島-王春生<[email protected]>
4. 傳統的需求非常詳細,而且很做凍結,scrum里面的需求完善是一個持續的過程。

2011-1-13 13:19:55 袁斌<[email protected]>
3. 傳統的是在產品開始之前做非常多的市場調查,產品計劃很詳盡

2011-1-13 13:20:14 項目管理(397528046)
關于Scrum,我一直有一個很困惑的問題,就是如何有效的編寫product backlog?我的理解中,需求是通過product backlog來描述的,但是對于一個具體項目的需求,如何清晰有效的描述呢?

2011-1-13 13:20:14 青島-王春生<[email protected]>
5. 傳統的反饋很晚,而scrum則很早。持續的進行。

2011-1-13 13:21:23 ㊣(28937095)
scrum和CMMI的區別主要在那里?

2011-1-13 13:21:33 北京-許進義(14917275)
Scrum的product backlog對于習慣傳統需求文檔的人來說,感覺很簡略,擔心不能準確覆蓋

2011-1-13 13:21:59 項目管理(397528046)
我同意需求分析是一個需要持續完善的過程

2011-1-13 13:22:02 袁斌<[email protected]>
Product backlog,在scrum中沒有說明必須用user story

2011-1-13 13:22:18 袁斌<[email protected]>
user case也可以用的

2011-1-13 13:22:41 項目管理(397528046)
但是 對于一個項目而言 有很多需求是已知的 很明確的

2011-1-13 13:22:43 ㊣(28937095)
Scrum的product backlog 不單擔心覆蓋,還覺得沒有個系統的體現!

2011-1-13 13:23:20 項目管理(397528046)
user case只能覆蓋一部分需求

2011-1-13 13:23:20 袁斌<[email protected]>
user story更適合和客戶交流需求,和在sprint planning中交流

2011-1-13 13:23:27 北京-許進義(14917275)
product backlog系統的體現,就在演示的demo上,以及wiki

2011-1-13 13:24:31 項目管理(397528046)
此外,按照Scrum的方法,對于需求進行分解跟蹤就不現實了

2011-1-13 13:25:22 袁斌<[email protected]>
項目管理(397528046) 13:24:31此外,按照Scrum的方法,對于需求進行分解跟蹤就不現實了可以詳細一些嗎?

2011-1-13 13:25:41 青島-王春生<[email protected]>
他這兒說的需求,我想應該是一個很大的東西。

2011-1-13 13:25:50 項目管理(397528046)
我的理解是,如果不能把需求有效的分解為單一的原子功能,就不能實現從需求到設計到實現和測試的一系列跟蹤行為

2011-1-13 13:26:42 北京-許進義(14917275)
敏捷中“原子功能”對應的應該是task,需求的跟蹤是類似wiki這樣的形式,不知道我的理解對不對

2011-1-13 13:27:26 項目管理(397528046)
我這兒所說的需求,指的就是某一個項目完整的客戶要求

2011-1-13 13:27:27 青島-王春生<[email protected]>
原子功能,我理解應該是user story,task是實現。

2011-1-13 13:27:46 北京-許進義(14917275)
噢,對,不應該是task

2011-1-13 13:28:15 項目管理(397528046)
如果原子功能是user story的話 那么一個story會不會太過于復雜?

2011-1-13 13:28:19 青島-王春生<[email protected]>
客戶的要求,應該要整理細分成user story。

2011-1-13 13:28:19 北京-許進義(14917275)
完整的客戶要求,就是一個大的story,需要拆分成多個小的story

2011-1-13 13:28:34 青島-王春生<[email protected]>
user story都是很小的。

2011-1-13 13:28:44 青島-王春生<[email protected]>
完整的客戶需求,不是story,是一個產品。:)

2011-1-13 13:28:58 上海-王劍峰(85822082)
對于一個項目而言 有很多需求是已知的 很明確的成熟度達到這個水平,不用scrum了

2011-1-13 13:29:28 項目管理(397528046)
需求是已知的 并非跟成熟度有關

2011-1-13 13:29:54 上海-王劍峰(85822082)
敏捷就是要應對變化的

2011-1-13 13:30:06 青島-王春生<[email protected]>
adny,評判一下。hoho

2011-1-13 13:30:07 袁斌<[email protected]>
scrum確實很適用于產品類的開發,需求是未知的或者需求在經常變化

2011-1-13 13:30:12 重慶-正(28937095)
想問下,user story中需要描述界面的樣式嗎?以及對界面的操作?

2011-1-13 13:30:19 上海-王劍峰(85822082)
是在需求不明確的的基礎上提出的解決方案

2011-1-13 13:30:26 項目管理(397528046)
比如 對于大多數信息管理系統 總所周知 都會有諸如 登錄、信息維護等功能

2011-1-13 13:30:26 廣州-馮智(288592)
需求明不明確跟成熟度沒關阿
(通過iPhone QQ發送,詳情請訪問: http://apple.qq.com/ )

2011-1-13 13:30:32 北京-許進義(14917275)
敏捷是關注需求的變化,

2011-1-13 13:30:46 青島-王春生<[email protected]>
to項目管理,有確定的,也肯定有很多不確定的。

2011-1-13 13:31:03 上海-王劍峰(85822082)
你需求都明確細化了,很穩定,那還敏捷啥意思呢

2011-1-13 13:31:06 青島-王春生<[email protected]>
你說的登錄,維護,應該是功能模塊,而不是user story

2011-1-13 13:31:24 青島-王春生<[email protected]>
比如登錄,是否需要驗證碼?是否需要記錄登錄狀態?

2011-1-13 13:31:26 袁斌<[email protected]>
對于項目類的開發,如果客戶的IT部門不強大,或者客戶很強勢,他們很多時候喜歡瀑布開發

2011-1-13 13:31:33 北京-許進義(14917275)
對,贊同

2011-1-13 13:31:46 重慶-正(28937095)
對,是的

2011-1-13 13:31:49 袁斌<[email protected]>
即給你兩個月做需求調研,然后就不要煩我了

2011-1-13 13:31:56 項目管理(397528046)
那么user story應該比功能模塊的范圍更小么?

2011-1-13 13:31:59 淄博-躍然(150243423)
傳統的項目管理里面的里程碑的定義在這里有沒有,或者相對應的東西?

2011-1-13 13:32:14 青島-王春生<[email protected]>
user story是比較小的東東。我的理解。呵呵。

2011-1-13 13:32:09 北京-許進義(14917275)
story是從用戶的角度來闡述功能模塊,

2011-1-13 13:32:23 上海-王劍峰(85822082)
Andy敏捷顧問<[email protected]> 1:31:49 PM即給你兩個月做需求調研,然后就不要煩我了,九個月后悲劇重演

2011-1-13 13:32:26 重慶-正(28937095)
而且需求調研完了 還要出一本固定的文檔

2011-1-13 13:32:31 青島-王春生<[email protected]>
比如,我希望可以記錄登錄狀態,可以作為一個user story

2011-1-13 13:32:39 項目管理(397528046)
比如 一個關于登錄的story是否可以是這樣

2011-1-13 13:32:56 青島-王春生<[email protected]>
登錄這個功能模塊,可以有很多個user story出來。

2011-1-13 13:33:00 北京-許進義(14917275)
“作為管理員,我要登錄系統,進行系統管理”

2011-1-13 13:33:25 北京-許進義(14917275)
“作為業務人員,我要登錄系統,進行業務處理”

2011-1-13 13:33:41 重慶-正(28937095)
北京-許進義(14917275) 13:33:00“作為管理員,我要登錄系統,進行系統管理”這也太模糊了吧

2011-1-13 13:33:53 項目管理(397528046)
操作人員輸入用戶名稱和用戶密碼,以及驗證碼,系統驗證輸入的信息,如果正確則允許登錄系統

2011-1-13 13:33:56 上海-王劍峰(85822082)
 

2011-1-13 13:33:55 北京-許進義(14917275)
呵呵,例子,不同的場景再細化

2011-1-13 13:34:04 上海-王劍峰(85822082)
就是這個杯具

2011-1-13 13:34:19 袁斌<[email protected]>
這個圖很經典

2011-1-13 13:34:42 項目管理(397528046)
經典的圖往往只是提出問題 不能解決問題

2011-1-13 13:34:53 上海-王劍峰(85822082)
這就是瀑布的結果

2011-1-13 13:35:00 上海-王劍峰(85822082)
scrum就是解決這個的

2011-1-13 13:34:55 北京-許進義(14917275)
敏捷就是在綁好繩子的時候,跟客戶確認,是不是這樣

2011-1-13 13:35:15 袁斌<[email protected]>
“作為管理員,我要登錄系統,進行系統管理”需要有acceptance test的描述

2011-1-13 13:35:31 青島-王春生<[email protected]>
>>>操作人員輸入用戶名稱和用戶密碼,以及驗證碼,系統驗證輸入的信息,如果正確則允許登錄系統我的意見是還可以再進行拆分。

2011-1-13 13:35:23 北京-許進義(14917275)
哦,學習了

2011-1-13 13:35:33 上海-王劍峰(85822082)
還缺business value

2011-1-13 13:35:45 青島-王春生<[email protected]>
驗證碼可以單獨拿出來,作為一個story

2011-1-13 13:35:57 項目管理(397528046)
是了

2011-1-13 13:36:24 項目管理(397528046)
但這樣的話 單單一個登錄模塊 就可以寫出很多個story

2011-1-13 13:36:33 項目管理(397528046)
那么

2011-1-13 13:36:33 上海-王劍峰(85822082)
多怕什么

2011-1-13 13:36:33 袁斌<[email protected]>
 

2011-1-13 13:36:43 上海-王劍峰(85822082)
story越小越好

2011-1-13 13:36:55 袁斌<[email protected]>
這個圖包含一個story應該包含的因素

2011-1-13 13:37:15 項目管理(397528046)
僅僅把項目中已知需求的story寫出來 就會要很多功夫的

2011-1-13 13:37:16 上海-王劍峰(85822082)
三個sprint做一個story那就不敏捷了

2011-1-13 13:37:50 北京-許進義(14917275)
how to demo就是acceptance test ?

2011-1-13 13:38:09 袁斌<[email protected]>
是的

2011-1-13 13:38:23 項目管理(397528046)
按這個圖上列出的stroy的因素來看,一個story的范圍絕不會很小

2011-1-13 13:38:54 項目管理(397528046)
login、deposit、check

2011-1-13 13:39:06 袁斌<[email protected]>
story是要拆分的,以在一個sprint內可以實現

2011-1-13 13:39:11 項目管理(397528046)
你的這個圖我研究過

2011-1-13 13:39:23 上海-王劍峰(85822082)
是大是小關鍵在于business value

2011-1-13 13:39:26 南京-張小狂(54518545)
拆分的度很難把握

2011-1-13 13:39:37 青島-王春生<[email protected]>
to 項目管理,你的理解呵呵,有問題

2011-1-13 13:39:45 重慶-正(28937095)
to 項目管理 解釋一下

2011-1-13 13:39:50 青島-王春生<[email protected]>
我的觀點,簡單的一點,就越細越好。

2011-1-13 13:39:59 項目管理(397528046)
它是一個story,但實際是若干story的一個集成應用

2011-1-13 13:40:03 南京-張小狂(54518545)
除了業務價值,還要考慮技術實現,資源等

2011-1-13 13:40:15 上海-王劍峰(85822082)
如果一個story的business value說不清楚,那這個story的大小就有問題

2011-1-13 13:40:15 南京-張小狂
也不是越細越好

2011-1-13 13:40:25 重慶-正
暈了!!!

2011-1-13 13:40:18 北京-許進義
之前Andy提到的,項目組的工作能力

2011-1-13 13:40:37 項目管理(397528046)
to 春生 我對于scrum的理解確實存在問題

2011-1-13 13:40:41 南京-張小狂(54518545)
business value是一個關鍵的維度

2011-1-13 13:40:44 上海-王劍峰(85822082)
比如驗證碼,為什么(春生說)要單分出來

2011-1-13 13:40:59 項目管理(397528046)
之前很積極 但是 在項目組實際應用時遇到了很多問題

2011-1-13 13:41:04 南京-張小狂(54518545)
但實際情況,受多個維度制約

2011-1-13 13:41:07 上海-王劍峰
因為他的business value和登錄的business value是兩個

2011-1-13 13:41:34 青島-王春生<[email protected]>
剛才andy里面的how to demo里面的login是另外的story

2011-1-13 13:41:42 沈陽-海岸
敏捷只算一個概念,嘗試一種新的模式,存在學習成本應屬正常。

2011-1-13 13:41:43 上海-王劍峰(85822082)
所以春生的理解是對的,叫項目管理那位先去改名吧

2011-1-13 13:41:52 青島-王春生<[email protected]>
不能何在一起。

2011-1-13 13:41:58 項目管理(397528046)
怎么改名?

2011-1-13 13:42:15 南京-張小狂(54518545)
to andy&春生,敏捷后如何系統,跟蹤文檔,知識積累與傳承

2011-1-13 13:42:50 項目管理(397528046)

我知道地方 我問得是名字的規則

2011-1-13 13:42:58 青島-王春生<[email protected]>
地方-姓名。

2011-1-13 13:43:00 青島-王春生<[email protected]>
hoho

2011-1-13 13:42:55 北京-許進義(14917275)
看看我們的沒發現?

2011-1-13 13:43:09 西安-楊帆(397528046)
ok

2011-1-13 13:43:59 北京-許進義(14917275)
請問Andy,敏捷開發是不是必須與敏捷的激勵配套?

2011-1-13 13:44:17 袁斌<[email protected]>
我總結了一下,大家對敏捷中的需求管理非常感興趣,我建議在下一次討論的時候作為一個主題,我自己也可以準備一些資料和大家分享

2011-1-13 13:44:22 西安-楊帆(397528046)
我的問題就在于 一開始編寫product backlog時難以下手

2011-1-13 13:44:39 青島-王春生<[email protected]>
andy剛才的那個story,只是一個存款的功能,將來可以提款,登錄,這些應當是其他的story點。:)

2011-1-13 13:44:53 重慶-正(28937095)
to andy,翻譯一下,便于理解

2011-1-13 13:45:07 青島-王春生<[email protected]>
呵呵,有的東西,還是英文的比較原汁原味。

2011-1-13 13:45:10 西安-楊帆(397528046)
到底一條backlog的粒度應該分解到什么程度

2011-1-13 13:45:35 重慶-正(28937095)
英文理解也有歧義啊

2011-1-13 13:45:39 青島-王春生<[email protected]>
andy,那個衡量的工時大概是多少來著?

2011-1-13 13:46:14 袁斌<[email protected]>
這里用的是ID(Ideal Day),即10個理想日

2011-1-13 13:46:27 青島-王春生<[email protected]>
每個需求都有一個估計的點的。如果這個需求的點太大,就應該要繼續拆分。

2011-1-13 13:46:29 袁斌<[email protected]>
也有人會用story point

2011-1-13 13:46:32 西安-楊帆(397528046)
此外 剛才我還提及到需求跟蹤 不知道在Scrum中是如何有效的跟蹤需求的

2011-1-13 13:46:57 西安-楊帆(397528046)
需求的估計的點? 這個如何判斷大小?

2011-1-13 13:47:12 北京-許進義(14917275)
story point,人天 或者 人小時,

2011-1-13 13:47:45 青島-王春生<[email protected]>
to andy, 10個理想日,是不是太大了?

2011-1-13 13:47:42 重慶-正(28937095)
to 王春生,禪道里面工時的統計沒體現出來

2011-1-13 13:47:54 西安-楊帆(397528046)
對于上述那個deposit的story 它的需求的點是大還是小?

2011-1-13 13:48:00 青島-王春生<[email protected]>
需求跟蹤,用禪道啊。:)

2011-1-13 13:48:25 袁斌<[email protected]>
春生, 所以這個story是需要拆分的,我展示的是一個較大的story

 2011-1-13 13:48:47 西安-楊帆(397528046)
跟工具沒有關系 我認為關鍵上是分解需求 需求如果不能被有效分解 就無法跟蹤啊

2011-1-13 13:48:44 北京-許進義(14917275)
  

2011-1-13 13:49:52 西安-楊帆(397528046)
說實話 我覺得這個北京團隊的backlog 每一條都很虛

2011-1-13 13:50:01 重慶-正(28937095)
嗯 我也覺得

2011-1-13 13:50:29 重慶-正(28937095)
基本上沒法執行

2011-1-13 13:50:47 西安-楊帆(397528046)
如果作為backlog 誰能估計出 他是需要幾個sprint來完成 或者 一個sprint能完成幾個呢?

2011-1-13 13:51:06 青島-王春生<[email protected]>
作為產品人員,我希望需求可以增加一個owner字段,這樣可以明確的標識這個需求的負責人是誰。

2011-1-13 13:51:05 袁斌<[email protected]>
這個backlog,是隱藏了故事背后的“acceptance test”吧:)

2011-1-13 13:50:56 北京-許進義(14917275)
backlog需要拆分成多個story,

2011-1-13 13:51:11 青島-王春生<[email protected]>
看看禪道的需求。

2011-1-13 13:51:43 青島-王春生<[email protected]>
  

2011-1-13 13:51:55 上海-王劍峰(85822082)
西安-揚帆 還沒入門呢

2011-1-13 13:52:10 青島-王春生<[email protected]>
  

2011-1-13 13:52:17 西安-楊帆(397528046)
我有沒有入門 無關緊要

2011-1-13 13:52:23 上海-王劍峰(85822082)
建議付費請andy給你先上一課

2011-1-13 13:52:40 青島-王春生<[email protected]>
是,我覺得主要的問題是你的觀念。

2011-1-13 13:52:51 青島-王春生<[email protected]>
建議你用腦圖軟件來分解需求。

2011-1-13 13:52:55 上海-王劍峰(85822082)
否則這不是交流,是灌水

2011-1-13 13:52:47 北京-許進義(14917275)
有問題,才更需要我們的討論

2011-1-13 13:53:17 西安-楊帆(397528046)
春生展示的幾個story是可執行的

2011-1-13 13:53:40 西安-楊帆(397528046)
但如果按照春生這樣的來做 就會回到另外一個問題

2011-1-13 13:54:07 西安-楊帆(397528046)
stroy過于細化 一個功能模塊就會有很多story

2011-1-13 13:54:18 袁斌<[email protected]>
這樣,關于變化的需求如何管理,我找一個圖和大家分享

2011-1-13 13:54:41 北京-許進義(14917275)
嗯,確實需要一個單獨的主題來討論這部分

2011-1-13 13:55:02 青島-王春生<[email protected]>
>>>stroy過于細化 一個功能模塊就會有很多story這怕啥?本來就應該要細分出來的。你這個時候不細分,早晚有一天要還賬.
  
 2011-1-13 13:56:46 袁斌<[email protected]>
  

2011-1-13 13:56:51 西安-楊帆(397528046)
你能否把禪道關于登錄方面的story發上來看看么?

2011-1-13 13:56:53 北京-許進義(14917275)
去www.qudvxe.tw

2011-1-13 13:57:21 青島-王春生<[email protected]>
先不急, 先聽andy解釋下這個圖。

2011-1-13 13:57:12 北京-許進義(14917275)
春生的需求都是在公網的,[表情]

2011-1-13 13:57:29 袁斌<[email protected]>
這是scrum如何管理變化的需求,即product backlog如何管理的一個模型

2011-1-13 13:58:49 西安-楊帆(397528046)
好的 先聽講解 我下來拜讀下春生的需求

2011-1-13 13:58:39 北京-許進義(14917275)
按照優先級劃分需求,每次迭代完成優先級高的;

2011-1-13 13:59:41 沈陽-海岸
andy老師,如果一個項目進行80%,做完的功能模塊,基本都處于一個“接近可測試”的狀態。現在進度開始緩慢,就是時間和精力似乎用下去了,但是項目的進展始終達不到目標。針對這個問題,您有什么好建議嗎。 [表情]

2011-1-13 14:00:29 青島-王春生<[email protected]>
建議就是實施scrum。hoho,請andy老師給你們做做內訓。[表情]

2011-1-13 14:00:39 沈陽-海岸
挺入門,也挺現實的一個問題…

2011-1-13 14:00:37 北京-許進義(14917275)
同意春生...

2011-1-13 14:00:53 袁斌<[email protected]>
時間還剩多少?

2011-1-13 14:01:02 袁斌<[email protected]>
海岸

2011-1-13 14:01:19 青島-王春生<[email protected]>
已經到時間了。:)感覺還意猶未盡呢。

2011-1-13 14:01:19 袁斌<[email protected]>
20%的時間剩余?

2011-1-13 14:01:24 北京-許進義(14917275)
才上路...

2011-1-13 14:01:59 袁斌<[email protected]>
海岸,我的一個建議

2011-1-13 14:02:31 袁斌<[email protected]>
如果下一個項目,先把需求按照耦合程度分組

2011-1-13 14:02:58 袁斌<[email protected]>
然后集中團隊力量先做優先級高的

2011-1-13 14:03:06 袁斌<[email protected]>
保證測試完成

2011-1-13 14:03:25 袁斌<[email protected]>
這樣團隊有持續的成就感

2011-1-13 14:04:08 袁斌<[email protected]>
項目的風險也低,退一步說,就算10個功能完成了9個,也比10個功能有5個完成90%但不能交付強

2011-1-13 14:04:24 青島-王春生<[email protected]>
經典!

2011-1-13 14:04:21 北京-許進義(14917275)
[表情]

2011-1-13 14:04:45 沈陽-海岸
是的,andy老師的建議也是我在這個項目中慢慢學到的東西。

2011-1-13 14:04:57 沈陽-海岸
下一個項目應該會成熟許多,目前項目還有兩個月時間。

2011-1-13 14:05:06 青島-王春生<[email protected]>
傷其十指,不如斷其一指。夠狠吧!

2011-1-13 14:05:51 沈陽-海岸
理論時間是夠的,但是我覺得現在處于一個泥潭狀態。如果拔不出來,再有兩年時間也不夠。 [表情]

2011-1-13 14:05:40 北京-許進義(14917275)

 時間到了,我的問題還沒來得及問... ...


2011-1-13 14:06:18 沈陽-海岸
呃,感謝andy老師的總結,我居然在剛好在結束的時間線上。

2011-1-13 14:06:50 袁斌<[email protected]>
針對目前這個項目,已經這樣了,如果進展不大,不如和老板建議一些可以刺激團隊的東西,激勵一下團隊,呵呵

2011-1-13 14:07:44 青島-王春生<[email protected]>
呵呵,andy老師時間也很緊。咱們今天就到這兒吧。感謝andy老師精彩專業的分享![表情]

2011-1-13 14:07:46 沈陽-海岸
嗯,也許我應該重新整理一次需求,然后把力量重新拉攏到主干上來。

2011-1-13 14:07:51 沈陽-海岸
謝謝andy老師。

2011-1-13 14:07:54 北京-許進義(14917275)
謝謝!

2011-1-13 14:08:19 青島-王春生<[email protected]>
[表情]

2011-1-13 14:10:07 青島-葉文濤(709808807)
謝謝老師

2011-1-13 14:09:14 西安-楊帆(397528046)
謝謝

2011-1-13 14:09:44 西安-楊帆(397528046)
如果有可能 我建議可以組織一次關于需求管理方面的討論

2011-1-13 14:10:50 Shirley(17980507)
好主意
發表評論
評論通過審核后顯示。
文章分類
聯系我們

聯系人:魏中顯

電話:18561939726

Email:[email protected]

QQ:1746749398

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐賀

電話:15216484215

Email:[email protected]

QQ:1492153927

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐賀

電話:13730922971

Email:[email protected]

QQ:2845263372

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:孫良宇

電話:13165056632

Email:[email protected]

QQ:3137772959

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:徐亞京

電話:17663982076

Email:[email protected]

QQ:2679672214

地址:青島開發區長江路232號國貿中心C座2單元2902室

聯系人:劉斌

電話:17685869372

Email:[email protected]

QQ:526288068

地址:青島開發區長江路232號國貿中心C座2單元2902室

云禪道

云端的項目管理軟件

尊享禪道項目軟件收費版功能

無需維護,隨時隨地協同辦公

內置subversion和git源碼管理

每天備份,隨時轉為私有部署

免費試用
三肖中特期准黄大仙373745