Placeholder Image

字幕列表 影片播放

由 AI 自動生成
  • [Music]

    [音樂]

  • Hi. This is me.

    嗨,這是我

  • My name is Hamid Shojaee, and I've been involved with a number of software development projects

    我的名字是Hamid Shojaee,我參與了許多軟件開發項目。

  • over the years,

    多年來,。

  • at a number of different companies, and I've come to recognize 'Scrum,'

    在一些不同的公司,我已經認識到了'Scrum,&#39。

  • as one of the best agile development practices in use today.

    作為當今使用的最佳敏捷開發實踐之一。

  • In this fast-paced video,

    在這個快節奏的視頻中。

  • I want to show you why Scrum is so great, and how you can get started with Scrum in

    我想告訴你,為什麼Scrum如此偉大,以及你如何在Scrum中開始。

  • under 10 minutes.

    10分鐘以內。

  • I'll cover all the core Scrum concepts,

    我'將涵蓋所有Scrum的核心概念。

  • like product backlogs, team roles, sprints, burndown charts, and more.

    如產品積壓、團隊角色、spring、burndown圖表等。

  • So get ready to be bombarded with information.

    所以準備好接受資訊轟炸吧。

  • Lets say THIS is the product we want to build.

    讓我們說這是我們要打造的產品。

  • For this product, we get all kinds of feature requests from customers, executives, or even

    對於這個產品,我們會收到客戶、高管的各種功能需求,甚至是。

  • other team members.

    其他團隊成員。

  • In Scrum, features are written from the perspective of the end-user,

    在Scrum中,功能是站在最終用戶的角度來寫的。

  • therefore, features are known as user-stories.

    是以,功能被稱為用戶故事。

  • The collection of all these user-stories is called the product backlog.

    所有這些用戶故事的集合稱為產品積壓。

  • Another way to think of the product backlog

    另一種思考產品積壓的方式

  • is to think of it as a wish list of all the things that would make this product great.

    就是把它當成一個願望清單,列出所有能讓這個產品變得偉大的東西。

  • Once we have our wish list or the product backlog,

    一旦我們有了我們的願望清單或產品積壓。

  • we need to start planning which specific user-stories

    我們需要開始規劃哪些具體的用戶故事。

  • we're going to put into a particular release of our product.

    我們'將投入到我們產品的特定版本中。

  • But we're getting ahead of ourselves.

    但我們'是在自作多情。

  • Let's back up a bit.

    讓'我們退後一點。

  • To build this product,

    為了打造這個產品。

  • we need to have one or more people in our team who are going to play a variety of roles.

    我們的團隊中需要有一個或多個要扮演各種角色的人。

  • First, we need her.

    首先,我們需要她。

  • She plays the role of product owner,

    她扮演的是產品所有者的角色。

  • and helps make sure the right features make it into the product backlog

    並幫助確保正確的功能進入產品積壓期

  • representing the users and customers of the product.

    代表產品的用戶和客戶。

  • She helps set the direction of the product.

    她幫助設定產品的方向。

  • Then, we need this guy.

    那麼,我們需要這個傢伙。

  • He is the Scrum Master and his job is to make sure the project is progressing smoothly

    他是Scrum Master,他的工作是確保項目的順利進行。

  • and that every member of the team has the tools they need to get their job done.

    並確保團隊的每個成員都有完成工作所需的工具。

  • He sets up meetings, monitors the work being done and facilitates release planning.

    他安排會議,監督正在進行的工作,並協助制定放行計劃。

  • He's a lot like a project manager, but that's such a boring title.

    他'很像一個項目經理,但這'真是一個無聊的頭銜。

  • So, we'll call him a Scrum Master [Karate yell] to imply he knows some Jui-Jitsu.

    所以,我們'就叫他Scrum Master[空手道大喊],暗示他懂點柔術。

  • And the rest of the team has similar roles to other development processes.

    而團隊其他成員的角色與其他開發流程類似。

  • These guys build the product,

    這些傢伙打造的產品。

  • while these guys test it to make sure it works right.

    而這些傢伙測試它,以確保它的工作正確。

  • These guys use it, and hopefully pay for it.

    這些人用了,希望能付出代價。

  • And these guys, they generally get in the way, but it turns out you can't build many

    而這些傢伙,一般都會礙於情面,但事實證明,你不能'建很多。

  • products without them.

    的產品,而沒有它們。

  • But lets get back to this: Release Planning.

    但讓我們回到這個問題上。發行計劃。

  • To plan a release, the team starts with this, the product backlog,

    為了計劃發佈,團隊從這個開始,產品積壓。

  • and they identify the user-stories they want to put into this release.

    他們確定了他們想要放到這個版本中的用戶故事。

  • These user-stories then become part of the release backlog.

    這些用戶故事就會成為發行積壓的一部分。

  • The team then prioritizes the user-stories and estimates the amount of work involved

    然後,團隊會對用戶故事進行優先排序,並對所涉及的工作量進行估算。

  • for each item.

    每個項目的。

  • Sometimes larger user-stories are broken down into smaller more manageable chunks.

    有時,較大的用戶故事會被分解成更小的、更容易管理的塊。

  • The collection of all the estimates provides a rough idea

    收集了所有的估計數,就有了一個粗略的瞭解。

  • of the total amount of work involved to complete the entire release.

    完成整個發行工作所涉及的總工程量的百分比。

  • A quick side note about estimates.

    關於估價的一個小插曲。

  • There are a lot of techniques for creating good estimates.

    創造好的估計有很多技巧。

  • Some prefer estimating in story points where estimates are made

    有些人喜歡在故事點中進行估算,在故事點中進行估算。

  • relative to building a small component with a known level of difficulty.

    相對於構建一個已知難度的小部件。

  • Unfortunately, story points don’t answer the question of,

    遺憾的是,故事點並沒有回答的問題。

  • When will my project ship?”

    "我的項目什麼時候能出貨?"

  • I have found that the best technique is to estimate work in hours,

    我發現,最好的技術是以小時來估算工作。

  • but to use some standards in how estimates are done.

    但要用一些標準在如何進行估算。

  • For example, things that take less than a day to complete

    例如,需要不到一天時間就能完成的事情

  • will be estimated as 1 hour, 2 hours, 4 hours or 8 hours.

    估計為1小時、2小時、4小時或8小時。

  • Every item will fall into one of those buckets.

    每件物品都會落入其中的一個桶中。

  • There will be no 3 hour estimates, for example.

    比如說,不會有3小時的估計。

  • A 3 hour item would fall into the 4 hour bucket.

    3小時的項目就屬於4小時桶。

  • Larger items will be estimated as 2 days, 3 days, 5 days, or 10 days.

    較大的項目預計為2天、3天、5天或10天。

  • Again, all estimates in between will fall into the next larger bucket.

    同樣,中間的所有估計都將歸入下一個更大的桶。

  • Extremely large items are similarly estimated in months: 1, 2, 3 or 6 Months,

    極大的項目同樣以月為組織、部門進行估算。1、2、3或6個月。

  • but the reality is that such items will need to be broken down substantially

    但現實是,這類項目需要大量分解

  • before work actually begins.

    在工作實際開始之前。

  • Well come back to these estimates in just a minute.

    我們一會兒再來談談這些估計。

  • But for now, lets go back to this:

    但現在,讓我們回到這個問題上。

  • The Release Backlog.

    發行積壓。

  • With a prioritized set of user-stories and the estimated amount of work at hand,

    有了一組優先級的用戶故事和手頭估計的工作量。

  • we are now ready to plan out several sprints to get the work done.

    我們現在準備規劃出幾個衝刺,把工作做好。

  • Sprints are short-duration milestones that allow teams to tackle a manageable chunk of

    衝刺是一個短期的里程碑,讓團隊能夠處理可管理的一大塊工作。

  • the project

    該項目

  • and get it to a ship-ready state.

    並使其達到船用狀態。

  • Sprints generally range from a couple of days to as much as 30 days in length,

    短跑的時間一般從幾天到30天不等。

  • depending on the product's release cycles.

    根據產品'的發佈週期。

  • The shorter the release cycles, the shorter each sprint should be.

    釋放週期越短,每次衝刺的時間應該越短。

  • And you'll want to have at least 2 to as many as a dozen sprints in a given release.

    而且你會希望在一個給定的版本中至少有2個到十幾個sprint。

  • So, at this point, we can take our release backlog and split it up into several of these:

    所以,此時,我們可以把我們的發行積壓,抽成這樣幾個。

  • Sprint Backlogs.

    衝刺積壓。

  • One of the most important things to remember about sprints

    關於短跑,最重要的事情之一就是要記住

  • is that the goal of each sprint is to get a subset of the release backlog to a ship-ready

    是指每一個衝刺的目標是讓發佈積壓的子集達到出貨準備的狀態。

  • state.

    態。

  • So, at the end of each sprint, you should have a fully tested product with all the features

    所以,在每個衝刺結束時,你應該有一個經過全面測試的產品,並具備所有的功能。

  • of that sprint 100% complete.

    的那個衝刺100%完成。

  • Since sprints are a very short, but a realistic representation of part of the product,

    由於sprint是一個很短的,但卻能真實的體現一部分產品。

  • a late finish of the sprint is a great indicator that the project is not on schedule and something

    衝刺晚完成是一個很好的指標,說明項目沒有按計劃進行,有些事情是不可能的

  • needs to be done.

    需要做的。

  • Therefore, it's extremely important to monitor the progress of each sprint with THIS:

    是以,用this監控每一次衝刺的進度是極其重要的。

  • A Burndown Chart.

    一張伯樂圖。

  • The burndown chart is the number one reason for Scrum's popularity,

    爆料圖是Scrum'受歡迎的首要原因。

  • and one of the best project visibility tools to ensure a project is progressing smoothly.

    和最好的項目可視性工具之一,以確保項目的順利進行。

  • The burndown chart provides a day-by-day measure of the amount of work that remains in a given

    消耗圖表提供了一個逐日衡量給定的剩餘工作量的方法。

  • sprint or release.

    衝刺或釋放。

  • In this graph, you can see that the amount of work remaining bounces up and down from

    在這張圖中,你可以看到,剩餘的工作量在從

  • day to day,

    每天都有。

  • but is generally trending towards zero.

    但總體上是趨向於零。

  • Because historical information is provided in the burndown chart,

    因為在爆料圖中提供了歷史資訊。

  • it's easy to see if the team is on the right track.

    它'很容易看到球隊是否在正確的軌道上。

  • Using the burndown chart, the team can quickly calculate this:

    利用燒傷圖,團隊可以快速計算出這一點。

  • the slope of the graph, which is also called the Burndown Velocity.

    圖形的斜率,也叫降速。

  • This is the average rate of productivity for each day.

    這是每一天的平均生產力率。

  • For example, a team's rate of productivity might be that on a typical day,

    例如,一個團隊'的生產力率可能是,在典型的一天。

  • they finish approximately 50 hours of work.

    他們大約完成50小時的工作。

  • Knowing that, it's possible to calculate an estimated completion date for the sprint

    知道了這一點,就可以計算出衝刺的預計完成日期。

  • or even for the entire release, based on the amount of work remaining.

    甚至根據剩餘的工作量,對整個發佈。

  • What's great about the burndown chart

    爆料圖有什麼好處?

  • is that we can compare our actual velocity and projected completion date

    是我們可以比較我們的實際速度和預計完成日期。

  • to what the team needs to do in order to finish OnTime.

    到團隊需要做什麼才能完成OnTime。

  • This is perhaps the most useful piece of knowledge

    這也許是最有用的知識

  • that any team member, product owner or product executive can have about the project,

    任何團隊成員、產品負責人或產品主管都可以對項目進行。

  • because knowing whether or not the project is on track early in the schedule

    因為在進度表的早期就知道項目是否走上了正軌。

  • can help teams make the proper adjustments necessary to get the project on track.

    可以幫助團隊進行必要的適當調整,使項目走上正軌。

  • The burndown chart provides empirical proof that the project is on track or if it's going

    消耗圖表提供了項目是否按部就班或是否要進行的經驗證明。

  • to be late.

    要遲到了。

  • So, let's talk a little about where the data for this incredibly useful burndown chart

    那麼,讓我們來談談這個令人難以置信的有用的爆表的數據在哪裡吧

  • comes from.

    來自。

  • As you recall, part of the release planning process was to create an estimate for each

    您還記得,發佈規劃流程的一部分是為每個項目創建一個估計值。

  • user-story in the release backlog.

    用戶故事在發佈積壓。

  • The collection of these estimates for a given sprint represents the total amount of work

    某一特定衝刺的這些估計值的集合代表了總的工作量。

  • that must be done to complete that sprint.

    為了完成這個衝刺必須做的事情。

  • As each team member goes through and makes progress on one or more of the user-stories,

    當每個團隊成員在一個或多個用戶故事上經歷並取得進展時。

  • they simply update the amount of time remaining for each of their own items.

    他們只需更新自己每個項目的剩餘時間量即可。

  • So, the total amount of time remaining on the group of user-stories that make up a sprint,

    所以,構成衝刺的用戶故事群的剩餘總時間。

  • changes on a day-by-day basis,

    逐日變化。

  • hopefully going downward until it hits zero when the sprint is complete.

    希望往下走,直到衝刺完成後達到零。

  • The burndown chart aggregates the remaining work data and shows it visually.

    爆料圖將剩餘的工作數據進行彙總,並直觀地顯示出來。

  • It's brilliant because it communicates a massive amount of information in just a few seconds.

    它的聰明之處在於它能在短短几秒鐘內傳達大量資訊。

  • And that brings us to this:

    這也就引出了這個問題。

  • The Daily Scrum.

    每天的Scrum。

  • The Daily Scrum is an essential tool to having communication flow freely between team members.

    每日Scrum是讓團隊成員之間自由交流的重要工具。

  • The idea is to have fast paced stand-up meetings

    我們的想法是開快節奏的站立會議。

  • where team members quickly list the work they completed since the last meeting,

    在這裡,團隊成員迅速列出自上次會議以來完成的工作。

  • and any obstacles in their way.

    和任何障礙。

  • By meeting daily, it ensures the team is always in-sync,

    通過每天開會,確保團隊始終保持同步。

  • and any major issues are dealt with as soon as they are known.

    並對任何重大問題一經瞭解,立即進行處理。

  • Finally, as each sprint comes to a finish,

    最後,隨著每一次衝刺的結束。

  • it’s important to have a Sprint Retrospective meeting,

    開一個衝刺回顧會很重要。

  • where the team can reflect on what went right and areas of improvement.

    在這裡,團隊可以反思哪些地方做得對,哪些地方需要改進。

  • After all, Scrum is a flexible agile development method

    畢竟,Scrum是一種靈活的敏捷開發方法

  • that needs constant improving and tweaking for every team.

    這需要每個團隊不斷的改進和調整。

  • So, there you have it.

    所以,你有它。

  • Scrum in under 10 minutes.

    在10分鐘內完成Scrum。

  • You now know all the essential concepts to start implementing Scrum inside of your organization.

    你現在知道了在你的組織中開始實施Scrum的所有基本概念。

  • But wait a second,

    但等一下。

  • what about tools to help you implement Scrum?

    幫助你實施Scrum的工具呢?

  • Well, it just so happens that I’ve spent the last 10 years building such a tool.

    好吧,恰好我在過去的10年裡一直在打造這樣一個工具。

  • With a lot of help from these guys:

    在這些人的大力幫助下。

  • a group of genius coders and design ninjas.

    一群天才的編碼員和設計忍者。

  • The tool is called, OnTime,

    這個工具叫,OnTime。

  • and it helps you manage your products, your backlogs, your team,

    並幫助你管理你的產品、你的積壓、你的團隊。

  • your releases and your sprints.

    你的發佈和你的衝刺。

  • It gives you project visibility with burndown charts,

    它為您提供了項目的可見性與燃盡圖。

  • and always answers the question of who is working on what.

    並始終回答著誰在研究什麼的問題。

  • You can get started with it for free, at Axosoft.com.

    您可以在Axosoft.com上免費開始使用它。

  • Of course, you could use a giant white board, some note cards [Paper crumples]

    當然,你也可以用一塊巨大的白板,一些便條卡[紙屑]

  • and a bunch of different spreadsheets [Paper crumples] to track everything.

    和一堆不同的電子表格[紙皺]來追蹤一切。