這年頭不作敏捷開發都很差意思說本身是作軟件開發的。不少人都知道敏捷開發或者項目就在敏捷開發中,可是愈來愈多的人對敏捷開發表示不理解了。我常常聽身邊的人問:敏捷是什麼?究竟什麼纔是敏捷開發?難道敏捷開發就是這樣嗎?web
這就跟早上正常點上個班,週末加個班就喊「狼性」是一個道理:不少人認爲早上開站立會就是敏捷了!工具
我不是科班出身,對敏捷開發瞭解是工做時候瞭解的,很早工做的時候有個雅虎來的牛人加入公司,他原本就是作流程軟件的,每天給咱們將如何敏捷,如何走開發流程,第一次據說還有敏捷開發這種東西。以後在騰訊工做,團隊有個業內Scrum大師,參與了不少大型項目,包括騰訊搜搜項目整個的研發流程制訂之類,那段時間給咱們團隊作流程優化,也給咱們分享,經他推薦,也算讀了幾本Scrum的書籍。下面簡單談下本身的認識。優化
若是要問:敏捷開發和站會是什麼關係?我想說:的確有關係,但要知道不是你把敏捷的流程都走一遍就真的敏捷了。接口
scrum會議能夠分爲:sprint計劃會,每日站會,評審會和回顧會。資源
我的認爲:敏捷提到的站會只是一天固定時間溝通的會議,主要目的仍是跟進進度、暴漏問題,PO(product owner)和SM(Scrum Master)意圖經過站會來完成本身的職責:開發
協調資源,解決項目的障礙文檔
保證項目進度產品
保證團隊內角色之間的協做io
團隊跟其餘團隊的接口人,協調溝通ast
而現實中的站會多是下面的樣子:
PM忙着改需求
RD討論解決方案
UE忙着改圖
QA在報bug
可有可無的人在打哈欠
敏捷開發是一套通過多年實踐而總結出來的一套方法論。因此不要神化,更不要跟風,適合本身的team就好(本人一直實用主義,從不盲從)。
敏捷總結了一些項目中經常碰見的問題,而且想經過敏捷的流程來避免這些問題。而如今不少公司不少項目用了敏捷(或者敏捷擴展版),實際參加敏捷的童鞋並無「敏捷」,而是在抱怨:爲何這麼多流程?爲何這麼多會議?
每每大公司一個項目須要牽扯太多人,一次發佈會能夠開5個小時,涉及到的人都參加,前面的人七嘴八舌各抒己見,後面的人各幹個事。可能某些人只知道本身負責的部分,絕大多數都不知道本身想要的是怎樣的一個產品,產品的roadmap是什麼,該堅持的不堅持,最多的狀況是在聽取了意見後作了妥協。
團隊太大,還會出現一些雞同鴨講的會議,好比每日站會:先是UE,而後RD,後是QA,再。。。
這樣前面講的事情,根本本身都不知道幹啥,聽不懂,那爲啥還要非拉在一塊兒開會呢?
最大的錯誤是team太大,忽略了個體。敏捷有個說法:2個披薩。也就說團隊人數要控制在兩個披薩夠吃內。
敏捷提倡對團隊人的信任,充分調動團隊中每一個人的積極性,發揮最大的效率。
當一個項目team太大的時候,能夠考慮拆成幾個敏捷團隊來執行,團隊之間共享角色,來實現溝通。好比:UE開UE的會,而參加RD的會就會昏昏欲睡;何須呢~當涉及到其餘團隊角色的時候能夠叫上一塊兒啊。
其實這在scrum裏面有個專業術語:scrum of scrums。個人想獲得,大佬想不到嗎?固然我相信他們也想獲得,不過沒有什麼比成功更具備說服力。因此也許堅持經驗更重要。
好比說燃起圖(燃盡圖)這件事,就是爲了你們看到天天的進度,而老一些「敏捷er」每每對新「敏捷er」說:task要拆的夠細,天天都有事情作,天天都有事情完成,要燃起圖好看。
你是知道的中國人都是很聰明的,因而會想盡辦法「造」task,由於我要保證次日個人燃起圖正常,否則會被點名批評的,被批評了KPI怎麼辦?
對於流程來講,當流程太複雜的時候,咱們應該敢於提出來,去精簡。當一個新的SM(搞錯意思的面壁三分鐘)接棒的時候,應該審視以前的流程,是否合理,是否須要調整。
如今每每是你們以爲項目作成了,leader升級了,留下的就是寶貴的經驗,下一個leader就會按照這個流程來作,儘快他也深受其害,可是這是「寶貴經驗」,以前的leader就是這樣成功的,爲何咱們要顛覆呢?
也許好幾個項目並行,一個角色穿梭於多個項目中,這樣貌似在並行,其實人仍是那我的,他不可能同時作兩件事情,這不是一種提升效率的事情。人只有在專一一件事情上,才能發揮最大的效率。多個事情並行會分散精力。這就像番茄鍾要25分鐘專一一件事情的道理同樣的。
爲啥你們都怨聲載道還要摸黑走下去呢?該變就變!
SM須要作的是:要每一個角色效率都最大化利用,爲角色提供更溫馨的工做環境(包括流程)。
個體和互動高於流程和工具
工做的軟件 高於詳盡的文檔
客戶合做 高於合同談判
響應變化 高於遵循計劃