You are on page 1of 10

Hướng dẫn Kanban

cho Scrum Teams


Tháng Chín 2019

Phát triển và duy trì bởi Scrum.org, Daniel Vacanti, and Yuval Yeret
Nộ i dung
Mục Đích ........................................................................................................................... 3
Quan Hệ với Tài Liệu Hướng Dẫn Scrum........................................................................... 3
Định Nghĩa Kanban........................................................................................................ 3
Kanban với học thuyết của Scrum ..................................................................................... 3
Flow và chủ nghĩa thực nghiệm ..................................................................................... 3
Các số đo cơ bản của flow ............................................................................................. 4
Luật Little --- Điều cốt yếu của việc tổ chức flow .............................................................. 4
Những thực hành của Kanban .......................................................................................... 4
Sự trực quan của Workflow --- Bảng Kanban .................................................................. 5
Giới Hạn Công việc Đang Thực Hiện (WIP) .................................................................... 5
Chủ động quản lý Các việc đang thực hiện ................................................................... 6
Thanh Tra và Thay đổi để thích nghi Định Nghĩa ‘‘Workflow’’ ........................................ 6
Các sự kiện theo Flow ....................................................................................................... 7
Sprint ............................................................................................................................. 7
Sprint Planning .............................................................................................................. 7
Daily Scrum.................................................................................................................... 7
Sprint Review ................................................................................................................. 8
Sprint Retrospective .......................................................................................................... 8
Phần tăng trưởng của sản phẩm (ND: Increment) ............................................................. 9
Lời kết ................................................................................................................................ 9
Lịch sử phát triển và lời tri ân ............................................................................................ 9
Translator Acknowledgement ......................................................................................... 10
Cập nhật các bản dịch ..................................................................................................... 10

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 2
Mục Đích
Hướng tiếp cận theo luồng của Kanban sẽ mở rộng và bổ sung cho cơ cấu tổ chức công
việc Scrum và sự thực hiện nó. Các đội có thể bổ sung những điều hay của Kanban cho
dù họ vừa bắt đầu sử dụng Scrum hay đã sử dụng nó từ lâu.
Hướng Dẫn Kanban cho Scrum Teams là kết quả cộng tác giữa những thành viên của
cộng đồng Scrum.org và những người tiên phong trong cộng đồng Kanban. Cùng với
nhau, họ đã cho ra đời Hướng Dẫn Kanban cho Scrum Teams. Họ cùng tin rằng những
nhà phát triển sản phẩm chuyên nghiệp có thể hưởng lợi từ việc áp dụng Kanban cùng
với Scrum.

Quan Hệ với Tài Liệu Hướng Dẫn Scrum


Tài liệu hướng dẫn này không thay thế hay làm giảm ý nghĩa của bất cứ phần nào trong
Tài Liệu Hướng Dẫn Scrum. Tài liệu này được thiết kế để mở rộng và làm phong phú những
cách thức hoạt động của Scrum. Tài liệu hướng dẫn này ngầm hiểu là người đọc đang sử
dụng Scrum. Vì vậy, Tài Liệu Hướng Dẫn Scrum được áp dụng dưới dạng toàn vẹn.

Định Nghĩa Kanban


Kanban (danh từ): là chiến lược tối ưu flow giá trị qua một quy trình trực quan, hệ thống
giới hạn công việc đang thực hiện theo nguyên lý kéo (ND: pull system).

Kanban với học thuyết của Scrum

Flow và chủ nghĩa thực nghiệm


Trung tâm của định nghĩa Kanban chính là khái niệm flow. Flow là sự chuyển dịch của giá
trị qua hệ thống phát triển sản phẩm. Kanban tối ưu flow bằng cách cải tiến hiệu quả, hiệu
năng và khả năng dự đoán của một quy trình.
Việc tối ưu flow trong ngữ cảnh của Scrum yêu cầu phải xác định ý nghĩa của flow trong
Scrum. Scrum được tạo ra dựa trên học thuyết điều khiển quy trình dựa trên thực nghiệm.
Điểm cốt yếu của việc điều khiển quy trình dựa trên thực nghiệm là sự thường xuyên của
các chu kỳ thanh tra, thích ứng, minh bạch --- điều mà có thể được gọi là thời gian chu kỳ
qua một chu trình phản hồi (ND: feedback loop)
Khi áp dụng các điểm hay của Kanban vào Scrum, chúng sẽ cung cấp sự tập trung vào cải
tiến flow trong chu trình phản hồi; tối ưu sự minh bạch và sự thường xuyên thanh tra, thích
ứng cho cả sản phẩm lẫn quy trình.

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 3
Các số đo cơ bản của flow
Bốn số đo cơ bản của flow mà Scrum Team sử dụng Kanban cần theo dõi là:
 Công việc đang thực hiện --- Work in Progress (WIP): Số lượng hạng mục công
việc đã bắt đầu mà chưa hoàn tất. Lưu ý sự khác nhau giữa số đo WIP và chính
sách giới hạn WIP mà Scrum Team sử dụng. Đội có thể sử dụng số đo WIP để
cung cấp sự minh bạch về tiến độ hướng đến việc giới hạn WIP để cải tiến flow
 Thời gian chu kỳ - Cycle Time: Thời lượng trôi qua giữa thời điểm công việc bắt
đầu và khi nó được hoàn tất
 Tuổi của hạng mục công việc --- Work Item Age: Thời lượng giữa thời điểm
công việc bắt đầu và thời điểm hiện tại. Số đo này áp dụng cho các công việc
đang thực hiện.
 Thông lượng --- Throughput: Số lượng hạng mục công việc hoàn tất trên một
đơn vị thời gian

Luật Little --- Điều cốt yếu của việc tổ chức flow
Nguyên lý cốt yếu của việc tổ chức flow là luật Little, đó là hướng dẫn cho việc thiết lập
mối quan hệ sau:
𝑇𝑟𝑢𝑛𝑔 𝑏ì𝑛ℎ 𝐶ô𝑛𝑔 𝑣𝑖ệ𝑐 đ𝑎𝑛𝑔 𝑡ℎự𝑐 ℎ𝑖ệ𝑛
𝑇ℎờ𝑖 𝑔𝑖𝑎𝑛 𝑐ℎ𝑢 𝑘ỳ 𝑡𝑟𝑢𝑛𝑔 𝑏ì𝑛ℎ
𝑇ℎô𝑛𝑔 𝑙ượ𝑛𝑔 𝑡𝑟𝑢𝑛𝑔 𝑏ì𝑛ℎ

Luật Little khám phá rằng, nói chung, bất cứ một quy trình nào có thông lượng, cứ thêm
công việc bạn phải làm trong một khoảng thời gian (tính trung bình) thì sẽ mất lâu hơn để
hoàn tất nó (tính trung bình).
Nếu thời gian chu kỳ quá lâu, Scrum Team cần ngay lập tức giảm WIP xuống. Hầu hết các
thành phần khác của Kanban được xây dựng dựa trên mối tương quan giữa WIP và thời
gian chu kỳ.
Luật Little cũng cho chúng ta thấy lý thuyết flow dưa trên chủ nghĩa thực nghiệm bằng
cách sử dụng các số đo flow và dữ liệu để có được sự minh bạch về lịch sử của flow và rồi
sử dụng dữ liệu đó để cung cấp cho việc thanh tra flow và các thử nghiệm thích ứng.

Những thực hành của Kanban


Scrum Teams có thể đạt được việc tối ưu flow thông qua 4 thực hành sau:
 Làm cho Workflow được trực quan
 Giới hạn công việc đang thực hiện (WIP)
 Chủ động quản lý các hạng mục công việc đang thực hiện
 Thanh tra và thay đổi để thích ứng định nghĩa ‘‘Workflow’’ của đội

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 4
Định nghĩa ‘‘Workflow’’
Bốn thực hành Kanban được thực hiện nhờ định nghĩa ‘‘Workflow’’ của Scrum Team. Định
nghĩa này đại diện cho các hiểu biết tường minh của thành viên Scrum Team về các chính
sách cần phải tuân theo để thực hành Kanban. Hiểu biết chung này sẽ cải tiến và hiện thực
hóa sự tự tổ chức công việc và tính minh bạch.
Lưu ý rằng, định nghĩa ‘‘Workflow’’ có thể được mở rộng ra ngoài phạm vi của Sprint hoặc
Sprint Backlog. Ví dụ như, định nghĩa ‘‘Workflow’’ của Scrum Team có thể định hướng flow
bên trong hoặc bên ngoài Sprint.
Việc tạo ra và thay đổi để thích nghi định nghĩa ‘‘Workflow’’ là trách nhiệm thuộc về các vai
trò trong Scrum Teams như định nghĩa trong Tài Liệu Hướng Dẫn Scrum. Không một
người ngoài Scrum Team nào có thể bảo Scrum Team phải định nghĩa ‘‘Workflow’’ của họ
ra sao. Tương tự, không một người ngoài nào, bao gồm cả Product Owner và Scrum
Master có thể bảo Development Team cách định nghĩa các khía cạnh của Workflow nội
bộ của Development Team như thế nào.

Sự trực quan của Workflow --- Bảng Kanban


Sự trực quan của bảng Kanban là cách mà Scrum Team làm cho Workflow của họ được
minh bạch. Cấu tạo bảng nên thể hiện đúng nội dung đúng lúc và chủ động gợi ý các cải
tiến khi cần thiết.
Sự trực quan nên bao gồm:
 Định ra điểm bắt đầu và kết thúc công việc của Scrum Team
 Định nghĩa của những hạng mục công việc --- đơn vị giá trị (giá trị của các bên liên
quan, giá trị tri thức, giá trị để cải tiến quy trình) chạy qua hệ thống của Scrum
Team (trong đa số trường hợp, chính là các hạng mục của Product
Backlog(PBIs)).
 Định nghĩa các trạng thái của flow mà các hạng mục công việc chạy qua từ trạng
thái bắt đầu đến trạng thái kết thúc (trong đó có ít nhất một trạng thái kích hoạt).
 Các chính sách tường minh mô tả công việc sẽ thay đổi qua mỗi trạng thái như
thế nào (có thể bao gồm các mục trong Định nghĩa ‘‘Done’’ của Scrum Team và
chính sách kéo (ND: Pull policies) giữa các giai đoạn)
 Các chính sách giới hạn công việc đang thực hiện (WIP)

Giới Hạn Công việc Đang Thực Hiện (WIP)


Công việc Đang thực hiện (WIP) là những việc Scrum Teams đã bắt đầu mà chưa hoàn tất.
Scrum Team sử dụng Kanban cần phải giới hạn số lượng các việc này trong quy trình của
họ một cách tường minh. Một Scrum Team có thể giới hạn WIP một cách tường minh sao
cho phù hợp và phải tuyệt đối tuân theo giới hạn đó một khi nó đã được thiết lập.

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 5
Ảnh hưởng chính của việc giới hạn WIP là nó sẽ tạo ra một hệ thống kéo. Nó được gọi là
hệ thống kéo vì đội chỉ bắt đầu làm một việc khi họ biết rõ họ có đủ khả năng (ND: thời
gian) để làm việc đó. Khi WIP giảm xuống dưới giới hạn, đó là dấu hiệu để bắt đầu một
việc mới. Lưu ý rằng nó khác hệ thống đẩy (ND: Push system) ở chỗ đội cần phải bắt đầu
công việc một khi được yêu cầu.
Việc giới hạn WIP sẽ giúp flow tốt hơn và cải tiến tính tự tổ chức công việc, độ tập trung,
cam kết và cộng tác của Scrum Team.

Chủ động quản lý Các việc đang thực hiện


Việc giới hạn WIP là cần thiết để đạt được khái niệm flow, nhưng chưa đủ. Thực hành thứ
ba để thiết lập flow là chủ động quản lý việc đang thực hiện. Trong Sprint, sự quản lý này
được Development Team thực hiện dưới nhiều dạng, bao gồm và không giới hạn ở:
 Việc bảo đảm các công việc được kéo vào flow tỷ lệ thuận với các việc ra khỏi
flow
 Việc đảm bảo công việc không ở trong flow lâu quá mức cần thiết
 Việc phản ứng nhanh đối với những khó khăn trở ngại, công việc dồn nhiều hay
công việc bị lố thời gian chu kỳ của đội (xem phần Mức độ Dịch Vụ Được Kỳ Vọng
(ND:Service Level Expectation) --- SLE).

Mức độ Dịch Vụ Được Kỳ Vọng (SLE)


Một kỳ vọng về mức độ dịch vụ (SLE) sẽ định trước cần bao lâu để một việc đi qua các
trạng thái từ bắt đầu đến kết thúc trong Workflow của Scrum Team. Scrum Team sử dụng
SLE của họ để tìm ra các vấn đề đang diễn ra của flow và thanh tra để thích nghi trong
trường hợp không đạt được các kỳ vọng.
SLE có hai phần: Thời gian kỳ vọng và những khả năng liên quan đến nó (ví dụ như 85%
công việc sẽ được hoàn tất trong 8 ngày hoặc nhanh hơn). SLE nên được dựa trên thời
gian chu kỳ trong quá khứ của Scrum Team, một khi được tính toán, Scrum Team phải
làm cho nó tường minh. Nếu không có dữ liệu trong quá khứ, Scrum Team phỏng đoán
gần đúng nhất và dùng việc thanh tra và thích nghi để khi có đủ dữ liệu, sẽ làm cho việc
tính toán ra SLE chính xác hơn.

Thanh Tra và Thay đổi để thích nghi Định Nghĩa ‘‘Workflow’’


Scrum Team sử dụng những sự kiện sẵn có trong Scrum để thanh tra và thay đổi định
nghĩa ‘‘Workflow’’ của nó, nhờ đó mà cải tiến thực tiễn và tối ưu giá trị mà Scrum Team
phát hành.

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 6
Các khía cạnh sau của định nghĩa ‘‘Workflow’’ có thể được Scrum Team ứng dụng
 Chính sách về trực quan --- ví dụ, các trạng thái của flow --- sẽ thay đổi flow thực tế
và làm tường minh các khu vực để thanh tra và thay đổi để thích nghi.
 Chính sách về phương pháp làm việc --- có thể giải quyết trực tiếp các khó khăn
trở ngại. Ví dụ thay đổi giới hạn WIP và SLEs, thay đổi khối lượng đợt công việc
hay mức độ thường xuyên của việc kéo việc giữa các trạng thái có thể gây ra ảnh
hưởng rất bất ngờ.

Các sự kiện theo Flow


Kanban trong ngữ cảnh Scrum không đòi hỏi thêm bất cứ sự kiện nào ngoài những sự
kiện đã được định ra trong Tài Liệu Hướng Dẫn Scrum. Tuy vậy nó sử dụng các sự kiện từ
góc nhìn flow và áp dụng các số đo flow trong các sự kiện của Scrum để tăng thêm sức
mạnh cho hướng tiếp cận dựa trên thực nghiệm.

Sprint
Những điều bổ sung trong Kanban không thay thế Sprint của Scrum. Ngay cả trong những
môi trường đã đạt được hoặc mong đợi đạt được flow liên tục, Sprint vẫn đóng vai trog
giữ nhịp như nhịp đập của trái tim cho tính thanh tra và thích nghi cho cả sản phẩm lẫn
quy trình. Các đội sử dụng Scrum cùng với Kanban cũng dùng các sự kiện trong Sprint
như một chu kỳ phản hồi cải tiến thông qua sự cộng tác trong thanh tra và thích ứng định
nghĩa ‘‘Workflow’’ và các số đo của flow.
Những thực hành của Kanban có thể giúp Development Team cải tiến flow và tạo ra một
môi trường ra quyết định đúng lúc trong suốt Sprint dựa trên sự thanh tra và thích ứng.
Trong môi trường này, Development Team dự trên mục tiêu của Sprint và sự cộng tác
chặt chẽ với Product Owner để tối ưu các giá trị chuyển giao trong Sprint.

Sprint Planning
Một buổi Sprint Planning dựa trên flow sẽ sử dụng các số đo của flow để bổ sung cho việc
phát triển Sprint Backlog. Ví dụ như, sử dụng thông lượng trong quá khứ để tìm hiểu khả
năng của Scrum Team cho Sprint kế tiếp.

Daily Scrum
Một buổi Daily Scrum dựa trên flow sẽ tập trung vào việc đảm bảo Scrum Team đang làm
tất cả những gì nó có thể làm để bảo đảm một flow nhất quán. Trong khi mục tiêu của
Daily Scrum giống y như được định ra trong Tài Liệu Hướng Dẫn Scrum, cuộc họp này

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 7
được tổ chức xung quanh bảng Kanban và tập trung vào việc flow đang bị thiếu ở đâu và
hành động nào nên được Scrum Team thực hiện để xử lý việc đó.
Một số việc khác nên cân nhắc trong buổi Daily Scrum dựa trên flow:
 Mục công việc nào đang bị đình trệ và Development Team có thể làm gì để giải
quyết?
 Công việc nào đang lưu thông chậm hơn mong đợi? Tuổi của các hạng mục việc
đang thực hiện? Mục nào sắp vi phạm SLE và Scrum Team cần làm gì để hoàn tất
chúng?
 Có bất cứ điều gì có thể gây ảnh hưởng làm cho Scrum Team không thể hoàn tất
công việc hôm nay mà chưa thể hiện trên bảng không?
 Đội có tìm ra được điều gì mới có thể làm ảnh hưởng đến kế hoạch sắp tới của
Scrum Team không?
 Đội có vượt qua giới hạn WIP không? Và đội có thể làm được gì để bảo đảm hoàn
tất các công việc đang thực hiện?

Sprint Review
Tài Liệu Hướng Dẫn Scrum cung cấp chi tiết về buổi họp Sprint Review. Việc tìm hiểu các
số đo của flow trong Kanban như một phần của buổi họp này tạo ra cơ hội cho các trao
đổi về việc theo dõi tiến độ hướng đến mục tiêu. Việc đánh giá thông lượng có thể cung
cấp thêm thông tin cho Product Owner khi xác định các mốc phát hành dự kiến.

Sprint Retrospective
Một buổi Sprint Retrospective dựa trên flow sẽ có thêm phần khảo sát các số đo của flow
và những phân tích nhằm giúp cho việc xác định các điểm cần cải tiến mà Scrum Team
phải thực hiện trong quy trình của mình. Scrum Team sử dụng Kanban cũng thanh tra và
thay đổi để thích ứng định nghĩa ‘‘Workflow’’ nhằm tối ưu flow trong Sprint kế tiếp. Sử
dụng sơ đồ flow tích lũy (ND: Cumulative Flow Diagram - CFD) để trực quan hóa WIP của
Scrum Team, ước tính Thời gian Chu Kỳ trung bình và Thông lượng trung bình cũng có
thể có ích.
Bên cạnh Sprint Retrospective, Scrum Team nên cân nhắc việc tận dụng các cơ hội thanh
tra và thay đổi thích ứng thường xảy ra trong suốt thời gian của Sprint.
Tương tự, những thay đổi cho định nghĩa ‘‘Workflow’’ của Scrum Team cũng có thể diễn
ra bất cứ lúc nào. Bởi vì những thay đổi này sẽ tạo ra những ảnh hưởng cụ thể năng suất
của Scrum Team, để cho thay đổi diễn ra theo một nhịp nhất định như Sprint Retrospective
sẽ giảm thiểu sự phức tạp, tăng sự tập trung, tính cam kết và sự minh bạch.

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 8
Phần tăng trưởng của sản phẩm (ND: Increment)
Scrum yêu cầu đội phải (ít nhất) tạo ra một phần tăng trưởng hoàn tất có khả năng phát
hành được của sản phẩm sau mỗi Sprint. Chủ nghĩa thực nghiệm trong Scrum khuyến
khích việc tạo ra nhiều phần tăng trưởng có thể chuyển giao được của sản phẩm qua các
Sprint để thực hiện việc thanh tra và thích ứng nhanh chóng qua các chu trình phản hồi.
Kanban giúp quản lý flow của những chu trình phản hồi đó một cách tường minh hơn và
cho phép Scrum Team xác định những điểm tắt nghẽn, ràng buộc và khó khăn trở ngại để
chuyển giao các giá trị nhanh và thường xuyên hơn.

Lời kết
Scrum không phải là một quy trình hay một kỹ thuật. Nó là một cơ cấu tổ chức công việc,
trong đó, chúng ta có thể xử lý các vấn đề thích ứng phức tạp trong khi vẫn chuyển giao
sản phẩm một cách hiệu quả và sáng tạo, cho ra giá trị cao nhất có thể. Tài Liệu Hướng
Dẫn Scrum đã nói rõ, Scrum đóng vai trò như một tập chứa cho các kỹ thuật, phương
pháp và thực hành khác.
Các kỹ thuật tối ưu flow trong Kanban cung cấp cho Scrum Team cơ hội để thanh tra đúng
lúc đúng việc và dựa trên đó, thay đổi để thích ứng theo nhu cầu. Kanban đặc biệt tập
trung vào tính minh bạch, tính trực quan, và flow thì tối ưu phản hồi, chủ nghĩa thực
nghiệm và chuyển giao giá trị một cách tối ưu nhất.

Lịch sử phát triển và lời tri ân


Những thực hành thường được xem là Kanban hầu hết xuất phát từ năm 2006 của đội
Corbis trong công ty cấp phép truyền thông của Bill Gates. Những thực hành đó nhanh
chóng lan rộng trong cộng đồng quốc tế và theo thời gian, tiếp tục mở rộng, phát triển
hướng tiếp cận.
Hướng dẫn này được phát triển bằng sự cộng tác giữa Scrum.org, cộng đồng Professional
Scrum Trainer của Scrum.org, Steve Porter, Yuval Yeret và Daniel Vacanti.
Đặc biệt tri ân đến Louis-Philippe Carignan, Charles Bradley, Jose Casal, Andy Hiles và
Jesse Houwing vì sự cộng tác của họ. Chúng tôi biết ơn họ vì trong quá khứ đã đóng góp
biến Kanban trở thành một thành tựu và là một chiến lược lean-agile thành công.

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 9
Translator Acknowledgement
Tài liệu hướng dẫn này được dịch ra từ bản gốc tiếng Anh cung cấp bởi những người phát
triển như trong lời tri ân bên trên. Biên dịch bởi Đoàn Nguyễn Minh Tuệ
Thông tin liên lạc
Tên người biên dịch: Đoàn Nguyễn Minh Tuệ
Địa chỉ thư điện tử: tue.doannguyenminh@yahoo.com
LinkedIn: https://www.linkedin.com/in/tuedoannguyen

Cập nhật các bản dịch


# Phiên Mô tả Chịu trách nhiệm Ngày hoàn tất
bản

1 1.0.0 Biên dịch toàn bộ và chỉnh sửa Đoàn Nguyễn Minh Ngày 28 Tháng
chính tả Tuệ 10 Năm 2019

© 2019 Scrum.org. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also
described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this
Kanban Guide for Scrum Teams, you acknowledge and agree that you have read and agree to
be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Hướng dẫn Kanban cho Scrum Teams | Page 10

You might also like