寫給初次接觸敏捷開發(fā)的PM們
敏捷思維和Scrum,哪個(gè)是第一位?
大多數(shù)決定走向敏捷開發(fā)的公司最終都使用Scrum作為敏捷開發(fā)的方法。他們認(rèn)為在他們大部分的團(tuán)隊(duì)里面使用Scrum就能夠給他們帶來作為一個(gè)敏捷開發(fā)公司的所有好處,但是這樣往往會導(dǎo)致一個(gè)令人失望的結(jié)局。最主要的問題是這些公司應(yīng)該考慮一些其他的方式。在開始Scrum之前,必須確定的是他們愿意采取敏捷的思維方式。你可以采用Scrum,但是首先你必須是敏捷的。
Scrum是否應(yīng)該解決我們的問題?
在我之前柏林的工作中,我們的團(tuán)隊(duì)有一個(gè)穩(wěn)定的流程但是很少有自主權(quán),我們依賴不同的團(tuán)隊(duì),因此我們的能力被限制。所以我們認(rèn)為Scrum可以使我們變得敏捷,相應(yīng)的問題也會消失。
于是我們逐漸開始Scrum并開始每天開一次Scrum會議。緊接著,我們決定將我們的迭代周期設(shè)置為兩周,也就是說每兩周我們就應(yīng)該有一個(gè)新發(fā)布。于是問題來了,對于其他團(tuán)隊(duì)的依賴性導(dǎo)致我們的Scrum變得一團(tuán)糟。除了我們在沖刺結(jié)束的2-3天前準(zhǔn)備好我們的軟件外,QA團(tuán)隊(duì)并沒有足夠的時(shí)間來審核我們的發(fā)布,TechOps團(tuán)隊(duì)也沒有足夠的時(shí)間來部署。以至于我們?nèi)匀皇敲?5天甚至更久才發(fā)布一個(gè)版本。Scrum給我們帶來的唯一一個(gè)改變就是增加了一系列的會議,很快這些會議也就失去了他們該有的意義。
這使得我們的發(fā)布縮短至每20-30天一次,仍然遠(yuǎn)長于我們最初制定的兩周一次迭代。公司發(fā)展的很快也有了很多新的項(xiàng)目,但是沒有新的TechOps工程師,所以他們沒有足夠的時(shí)間去處理每個(gè)人的每件事情。
波蘭的救援!
就是在這期間,我們項(xiàng)目的領(lǐng)導(dǎo)從阿姆斯特丹調(diào)到了波蘭,新的管理者已經(jīng)有幾年的Scrum經(jīng)驗(yàn),他們知道為了改進(jìn)我們的效率,我們需要避免對其他團(tuán)隊(duì)的依賴。
我們新的團(tuán)隊(duì)成員已經(jīng)從開發(fā)到部署負(fù)責(zé)他們的產(chǎn)品一年多的時(shí)間了,在此之前,他們跟我們遇到過同樣的問題。他們有一個(gè)很棒的解決方案:將項(xiàng)目遷移到AWS上。于是他們準(zhǔn)備了一個(gè)很詳細(xì)的預(yù)算,描述了遷移到AWS所需的費(fèi)用并展示給了管理者。當(dāng)他們看到這將會將我們的運(yùn)維成本減少到一半的時(shí)候就欣然同意了這個(gè)方案。于是,在波蘭團(tuán)隊(duì)的幫助下,我們能夠在脫離對TechOps團(tuán)隊(duì)依賴的情況下同等程度的完成我們的工作。最終,在決定開始Scrum之后的四個(gè)月時(shí),終于實(shí)現(xiàn)了每兩周一個(gè)發(fā)布的目標(biāo)。
結(jié)語
如果你想變得敏捷,只采用類似Scrum這樣的開發(fā)框架是不夠的,你必須改變思維方式,并且管理者也必須改變追求“萬無一失”的觀念。公司必須承擔(dān)讓團(tuán)隊(duì)變得跨領(lǐng)域且更自主所帶來風(fēng)險(xiǎn)。如果在管理者和員工之間沒有這樣的信任,那么想實(shí)現(xiàn)敏捷開發(fā)就會變得更復(fù)雜。
我們很幸運(yùn)有一個(gè)思維開放的管理團(tuán)隊(duì),讓我們負(fù)責(zé)整個(gè)開發(fā)過程也愿為此承擔(dān)風(fēng)險(xiǎn)。如果你也同樣幸運(yùn),不要再等了,趕快全面負(fù)責(zé)你的項(xiàng)目吧,你不會為這個(gè)決定后悔的。
敏捷思維和Scrum哪個(gè)是第一位?當(dāng)然是敏捷思維啦。
英文原文:
What came first, Agile or Scrum?
Most companies that decide to go Agile, end up using Scrum as the highway to agility. They think that doing a Scrum process in most of their teams will give them all the benefits of being an agile company. Sadly, this usually ends up in nothing else than disappointment. The main problem is that companies should think the other way around. Before start doing Scrum, they must be sure that they are willing to adopt the agile mindset. You can DO Scrum, but first you must BE agile.
Scrum should solve our problems, shouldn’t it?
On a previous job I had in Berlin, our team had a smooth process but little autonomy. We were dependant on different teams and that was reducing our capacity. So we thought that doing Scrum we were going to become agile and this problems were going to disappear.
We started doing Scrum incrementally and started by doing a daily standup meeting. Later on, we decided to time-box our iterations to two weeks. So we decided that every two weeks, we should have a new release. And here is where problems arrived. Dependencies with other teams made our Scrum process a disaster. Besides we had our software ready 2 or 3 days before the end of the sprint, there was never enough time for the QA team to approve our release and for the TechOps team to deploy it. So instead of releasing every 2 weeks, we were still releasing every 45 days or more. The only thing that Scrum did to our process was introducing a bunch of meetings which lost their sense very quickly.
Developer? It doesn’t mean you can’t test
So the first step was trying to get rid of the QA team dependency. And the way we decided as a team to solve it was by asking the company for a TDDtraining. We thought that by incrementing our test coverage and presenting it nicely to management they would be convinced that we could do the QA job. After this we started having releases with 80% test coverage, and we were happy doing it. We felt that ownership of the project started to become ours. We convinced management that we could do the development and also the testing. The only thing the QA team should do was checking the continuous integration platform before every release and confirm that everything was green there.
This improved our process by releasing every 20-30 days. Still far from the two weeks cycle we pretended when we decided to do Scrum. The company was growing a lot and there were many new projects, but not many new TechOps engineers, so they had no time to handle everything for everybody.
Poland to the rescue!
It was during this time, that the leadership of our project was moved from Amsterdam to ?ód?(Poland). The new management had already a few years working with Scrum, and they knew that in order to improve our performance we needed to remove any dependencies with external teams.
Our new team members had already more than 1 year being fully responsible for their product, from development to deployment. Before that, they had the same issues we had. So their smart move was to create a plan to move their project to Amazon’s cloud (AWS). So they prepared a detailed budget report of how much would it cost to host all their environments in AWS and presented it to management. And when management saw that the numbers would reduce operations cost by the half, guess what? Approved! So with the polish team help, we could do the same thing and finally removed our dependency with TechOps. And around 4 months after deciding to do Scrum, we achieved our “one release every two weeks” goal.
The Learning
If you want to become agile, it’s not enough to just use an agile framework like Scrum. You MUST change your mind and management MUST change their “failure safe” way of thinking. The company must take the risk of letting teams to be multidisciplinary and self-organised. If there is no trust between management and employees, becoming agile gets very complicated.
We were lucky to have an open minded management team which decided to take the risk and let us be fully responsible for the whole development process. So if you have the same luck, don’t waste your time and take full ownership of your project, you’ll never regret that decision.
What came first then, Agile of Scrum? Agile for sure.
本文作者M(jìn)auricio Payetta是點(diǎn)融網(wǎng)首席軟件開發(fā)工程師,原Lending Club工程師,對于敏捷開發(fā)有著深入的研究。翻譯水平有限,如果有不準(zhǔn)確的地方請大家指正。
本文由 @Mauricio Payetta 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?,未經(jīng)許可,禁止轉(zhuǎn)載。
很好的見解
?? 不錯(cuò),很正確