Phần mềm-Ứng dụng

Scrum là một phương pháp Agile (phát triển phần mềm linh hoạt) dựa trên cơ chế lặp và tăng trưởng. Scrum được thiết kế để hỗ trợ việc phát triển, cung cấp và cải tiến các sản phẩm phức tạp. Với Scrum, sản phẩm được xây dựng trong một chuỗi các quy trình lặp lại, có tên là vòng sprint. Qua đó, bạn có thể liên tục cải tiến sản phẩm, kỹ thuật, team (nhóm) và môi trường làm việc. Cũng nhờ vậy mà bạn có thể cung cấp giá trị cho khách hàng trong suốt quá trình phát triển.

Scrum là một khung tổ chức công việc (framework) dùng trong các dự án phát triển phần mềm với mục tiêu là chuyển giao các sản phẩm mới đều đặn, sau từ 1-4 tuần. 

Theo Scrum.org - đơn vị nổi tiếng giới thiệu các lý thuyết về Scrum, Scrum là một framework giúp chúng ta giải quyết các vấn đề phức tạp luôn thay đổi, mà vẫn giữ hiệu quả và sáng tạo khi chuyển giao các sản phẩm có giá trị cao. 

Scrum cũng được tổ chức này nhấn mạnh, không phải là một hệ thống các phương pháp luận (methodology). Mà nó bao gồm các cách thức nhất định để giúp 1 nhóm làm việc cộng tác với nhau trong thực tiễn nhằm chuyển giao sản phẩm phức tạp (như phần mềm). 

Scrum khuyến khích team học tập qua trải nghiệm, tự tổ chức các hoạt động của team để giải quyết các bài toán, và reflect - suy tưởng, phản tư về những thành công cũng như thất bại của team để liên tục tìm ra các cải tiến. 

Scrum có phải là Agile?

The answer: Scrum is just one of the ways to achieve agile thinking. Scrum is in the big Agile umbrella. That big umbrella includes many different methods, ways and practices.

‍

Có thể nói, Scrum là một trong những cách tiếp cận phổ biến nhất hiện nay khi đội nhóm muốn ứng dụng agile vào công việc. 

Cần lưu ý rằng Scrum là khung làm việc, còn Agile là mindset. Agile mindset là tư tưởng, tư duy làm việc. Triết lý agile chỉ đề cập đến 4 giá trị và 12 nguyên tắc định hướng giúp phát triển phần mềm một cách linh hoạt, nhanh chóng đưa ra thị trường, chứ không chỉ rõ cụ thể ta nên làm như thế nào khi ứng dụng vào đội nhóm. 

Bởi vậy, chúng ta khó có thể trở thành người có Agile mindset ngay trong 1 thời gian ngắn.  Nhưng bằng cách sử dụng các framework (trong đó Scrum là 1 loại framework phổ biến), chúng ta có thể rút ngắn quá trình đưa những giá trị và nguyên tắc của Agile vào thực tiễn công việc hàng ngày. 

Các trụ cột của Scrum

Scrum được xây dựng dựa trên những lý thuyết về quy trình thực tế. Những lý thuyết này dựa trên 3 trụ cột.

1. Minh bạch (transparency)

Sức mạnh của một dự án hay một công ty nằm ở việc mọi người phối hợp với nhau để hoàn thành mục tiêu, sứ mệnh đã đề ra. Để có thể đẩy thuyền đi đến đích, các team, các thành viên cần được truy cập vào những thông tin hữu ích với họ trong quá trình phát triển sản phẩm. 

Trong Scrum đề ra các sự kiện họp như Sprint Planning, Sprint Review, Sprint Retrospective, daily meeting để giúp tăng cường sự tương tác và trao đổi thông tin giữa các thành viên làm việc. 

Khía cạnh minh bạch này cũng liên quan mật thiết tới 2 trụ cột còn lại. Sẽ rất khó để có thể thanh tra nếu công việc, quy trình không hiển lộ ra cho người khác biết. Và cũng sẽ rất khó để kịp thời, nhanh chóng điều chỉnh kế hoạch nếu bị thiếu thông tin, hoặc nhiễu loạn thông tin.

Ví dụ:

Daily meeting là lúc để các thành viên trao đổi, tương tác với nhau về công việc, về sản phẩm đang thực hiện. Đồng thời nhìn vào những công cụ trình bày, như Kanban board, thể hiện rõ quy trình, trạng thái của luồng việc sẽ giúp cả độ phát triển và Product Owner hiểu nhau hơn, đồng thời có thể nhanh chóng xử lý các vấn đề vướng mắc hoặc chưa được làm rõ. 

2. Thanh tra (inspection)

Để đảm bảo chất lượng cho sản phẩm, tránh những sự sai khác quá lớn về sản phẩm làm ra thực tế so với sản phẩm mong muốn ban đầu, chúng ta cần phải thanh tra những thứ được tạo ra một cách thường xuyên, định kỳ. 

Sự thanh tra được thực hiện ở một thời điểm nhất định, chứ không nên xen ngang vào giữa chừng. 

Ví dụ: Các thành viên đội phát triển cùng với Product Owner tham gia Sprint Review, Sprint Retrospective. Đây là các hoạt động thể hiện tính chất thanh tra. Khi ấy họ sẽ thanh tra chính sản phẩm chuyển giao, và các quy trình phát triển sản phẩm. 

3. Thích nghi (adaptation)

Khi có sự chệch hướng so với Product Roadmap, hoặc do nhu cầu thị trường thay đổi, sản phẩm và quy trình cũng cần được điều chỉnh nhanh chóng để thích nghi với những thay đổi này. 

Ví dụ: Đội phát triển cần thích ứng sản phẩm của mình vào cuối mỗi Sprint, để phù hợp với lộ trình phát triển sản phẩm, với yêu cầu của Product Owner, hay của các Stakeholders

Các giá trị của Scrum

Các giá trị cốt lõi của Scrum được hiểu là những người sống với giá trị này sẽ dễ dàng hơn khi thực hiện Scrum trong công việc. Đó là.

1. Dũng cảm - Courage

Dũng cảm là một giá trị rất quan trọng mà các thành viên team Scrum cần hướng tới. Đội Scrum hay development team cần phải cảm thấy an toàn để nêu ra ý kiến của mình, để nói không khi cần, và thử nghiệm những điều mới mẻ. Đội phát triển cũng cần sự dũng cảm để thách thức những mô thức cũ, cản trở con đường đạt được mục tiêu. 

2. Tập trung - Focus

Scrum coi trọng sự tập trung vào ít thứ. Nghĩa là bắt đầu một thứ và kết thúc nó, hạn chế số lượng công việc đang diễn ra cùng lúc, hạn chế số việc ở trạng thái Doing (limit WIP)

3. Cam kết - Commitment 

Các thành viên của team làm việc Scrum cần phải có sự cam kết với các mục tiêu của đội nhóm. Họ là người lựa chọn sẽ thực hiện điều gì, và gắn chặt với những điều mình chọn. 

Như bạn đã biết, lõi của Scrum là Sprint. Mỗi Sprint đều cần có những mục tiêu rõ ràng trong 1 timebox (từ 1-4 tuần). Đội phát triển có thể chia nhỏ mục tiêu thành các phần có thể xử lý được và bắt tay vào thực hiện công việc. Các thành viên cần đánh giá tính thực tế của các mục tiêu đưa để thống nhất các công việc cần hoàn thành cho phù hợp để họ giữ được cam kết với những thứ mình mong muốn chuyển giao.

4. Tôn trọng - Respect

Các thành viên trong Scrum team hay đội phát triển cần thể hiện sự tôn trọng lẫn nhau, tôn trọng Product Owner và các bên liên quan (Stakeholders), cũng như Scrum Master. 

Các đội nhóm sống với tinh thần Agile cần biết rằng sức mạnh để đạt được mục tiêu nằm ở trí tuệ tập thể, ở cách thức họ cộng tác ăn ý với nhau. Mỗi cá nhân đều có đóng góp nhất định vào mục tiêu của Sprint. Vì vậy, họ cần tôn trọng ý kiến của nhau, ghi nhận nỗ lực của nhau, thậm chí chấp nhận sự không hoàn hảo của các thành viên.

5. Cởi mở - Openness

Đội phát triển cần không ngừng tìm kiếm những ý tưởng mới, những cơ hội mới để học hỏi. Một đội nhóm agile cũng cần thành thật với nhau khi cần sự giúp đỡ. 

Các công cụ của Scrum

1. Product backlog

Product backlog là một danh mục các công việc cần hoàn thành, được quản lý bởi Product Owner hoặc Product Manager. 

Danh mục này là một danh sách các tính năng, yêu cầu, nâng cấp hoặc lỗi là đầu vào cho Sprint backlog. Bản chất của Product Backlog là to-do list.

Do những công việc trong Product Backlog có thể bị thay đổi do yêu cầu của khách hàng thay đổi, nhu cầu thị trường thay đổi nên nó cần Product Owner thường xuyên chăm nom, sắp xếp thứ tự ưu tiên và quản lý, duy trì.

2. Sprint backlog

Sprint backlog là một danh sách các đầu việc, hoặc user story, bug được lựa chọn bởi development team (đội phát triển), mang vào để triển khai trong 1 Sprint. Trước mỗi Sprint, đội phát triển sẽ có buổi họp Sprint Planning để lựa chọn sẽ thực hiện các đầu việc nào từ Product Backlog.  

Sprint Backlog có thể linh hoạt và tiến hóa trong 1 Sprint. Tuy nhiên những mục tiêu cơ bản Sprint goal - điều mà team muốn đạt được trong Sprint đó thì không thể nhượng bộ. 

3. Increment (Sprint Goal)

Là sản phẩm có thể dùng được từ 1 Sprint. 

Ở Magestore, chúng mình sẽ chuyển giao increment - phần tăng trưởng của sản phẩm vào cuối mỗi tuần cho người dùng. Sprint của chúng mình được cả công ty ấn định là kéo dài 1 tuần. Và cứ đến sáng thứ 2 của tuần mới, các team sẽ cùng minh họa và giới thiệu các sản phẩm này tới toàn công ty để mọi người cùng hiểu được các team khác đang có bước tiến như thế nào trong sự phát triển của toàn công ty. 

Bạn có thể ít nghe đến từ Increment vì có thể mọi người thường dùng từ Sprint Goal, milestone, hay hoặc shipped epic. Đó là tùy thuộc vào mỗi công ty, mỗi đội nhóm và cách định nghĩa hoàn thành của bạn. 

4. Burndown chart

Burndown chart là biểu đồ thể hiện lượng công việc còn lại tới khi hoàn thành. Nó thể hiện tốc độ team của bạn “đốt cháy” các công việc để tiến tới mục tiêu như thế nào. 

Trục dọc thường là lượng công việc, trục ngang là ngày hoặc Sprint.  

Nếu nhìn vào Sprint burndown, thấy công việc của team bạn đang chậm chơi so với kỳ vọng, biểu thị lượng việc hoàn thành đang ít, cột việc còn lại vẫn cao qua 2-3 ngày đầu của Sprint, team bạn cần để ý và tập trung hoàn thành các đầu mục việc quan trọng nhất để đạt mục tiêu Sprint. Cùng với đó có thể họp làm mịn, tìm ra các nút thắt cản trở công việc được hoàn thành. 

Nhìn vào Product Burndown chart qua các Sprint tuần tự, bạn cũng sẽ thấy nhịp độ chuyển giao công việc của team. Sẽ không có 1 đường thẳng tắp từ trên xuống dưới vì đội nhóm nào cũng sẽ gặp những biến cố hoặc trắc trở hoặc thuận lợi khác nhau khiến cho nhịp độ chuyển giao lên xuống dao động qua từng Sprint. Nhưng nhìn vào biểu đồ, bạn cũng sẽ có cái nhìn tổng quan hơn về tiến trình thực hiện product backlog hoặc project. 

Các vai trò trong đội nhóm sử dụng Scrum

Vai trò và kỹ năng của từng bộ phận: Phân biệt rõ sự khác biệt giữa về công việc, trách nhiệm giữa các vai trò trong Scrum và các kỹ năng cần thiết ở từng vị trí. Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra 03 vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm:

1. Product Owner

Product Owner là người chịu trách nhiệm về thành công của dự án, hoặc của sản phẩm. Họ sẽ tập trung vào khía cạnh business (kinh doanh), khía cạnh khách hàng và nhu cầu của thị trường, sau đó thiết lập các ưu tiên cho công việc để đội phát triển tiến hành. 

Một Product Owner hiệu quả là người:

• Xây dựng và quản lý tốt product backlog
• Có mối quan hệ chặt chẽ về phía doanh nghiệp và đội phát triển, đảm bảo rằng tất cả 2 bên cùng hiểu các hạng mục công việc trong Product Backlog. 
• Đưa ra những định hướng rõ ràng cho đội phát triển về các tính năng sẽ chuyển giao
• Quyết định khi nào sẽ chuyển giao sản phẩm và với chu kỳ chuyển giao như thế nào. 

2. Scrum Master

Scrum Master là người am hiểu rõ về Scrum trong đội phát triển. Họ sẽ coach team, Product Owners và các bên liên quan khi những người này tham gia vào quy trình Scrum.

Một Scrum Master có năng lực là người hiểu các công việc được thực hiện bởi đội phát triển và giúp đội này tối ưu hóa sự minh bạch và hiệu suất chuyển giao. Anh ấy/cô ấy giữ vai trò người điều phối (facilitator), tập hợp các nguồn lực cần thiết (cả về nhân sự lẫn trang thiết bị, logistics…) cho các buổi họp Sprint Planning, Stand-up, Sprint Review, Sprint Retrospective.

3. Development Team (BA, Developer, Tester...)

Đội phát triển chính là những người thực hiện xây dựng sản phẩm, hoàn thành những thứ cần được chuyển giao tới khách hàng. 

Một đội phát triển hiệu quả bao gồm các thành viên có mối quan hệ thân thiết với nhau, ngồi gần nhau trong cùng 1 không gian (co-located) và thường có từ 5-7 thành viên. 

Một trong những quy tắc để xác định số lượng thành viên cho đội phát triển, dựa trên câu nói nổi tiếng của Jeff Bezos, CEO Amazon: “Một team chỉ nên đủ nhỏ để ăn chung 2 chiếc bánh pizza.” - (8 miếng bánh-> tối đa 8 người)

Đội phát triển này nên là một cross-function team, gồm những người có nhóm kỹ năng khác nhau (skill set), để có thể training lẫn nhau, nhờ đó không ai trở thành nút thắt trong luồng chảy công việc. 

Đồng thời, đội này cùng cần là một đội tự tổ chức (self-organizing team). Họ được trao quyền để lựa chọn sẽ giải quyết các bài toán được đề ra như thế nào. Họ cũng là những người sẽ dự tính khối lượng công việc mà họ có thể hoàn thành được trong Sprint và cam kết với chúng. 

Scrum diễn ra như thế nào?

1. Tổ chức backlog (hay còn được gọi là backlog grooming)

Đây thường là trách nhiệm của Product Owner. PO là người định hướng sản phẩm tới tầm nhìn đã đưa ra. PO cũng cần có sự nhanh nhạy về mặt thị trường, về khách hàng để thay đổi lộ trình phát triển sản phẩm khi cần. 

PO đồng thời sẽ là cầu nối giữa người dùng và khách hàng với đội phát triển. PO sẽ tiếp nhận ý kiến phản hồi từ cả 2 phía để tạo nên một danh mục các công việc sẵn sàng cho việc triển khai trong thời gian tiếp theo.

2. Sprint Planning (Họp kế hoạch Sprint)

Đây là cuộc họp lên kế hoạch, đặt mục tiêu cho Sprint của đội phát triển. Các user story cụ thể sẽ được thêm vào Sprint backlog từ Product backlog. Các user story cần được các thành viên đồng thuận với nhau rằng là khả thi để thực hiện trong Sprint này. 

Cuối buổi họp Sprint Planning, đội phát triển cần rõ với nhau về những gì sẽ cần được chuyển giao trong Sprint, và các phần tăng trưởng sản phẩm sẽ chuyển giao sẽ trông như thế nào. 

3. Diễn biến trong Sprint

Một Sprint kéo dài ít nhất là 1 tuần, nhiều nhất là 4 tuần. Đây là khoảng thời gian đội phát triển làm việc, phối hợp với nhau để hoàn thành phần tăng trưởng sản phẩm (increment). 

Trong khoảng thời gian này, phạm vi công việc của Sprint có thể được Product Owner và đội phát triển (development team) mang ra thương lượng, nếu thấy cần thiết. 

Tất cả các sự kiện từ Planning cho đến Retrospective đều diễn ra trong phạm vi 1 Sprint. 

Thời lượng của 1 Sprint nên được giữ vững trong một khoảng thời gian phát triển sản phẩm, điều này giúp cho đội phát triển học được từ các trải nghiệm trong quá khứ và áp dụng chúng vào các Sprint trong tương lai. 

4. Daily meeting (Daily Scrum)

Đây là các buổi họp cực ngắn, tổ chức vào một khung giờ cố định, hàng ngày. Các thành viên tham gia trả lời 3 câu hỏi: Hôm qua làm gì? Hôm nay sẽ làm gì? Khó khăn, trở ngại đang gặp phải là gì? 

Cuộc họp này chỉ nên giới hạn trong 15 đến 30 phút. Mục đích là để kiểm tra tiến độ hoàn thành sprint goal và điều chỉnh sprint backlog nếu cần thiết. Ngoài ra, các buổi daily Scrum còn phải đưa ra được kế hoạch làm việc cho 24 giờ tiếp theo.

5. Sprint Review (Họp sơ kết Sprint)

Cuối mỗi Sprint, team sẽ tụ họp với nhau trong một buổi để demo increment - phần tăng trưởng sản phẩm. Team cũng sẽ chỉ ra những hạng mục công việc đã hoàn thành, và đón nhận góp ý từ product owner. 

Product Owner sẽ là người quyết định có phát hành phần tăng trưởng sản phẩm này hay không.
Sprint Review cũng là lúc để Product Owner nhìn lại vào Product Backlog sau khi Sprint vừa diễn ra, đưa ra những dự định cho Sprint tiếp theo. 

6. Sprint Retrospective (Họp Cải tiến Sprint)

Retrospective là cuộc họp để đội phát triển cùng ngồi lại với nhau và trao đổi về những gì đã diễn ra thuận lợi, những gì chưa tốt trong Sprint.  Đó có thể là về quy trình, về con người, về công cụ, thậm chí về chính các sự kiện họp diễn ra trong Sprint. 

Mục đích của Retrospective là tạo ra không gian và cơ hội để các thành viên reflect, tìm ra các cải tiến cho Sprint tiếp theo.

 

Nội dung cần nhớ của quy trình Scrum

Không thực hiện đưa toàn bộ yêu cầu/ nghiệp vụ hệ thống vào Code và Testing cùng một lúc, mà sẽ chia các yêu cầu làm theo từng giai đoạn. Mỗi giai đoạn chỉ làm một số lượng yêu cầu nhất định.

• Chia thành nhiều giai đoạn nhỏ để thực hiện hay còn gọi lại Sprint.
• Mỗi 1 Sprint thường kéo dài từ 1 đến 4 tuần (không dài hơn 1 tháng).
• Đầu Sprint sẽ lên kế hoạch làm những yêu cầu nào, sau đó sẽ thực hiện code và test. Cuối Sprint là một sản phẩm hoàn hiện cả code lẫn test có thể demo và chạy được.
• Hoàn thành Sprint 1, tiếp tục làm Sprint 2... cho đến khi hoàn thành hết các yêu cầu.
• Trong mỗi 2 Sprint thì sẽ có họp hàng ngày – daily meeting. Cả team sẽ đứng họp thành 1 vòng tròn (xung quanh bàn đó mà :)) ) thường chỉ họp 15-20 phút (nếu làm remote thì có khi lên 30p tùy ngày). Mỗi thành viên sẽ báo cáo: Hôm qua đã làm gì? Hôm nay sẽ làm gì? Có gặp khó khăn gì không?...
• Trong mỗi 1 Sprint thì các thành viên của dự án phải tạo task cho code và test. Một task code xong là phải có task test liền ngay đó. Do thời gian làm ngắn nên hiệu quả làm việc cao, đúng tiến độ đảm bảo cuối Sprint là hoàn thành được cả test.
• Ưu điểm phù hợp với những yêu cầu nghiệp vụ hay thay đổi hoặc hệ thống nghiên cứu do làm theo từng giai đoạn ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù hợp để thay đổi.
• Điều hành đội dự án sẽ là Scrum Master, còn có Product Owner là người đánh giá phần mềm làm đã đúng nghiệp vụ/ yêu cầu chưa.

Cách vận hành Scrum trong một Sprint

• Lập kế hoạch & phân bổ nguồn lực trong Sprint Planning;
• Đánh giá hiệu quả sản phẩm trong Sprint Review;
• Nâng cao Performance với Restrospective;
• Nắm bắt tình trạng công việc qua Daily Scrum.

Có nên bắt đầu triển khai Scrum?

 Các quy tắc, các công cụ, sự kiện, vai trò trong Scrum khá dễ hiểu. Việc tổ chức các công việc phức hợp thành các phần nhỏ hơn là khía cạnh tiếp cận mà Scrum mang đến giúp team giải quyết các công việc khó. Đi kèm với đó, các vai trò và sự kiện được định sẵn giúp hình thành sự minh bạch và cộng tác cao trong suốt chu trình phát triển. 

Khi team liên tục chuyển giao giá trị, thì team sẽ có động lực hơn và hạnh phúc hơn khi nhìn thấy tiến trình phát triển của mình trong một thời gian ngắn. 

Đối với doanh nghiệp nói chung, ứng dụng Scrum có thể giúp doanh nghiệp đẩy nhanh tốc độ phát hành sản phẩm ra thị trường, tăng năng suất làm việc của nhân sự hay mang lại sự hài lòng cho khách hàng.

Tuy nhiên, càng ứng dụng Scrum, bạn sẽ thấy rằng sẽ cần thời gian để thành thạo Scrum. Các khái niệm về phân đoạn nhỏ như Sprint, các cuộc họp daily meeting, Sprint Review và các thực hành của Scrum master có thể là thách thức với nhiều team mới. 

Nhưng lợi ích lâu dài của Scrum sẽ rất đáng để bạn vượt qua những trở ngại ban đầu. Nếu tổ chức của bạn chưa áp dụng triết lý agile và sử dụng khung làm việc Scrum vào trong đội nhóm làm việc, thì có thể học từ những khái niệm cơ bản nhất, và thử ứng dụng với một team đang sống với các giá trị sát nhất với Scrum (dũng cảm, tập trung, cam kết, tôn trọng, cởi mở). 

Hiện tại đội nhóm của bạn đã áp dụng Scrum tới đâu rồi? Bạn có thể liên lạc với chúng mình để cùng nhau thảo luận về chủ đề này!
Chúc các bạn thành công trong việc ứng dụng Scrum vào công việc của đội nhóm, và đem lại nhiều giá trị hơn tới khách hàng!