中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

敏捷思維和Scrum，哪個是第一位？

大多數決定走向敏捷開發的公司最終都使用Scrum作為敏捷開發的方法。他們認為在他們大部分的團隊里面使用Scrum就能夠給他們帶來作為一個敏捷開發公司的所有好處，但是這樣往往會導致一個令人失望的結局。最主要的問題是這些公司應該考慮一些其他的方式。在開始Scrum之前，必須確定的是他們愿意采取敏捷的思維方式。你可以采用Scrum，但是首先你必須是敏捷的。

Scrum是否應該解決我們的問題？

在我之前柏林的工作中，我們的團隊有一個穩定的流程但是很少有自主權，我們依賴不同的團隊，因此我們的能力被限制。所以我們認為Scrum可以使我們變得敏捷，相應的問題也會消失。

于是我們逐漸開始Scrum并開始每天開一次Scrum會議。緊接著，我們決定將我們的迭代周期設置為兩周，也就是說每兩周我們就應該有一個新發布。于是問題來了，對于其他團隊的依賴性導致我們的Scrum變得一團糟。除了我們在沖刺結束的2-3天前準備好我們的軟件外，QA團隊并沒有足夠的時間來審核我們的發布，TechOps團隊也沒有足夠的時間來部署。以至于我們仍然是每45天甚至更久才發布一個版本。Scrum給我們帶來的唯一一個改變就是增加了一系列的會議，很快這些會議也就失去了他們該有的意義。

這使得我們的發布縮短至每20-30天一次，仍然遠長于我們最初制定的兩周一次迭代。公司發展的很快也有了很多新的項目，但是沒有新的TechOps工程師，所以他們沒有足夠的時間去處理每個人的每件事情。

波蘭的救援！

就是在這期間，我們項目的領導從阿姆斯特丹調到了波蘭，新的管理者已經有幾年的Scrum經驗，他們知道為了改進我們的效率，我們需要避免對其他團隊的依賴。

我們新的團隊成員已經從開發到部署負責他們的產品一年多的時間了，在此之前，他們跟我們遇到過同樣的問題。他們有一個很棒的解決方案：將項目遷移到AWS上。于是他們準備了一個很詳細的預算，描述了遷移到AWS所需的費用并展示給了管理者。當他們看到這將會將我們的運維成本減少到一半的時候就欣然同意了這個方案。于是，在波蘭團隊的幫助下，我們能夠在脫離對TechOps團隊依賴的情況下同等程度的完成我們的工作。最終，在決定開始Scrum之后的四個月時，終于實現了每兩周一個發布的目標。

結語

如果你想變得敏捷，只采用類似Scrum這樣的開發框架是不夠的，你必須改變思維方式，并且管理者也必須改變追求“萬無一失”的觀念。公司必須承擔讓團隊變得跨領域且更自主所帶來風險。如果在管理者和員工之間沒有這樣的信任，那么想實現敏捷開發就會變得更復雜。

我們很幸運有一個思維開放的管理團隊，讓我們負責整個開發過程也愿為此承擔風險。如果你也同樣幸運，不要再等了，趕快全面負責你的項目吧，你不會為這個決定后悔的。

敏捷思維和Scrum哪個是第一位？當然是敏捷思維啦。

英文原文：

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.

本文作者Mauricio Payetta是點融網首席軟件開發工程師，原Lending Club工程師，對于敏捷開發有著深入的研究。翻譯水平有限，如果有不準確的地方請大家指正。

本文由 @Mauricio Payetta 原創發布于人人都是產品經理?，未經許可，禁止轉載。