學生團隊實施scrum敏捷開發的疑問?
1.scrum中有個重要特性是每日站立會議,每個團隊成員總結當天做了什麼、遇到什麼困難、明天想做什麼,但是一般學生團隊中,每個成員由於時間上的關係,並不能保證每天都能抽出時間來做項目相關的事情,那麼這樣的站立會議應該怎麼開呢?
這個時間問題對於團隊的所有成員都存在,每個成員都不能保證每天能花時間在項目上,但是一周20多個小時的時間是能保證的,那麼這樣的情況來說,站立會議的周期是否可以適當調整的長一點?2.scrum站立會議能通過網上溝通代替嗎?
法無定法,只要達到充分溝通,及時分享信息,發現問題的目的,形式是次要的。:)
Scrum的站立會議最忌諱形式主義,它的目標就是為了讓大家每天都碰個面,有問題提早拋出來,有事被耽擱儘早說,有事正在做的也要說,總之就是一來讓scrum master知道自己要幫些什麼,二來也讓成員們知道whole picture,針對你第一個問題,
1. 三個問題,如果實在不能參加,可以早上發郵件或簡訊微信群什麼的讓成員知曉,2. 完全可以,形式不重要,重要的是參與意識。我其實個人特別反感形式主義的scrum,光有形而無實簡直是拖累,要了解scrum和敏捷的實質。
It"s Not Just Standing Up: Patterns for Daily Standup MeetingsEdit
「如何評價網路熱文《 Scrum 行還是不行 》?第一個回答中的這一段很贊:最後說幾句,我真的不在乎一個項目是用敏捷,Scrum,瀑布或者CMMI,完全不在乎。我真正在乎的是「組建牛X團隊」,「實現商業目標」,「創造出高品質產品」,「讓客戶滿意」,「增強客戶盈利能力」。恰好,包括敏捷在內的一些有效的方法論幫助我去實現了以上的目標。我更希望看到我們的用戶在使用我們產品,玩我們的遊戲的時候得到真正的開心和便捷。
敏捷是為什麼而誕生的?它是因為客戶/用戶需求多雜,而滿足的一種短期交付的行為,比如開發版本的MIUI,一個月發布一次,這就是典型的敏捷(但是否是用的scrum不重要,不得而知),它的特點就是拆分任務,減少交付粒度,調整交付任務優先順序,指向性的迅速對用戶需求和市場做出反應,對應傳統的過度設計,繁重文檔維護,交付周期長等,而變革的一種順應時代的軟體實施方法論。
share一篇:有道雲筆記蔣煒航:敏捷開發的實戰經驗。1,每日站會只不過是Scrum的一部分而已(5個會議之一,其他組成部分還包括3類角色、3種工件),算不上是重要特性。Scrum最重要的是Transparency、Inspection、Adaption。可參考https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-CN.pdf#zoom=100。
2,站會的目的是幫助團隊共同關注和管理他們當前迭代進度的狀態和風險。對於你所描述的這種情況,我很懷疑他們是否有共同的目標,這種情況下,連團隊都算不上,只是群體而已,開每日站會也就只有分享信息的作用了。
- 不過,如果你只能在這種情況下開展Scrum,那麼也很簡單,站會照開,沒有進度就是「我今天沒有任何進度」就可以了。3,站會的周期如果調整,那就不是Scrum的站會了。
- 如果你並不在乎自己是否在做Scrum,那麼儘管調整,沒關係。4,不可以用網上交流代替。「面對面交流」是敏捷的原則之一,Scrum當然也需要遵守,敏捷宣言遵循的原則。1.scrum中有... 那麼這樣的站立會議應該怎麼開呢?一周20多個小時能保證
答: 敏捷里有持續集成的概念, 不能保證每天有時間去做和開日例會,那麼每周都得去做一個大的集成,開好回顧會,在一周裡面,也要有集成兩到三次,用產出說話和評估下一步風險做出改善。
2.scrum站立會議能通過網上溝通代替嗎? 答:能當面當然當面最好,像我們團隊本來就是分散式的就沒辦法了,有共享平台就好,沒有的話文檔和規範要設置多一點。推薦閱讀:
※qt5.4以後會向什麼方向發展?
※黑客可以厲害到什麼程度?
※關於軟體測試和軟體測試工程師有什麼好笑的段子?
※如何看待在 OI / ACM 賽事廣為使用的快速讀入整數?
※如何在完全不會使用CFD軟體的情況下裝作很了解CFD的樣子?