1. Cộng đồng OpenERP Việt Nam terp.vn
Giới thiệu sơ lược về Scrum
Mục tiêu của bài viết này là nhằm giải thích những khái niệm cơ bản
về Scrum trong khuôn khổ của một bài viết ngắn để bạn đọc có thể hiểu sơ lược
về Scrum và có thể áp dụng Scrum vào việc phát triển các dự án của bạn. Đây là
bài viết lược dịch từ bài của tác giả Stephen Walther.
Product Backlog và Product Owner
Giả sự bạn là thành phần của một đội đang có nhu cầu tạo một website mới, ví dụ
như là một website thương mại điện tử (e-commerce). Các bạn có quá nhiều việc
để làm. Các bạn cần phải xây dựng giỏ hàng, cài đặt chứng chỉ SSL, tạo danh mục
sản phẩm, tạo trang giới thiệu trên Facebook và hàm tram thứ khác mà bạn chưa
kịp nghĩ đến.
Theo Scrum, việc đầu tiên bạn nên nghĩ đến đó là tạo ra một danh sách. Hãy đặt
các phần tử có độ ưu tiên cao nhất lên phía trên của danh sách, và các phần tử có
độ ưu tiên thấp hơn nằm ở dưới. Ví dụ như, tạo ra giỏ hàng và mua domain name
là công việc có độ ưu tiên cao, còn tạo ra trang Facebook thì có lẽ là có độ ưu tiên
thấp hơn. Với Scrum, danh sách này được gọi là Product Backlog.
Làm sao để bạn đặt độ ưu tiên cho các phần tử trong Product Backlog? Các bên
liên quan khác nhau của dự án sẽ có độ ưu tiên khác nhau. Giám đốc sản phẩm
thì cho rằng website thương mại điện tử bắt buộc phải có ứng dụng mobile.
Manager của bạn thì nghĩa rằng áp dụng các tính năng của HTML5 là quan trọng
hơn. Càng nhiều người tham gia, bạn sẽ càng thấy sự khác biệt về quan điểm, và
có lẽ sẽ làm bạn rối rắm hơn.
Theo Scrum, điều quan trọng nhất mà bạn nên làm đó là luôn chọn một người, và
chỉ một người làm Product Owner (chủ của sản phẩm). Product Owner là người
quyết định việc nào (hay tác vụ nào) sẽ được đặt vào Product Backlog và độ ưu
tiên của các phần tử trong Product Backlog. Product Owner có thể là khách hàng –
Trang 1/9

2. Cộng đồng OpenERP Việt Nam terp.vn
người trả chi phí thực hiện, cũng có thể là quản lý dự án – người có trách nhiệm
hoàn thành dự án, hoặc là một đại diện của khách hàng. Điểm mấu chốt đó là,
Product Owner luôn phải là một người duy nhất và cũng là người duy nhất có
quyền với Product Backlog.
Sprints và the Sprint Backlog
Lúc này, đội phát triển phần mềm đã có danh sách ưu tiên của các nhiệm vụ mà
họ có thể làm. Cả đội bắt đầu cài đặt thứ được ưu tiên nhất đó là giỏ hàng. Tuy
nhiên, khi công việc đi đến nữa đường thì Product Owner có ý thay đổi, anh ta cho
rằng nên tạo ra danh mục sản phẩm trước khi cài đặt giỏi hàng. Dù hơi phật ý,
nhưng cả đội vẫn chuyển qua tập trung vào việc cài đặt danh mục sản phẩm. Tuy
nhiên, khi công việc đã gần hoàn thành, Product Owner lại thay đổi quan điểm về
việc được ưu tiên nhất.
Khó có thể hoàn thành công việc khi độ ưu tiên dành cho các nhiệm vụ cần thực
hiện luôn thay đổi. Tuy nhiên, Product Owner vẫn có quyền để thay đổi độ ưu tiên
của các công việc cần thực hiện. Để giải quyết mâu thuẫn này, Scrum đưa ra khái
niệm về Sprint. Sprint được dịch bởi Google Translate là cuộc đua nước rút.
Khi áp dụng Scrum, nhóm phát triển sẽ làm việc trong các Sprint. Tại thời điểm
bắt đầu của một Sprint, các lập trình viên và Product Owner đồng ý về các phần tử
được chọn từ backlog mà họ sẽ phải hoàn thành trong suoosts quá trình của một
Sprint. Danh sách các việc cần hoàn thành lấy ra từ Product Backlog sẽ trở thành
Sprint Backlog. Trong suốt quá trình của Sprint, Product Owner không được phép
thay đổi các phần tử trong Sprint Backlog. Nói một cách khác, Product Owner
không được thay đổi độ ưu tiên của các phần tử cần thực hiện trong suốt thời gian
diễn ra Sprint.
Thời gian của mỗi Sprint được quyết định tùy thuộc vào mỗi đội phát triển, có thể
là một tháng, hai tuần hoặc chỉ là một tuần. Đối với các dự án mang tính cấp
bách, và thời gian là độ ưu tiên số một, các team thường chọn các sprint ngắn
(thường là một tuần). Đối với các dự án ổn định, thời gian một tháng sẽ hợp lý
hơn. Chúng ta nên chọn thời lượng của một Sprint một cách hợp lý và giúp ổn định
nhóm phát triển.
Daily Scrum
Trong suốt mỗi Sprint, nhóm phát triển phải gặp nhau để điều phối công việc
nhằm hoàn thành các nhiệm vụ ở Sprint Backlog. Ví dụ, cả nhóm cần phải thảo
luận xem thử ai làm việc gì và những vấn đề đã phát hiện ra và cần giải quyết.
Các lập trình viên thường ghét họp hành. Họp hành khiến lập trình viên không thể
làm việc chính của họ được, việc chính ở đây là lập trình, thay vào đó họ phải ngồi
bàn về những chuyện họ cần làm. Tuy nhiên, một đội không bao giờ họp hành và
không điều hành công việc của họ sẽ dẫn đến nhiều vấn đề. Ví dụ lập trình viên A
đang gặp phải một vấn đề và không giải quyết được trong nhiều ngày, trong khi
Trang 2/9

3. Cộng đồng OpenERP Việt Nam terp.vn
đó anh không biết rằng lập trình viên B đã gặp và giải quyết được. Hoặc có thể có
sự chồng chéo, trùng lắp trong công việc của các lập trình viên.
Với Scrum, để giải quyết các mâu thuẫn kể trên, đồng thời để đảm bảo tiến độ của
các đội, Scrum đưa ra ý tưởng về Daily Scrum. Daily Scrum là một buổi họp nhằm
điều hướng công việc của nhóm lập trình và là buỗi họp diễn ra mỗi ngày. Để giữ
cho buổi họp diễn ra nhanh chóng, các lập trình viên chỉ trả lời đối với ba câu hỏi
sau:
1. Bạn đã làm gì ngày hôm qua?
2. Bạn định làm gì hôm nay?
3. Có gì cản bước bạn không?
Trong suốt cuộc họp Daily Scrum, các lập tình viên không được phép nói chuyện
về các vấn đề không liên quan, trình diễn cái họ đã làm, hay nói về những kinh
nghiệm khi giải quyết các vấn đề lập trình. Buổi họp phải diễn ra nhanh gọn,
thường la ftrong 15 phút. Các vấn đề được nêu ra trong Daily Scrum sẽ được thảo
luận kỹ hơn trong các cuộc meeting khác, và lúc đó không cần thiết phải có sự có
mặt của toàn đội.
Stories và Tasks
Các phần tử trong Product Backlog hoặc Sprint Backlog như là xây dựng giỏ hàng
hoặc tạo ra trang Facebook thường được gọi là User Stories hoặc Stories. Các
Stories được tạo bởi Product Owner và chúng thường nói về nhu cầu dành cho sản
phẩm.
Khác với Product Owner, các lập trình viên cần phải nghĩ cách để cài đặt cho các
Story. Tại thời điểm bắt đầu của mỗi Sprint, nhóm phát triển sẽ lấy các Stories từ
Sprint Backlog và chia nhỏ các story thành các tasks (tác vụ).
Ví dụ, nhóm phát triển sẽ phân nhỏ story “Tạo giỏ hàng” thành các nhiệm vụ như
sau:
• Cho phép người dùng thêm và quản lý các phần tử trong giỏ hàng.
• Cập nhật giỏ hàng vào database sau mỗi lần viếng thăm
• Chuyển người dùng đến trang thanh toán khi nút Thanh toán được nhấn.
Trong suốt cuộc họp Daily Scrum, thành viên của nhóm phát triển sẽ xung phong
hoàn thành các task cần để cài đặt cho Story tiếp theo có trong Sprint Backlog.
Khi một lập trình viên nói về những việc anh ta đã hoàn thành vào ngày hôm qua,
và những việc sẽ làm kế tiếp, anh ta nên nói về các task.
Stories được sở hữu bởi Product Owner và mỗi story thường nói về giá trị thương
Trang 3/9

4. Cộng đồng OpenERP Việt Nam terp.vn
mại mang lại. Ngược lại, các task là do nhóm phát triển sở hữu, và task nói một
cách chi tiết về việc cài đặt. Mỗi story nếu muốn được cài đặt thì cần vài ngày
hoàn vài tuần để hoàn thành. Một task là một công việc mà một developer có thể
hoàn thành trong một khoảng thời gian ít hơn một ngày.
Một số nhóm thường biếng nhác và không chia nhỏ các stories thành tasks. Việc
không chuyển các stories thành tasks có thể biến các câu chuyện trở thành
“những câu chuyện không có hồi kết”. Nếu bạn không phân nhỏ một story thành
các tasks, bạn sẽ chẳng thể nào biết được một story sẽ được hoàn thành như thế
nào, bao nhiêu lâu, bởi vì bạn không có ý tưởng rõ ràng cho việc cần bao nhiêu
bước để hoàn thành một story.
Scrumboard
Trong mỗi Daiy Scrum, nhóm phát triển sẽ sử dụng Scrumboad để quản lý công
việc của họ. Một Scrumboard sẽ có danh sách các stories của Sprint hiện tại, các
tác vụ thuộc về mỗi Story, và trạng thái của mỗi Tasks. Mỗi thành viên trong nhóm
sẽ thấy được tiến độ công việc của bất cứ người nào khác trong nhóm.
Trang 4/9

5. Cộng đồng OpenERP Việt Nam terp.vn
Khi lập trình viên làm việc với một task, thì task sẽ được chuyển trạng thái này
sang trạng thái khác, và trạng thái của task sẽ được cập nhật trên Scrumboard.
Các task thông thường có các trạng thái là ToDo, In Progress và Done (Cần làm,
Đang làm, và xong). Một số nhóm còn thêm các trạng thái như Needs Review,
Needs Testing (cần xem lại, cần kiểm thử).
Một số nhóm sử dụng bảng Scrumboard vật lý. Lúc đó, bạn sẽ sử dụng các miếng
giấy để thể hiện các stories và các tasks và bạn sẽ dán các miếng giấy đó lên
bảng vật lý.
Sử dụng bảng Scrumboard vật lý mang lại đôi chút bất lợi. Thứ nhất là nó không
phù hợp với những nhóm làm việc phân tán. Thứ hai, tạo ra các báo cáo từ bảng
Scrumboard vật lý sẽ khó hơn nhiều so với việc xuất ra các báo cáo từ online
Scrumboard.
Ước lượng cho Stories và Tasks
Các bên liên quan trong dự án, những người đầu tư vào dự án cần phải biết dự án
đang tiến triển như thế nào và khi nào dự án sẽ hoàn thành. Và bạn không thể trả
lời rằng “dự án sẽ sớm xong thôi”, hoặc “chắc là sắp xong rồi”, hay “còn lâu nữa
mới xong”, bởi vì các bên liên quan có ngân quỹ giới hạn để đầu tư cho dự án. Và
nếu không biết được khi nào xong, thì các bên liên quan hoàn toàn không thể xác
định giá trị mang lại của dự án.
Các lập trình viên ghét phải ước lượng thời gian phát triển các tính năng. Lý do
chính là bởi vì hầu như chả bao giờ họ có thể ước lượng đúng, và họ chỉ có thể ước
lượng khi bắt tay vào nghiên cứu, và chỉ có thể biết được thời gian chính xác khi
họ đã làm xong. Bởi lập trình giống như việc tìm ra phương thuốc chữa bệnh ung
thư hơn là ngồi xây một bức tường bằng gạch. Việc xây tường thì thật đơn giản, cứ
thế mà trộn hồ, trét vữa bỏ gạch.. là xong. Việc xây tường quen thuộc đến mức
hầu như chả có chuyện gì xảy ra để mà ngạc nhiên.
Viết mã chương trình thì lại giống như việc tìm phương pháp chữa bệnh ung thư,
bác sĩ sẽ không thể đoán được khi nào sẽ tìm ra phương pháp chữa bệnh nếu bạn
đòi hỏi ông ta ước lượng thời gian. Lý do chính để không ước lượng được là vì bài
toán có nhiều yếu tố chưa xác định. Và thật khó để có thể ước lượng được nếu
không bắt tay vào nghiên cứu và chữa bệnh.
Rõ ràng là các lập trình viên ghét phải ước lượng, nhưng Product Owner và các
bên liên quan lại cần có ước lượng. Scrum sẽ giải quyết mâu thuẫn này bằng cách
sử dụng ý tưởng Story Points.
Các đội khác nhau sẽ dùng các loại đơn vị khác nhau để đại diện cho các Story
Points. Một số nhóm dùng kích thước của áo quần như Small, Medium, Large và X-
Large. Một số nhóm lại thích dùng kích cở của ly cà phê như Tall, Shot và Grande.
Trang 5/9

6. Cộng đồng OpenERP Việt Nam terp.vn
Các nhóm khác lại thích sử dụng các số lấy từ dãy Fibonacci.
Cho dù bạn có chọn loại đơn vị để đại diện cho Story Points như thế nào đi nữa, thì
mục tiêu vẫn là giống nhau. Thay vì ước lượng một Story theo giờ (thường thì lúc
nào cũng ước lượng sai), bạn sẽ dùng phương thức đo ít chi li hơn. Nhóm lập trình
sẽ thích ước lượng một Story là Small hoặc X-Large hơn là số lượng chính xác là
bao nhiêu giờ để để hoàn thành một Story. Như vậy, Story Points cũng có thể xem
là sự thỏa hiệp giữa nhu cầu của Product Owner và nhu cầu của nhóm phát triển.
Khi Sprint bắt đầu, nhóm phát triển sử dụng nhiều thời gian để suy nghĩ về các
Stories trong Sprint và chia nhỏ các Stories thành các Tasks. Trong Scrum, bạn ước
lượng thời gian hoàn thành Story bằng các Story Points và bạn sẽ ước lượng khối
lượng công việc cần phải làm để hoàn thành mỗi task bằng giờ.
Sự khác biệt giữa Stories và Tasks đó là bạn không tạo ra một task cho tới khi bạn
sẵn sàng làm việc với một task. Một task là thứ mà bạn có tể tạo và thực hiện
trong một ngày, và lúc đó bạn có thể ước lượng chính xác để hoàn thành một task
hơn là một story.
Burndown Charts
Ở Scrum, bạn có thể sử dụng Burndown charts để hiển thị những công việc còn lại
của một dự án. Bạn sử dụng Release Burndown charts để hiển thị công việc còn lại
của một dự án và bạn có thể sử dụng Sprint Burndown charts để hiển thị công
việc còn lại của một Sprint.
Bạn có thể tạo ra Release Burndown chart bằng cách tính toán số Story Points
chưa hoàn thành của Product Backlog mỗi ngày. Trục dọc của biểu đồ biểu diễn số
lượng Story Points, và trục ngang của biểu đ biểu diễn thời gian.
Trang 6/9

7. Cộng đồng OpenERP Việt Nam terp.vn
Sprint Burndown chart cũng tương tự như Release Burndown chart, nhưng nó tập
trung vào các công việc còn lại cho một Sprint cụ thể. Có hai loại Sprint Burndown
chart. Bạn có thể hiển thị khối lượng công việc của một Sprint bằng Story Points
hoặc bằng giờ.
Khi mỗi Story trong Product Backlog được hoàn thành, đường đồ thị trong Release
Burndown chart sẽ đi xuống. Khi mỗi Story hoặc task được hoàn thành, đường đồ
thị Sprint Burndown chart cũng sẽ đi xuống.
Mục đích của Burndown chart là giúp cho bạn có thể theo dõi tiến trình làm việc
của cả nhóm. Nếu qua nữa thời gian của một Sprint, Sprint Burndown chart vẫn
còn rất cao thì rõ ràng là đội của bạn đang gặp vấn đề.
Team Velocity
Các bên liên quan trong một dự án luôn muốn công việc được làm nhanh hơn nữa.
Ví dụ, Product Owner của website thương mại muốn website sẽ online một thời
gian ngắn. Các lập trình viên có thể sẽ rất lạc quan và sẽ đồng ý với yêu cầu của
Product Owner. Tuy nhiên, hiếm khi các lập trình viên biết được giới hạn vật lý của
chính họ.
Thường thì các bên liên quan và nhóm lập trình hay ước lượng thời gian phát triển
phần mềm quá hoàn hảo, với năng suất tối ưu. Điều đó dẫn đến một thực tế là, rất
nhiều dự án phần mềm bắt đầu với ước lượng rất lạc quan và sau đó lại trễ hẹn
Trang 7/9

8. Cộng đồng OpenERP Việt Nam terp.vn
một cách đáng thất vọng.
Với Scrum, vấn đề trên sẽ được khắc phục thông qua một đại lượng có tên là Team
Velocity (velocity có nghĩa là vận tốc). Team Velocity là số lượng Story Points trung
bình mà nhóm lập trình hoàn thành trong các Sprints trước.
Xác định được Team Velocity rất quan trọng đối với cuộc họp Sprint Planning, vì tại
thời điểm đó Product Owner và nhóm lập trình sẽ làm việc cùng nhau để ước đoán
số lượng stories có thể hoàn thành trong Sprint tiếp theo. Nếu xác định được Team
Velocity, bạn có thể tránh được việc giao công việc quá sức của nhóm so với khả
năng đã thể hiện trước đây, và nhóm của bạn có thể hoàn thành tất cả các công
việc cần thiết cho Sprint tiếp theo.
Scrum Master
Có ba vai trò trong Scrum: Product Owner, nhóm phát triển và Scrum Master.
Chúng ta đã đề cập đến Product Owner. Product Owner là người duy nhất quản lý
Product Backlog và sắp xếp độ ưu tiên của các stories.
Chúng ta cũng đã đề cập đến vai trò của nhóm phát triển. Các thành viên của
nhóm phát triển làm công việc triển khai xây dựng các stories bằng cách chia nhỏ
các stories thành các task.
Có một vai trò mà chúng ta chưa nhắc đến, đó là Scrum Master. Scrum Master có
vai trò đảm bảo cho cả đội làm việc theo quy trình Scrum. Ví dụ, Scrum Master sẽ
đảm bảo cả đội sẽ tham gia các cuộc họp Daily Scrum và trong mỗi cuộc họp các
thành viên sẽ trả lời đầy đủ ba câu hỏi tiêu chuẩn.
Scrum Master cũng có vai trò loại bỏ các chướng ngại (không phải về kỹ thuật) mà
cả nhóm có thể mắc phải. Ví dụ, nếu cả đội không thể làm việc cho tới khi mọi
người đều cài đặt phiên bản mới nhất của Microsoft Visual Studio, vì
vậy, Scrum Master sẽ làm việc với IT để đảm bảo phiên bản mới nhất của Visual
Studio được cài đặt càng sớm càng tốt.
Scrum Master có thể là thành viên của đội phát triển. Tuy nhiên, vị trí này có thể
cho những người khác nhau đảm đương. Một điều bạn cần đặc biệt lưu ý, đó
là Scrum Master không thể là Product Owner, hay nói theo một cách khác, không
thể để một người đảm nhiệm cùng một lúc hai vai trò này.
The Scrum Master can be a member of the developer team. Furthermore, different
people can take on the role of the Scrum Master over time. The Scrum Master,
however, cannot be the same person as the Product Owner.
Tổng kết
Bài viết này đã đề cập nhiều khái niệm cơ bản về Scrum. Bạn đã được biết Product
Trang 8/9

9. Cộng đồng OpenERP Việt Nam terp.vn
Owner sử dụng Product Backlog để tạo và sắp xếp độ ưu tiên của các stories.
Chúng ta cũng đã được giải thích tại sao công việc được hoàn thành trong các
Sprints, và nhờ vậy nhóm lập trình làm việc có hiệu suất cao hơn.
Chúng ta cũng đã được giải thích về cách mà nhóm lập trình viên sử dụng
daily scrum để quản lý công việc. Bạn cũng đã biết về cách mà nhóm lập trình
viên sử dụng Scrumboard để xem, theo dõi ai đang làm tác vụ gì và trạng thái của
mỗi task.
Chúng ta cũng đã được giới thiệu sơ qua về các biểu đồ Burndown. Chúng ta cũng
đã biết cách sử dụng Realease Burdown charts và Sprint Burndown charts để theo
dõi tiến trình của đội trong việc hoàn thành dự án.
Cuối cùng bài viết đã mô tả vai trò của Scrum Master, người có vai trò đảm bảo
các quy tắc của Scrum được tuân thủ.
Mục tiêu của bài viết này không phải để diễn tả tất cả các khái niệm của Scrum.
Bài viết này chỉ nhằm giới thiệu tổng quan. Để hiểu rõ về Scrum, bạn nên đọc
cuốn sách của Ken Schwaber có tựa đề “Agile Project Management with Scrum”.
(Nguồn internet)
Trang 9/9