EN |
VN
Rất nhiều đội ngũ phát triển phần mềm/sản phẩm theo phương pháp truyền thống – waterfall đã phải làm việc cả đêm và cuối tuần chỉ để theo kịp tiến độ, dù nhóm đã lên kế hoạch bao nhiêu thì lịch trình của cả nhóm dường như không bao giờ đủ để giải quyết hết tất cả những công việc đã đặt ra vì yêu cầu dự án luôn thay đổi liên tục.
Đối với những nhóm Agile, những khó khăn và rào cản đó dường như được phá bỏ. Nhưng bằng cách nào? Trong khi Agile Manifesto chỉ đề cập tới 4 giá trị cốt lõi, 12 nguyên tắc, giúp chúng ta hình thành được cách tư duy theo Agile – Being Agile. Làm sao để áp dụng Agile vào thực tế – Doing Agile? Câu trả lời là dựa vào những framework được xây dựng dựa trên Agile, và trong bài viết này, chúng ta sẽ cùng nhau tìm hiểu xem áp dụng Agile vào thực tế như thế nào thông qua một framework nổi tiếng và phổ biến nhất của Agile, đó chính là SCRUM.
Scrum là gì?
Scrum – phương pháp phổ biến nhất của Agile – là một framework cơ bản giúp việc tiếp cận, phát triển công việc/sản phẩm phức tạp một cách nhanh nhất, hiệu quả nhất. Theo kinh nghiệm thu được trong quá trình triển khai dự án với Scrum, để cho Scrum đạt được hiệu quả cao nhất thì nên tổ chức các team có ít nhất 3 người và tối đa 9 người (với những nhóm lớn, có thể chia thành những nhóm Scrum nhỏ hơn – Scrum of Scrums – sẽ được giới thiệu trong 1 bài viết khác). Để tìm hiểu về Scrum thì rất dễ, nhưng để áp dụng hiệu quả trong quá trình làm việc thì lại rất khó. Scrum bao gồm một tập các phương pháp thực hành (practices), vai trò (roles), sự kiện (events), tạo tác (artifacts) và quy tắc (rules) được thiết kế để làm “kim chỉ nam” cho team thực hiện dự án.
Những vai trò trong Scrum Team
Mỗi Scrum team sẽ có ba vai trò tương ứng với trách nhiệm, quyền hạn rõ ràng giúp cho công việc được tối ưu hóa. Ba vai trò của Scrum team bao gồm: Development Team, Product Owner và Scrum Master. Và khi ba bộ phận này kết hợp với nhau chúng ta sẽ có được toàn bộ Scrum team.
1. Development Team
Là những thành viên cùng tham gia trực tiếp vào quá trình phát triển những tính năng cụ thể của phần mềm/sản phẩm.
Các thành viên của Development Team tự tổ chức – nghĩa là họ được trao quyền để quản lý công việc của chính họ. Scrum cũng khuyến khích mỗi thành viên đều “đa di năng”, có thể đảm nhiệm nhiều hơn một vai trò nhất định miễn là cần thiết để hoàn thành công việc, chẳng hạn như phân tích, thiết kế, xây dựng, kiểm thử phần mềm/sản phẩm.
2. Product Owner
Giúp nhóm hiểu được nhu cầu của khách hàng/người dùng, từ đó nhóm có thể xây dựng sản phẩm/phần mềm có giá trị nhất.
Product Owner chịu trách nhiệm tối đa hóa giá trị của sản phẩm/phần mềm bằng cách quản lý Product Backlog hoặc danh sách công việc cần thực hiện. Điều này bao gồm việc đảm bảo các mục con trong product backlog (backlog items) được cập nhật liên tục và sắp xếp theo mức độ ưu tiên, giúp cho các thành viên trong nhóm hiểu được các tính năng, yêu cầu được liệt kê trong Product Backlog và tại sao người dùng cần chúng. Đây là một công việc thực sự quan trọng vì nó giúp nhóm xây dựng sản phẩm/phần mềm giá trị nhất có thể.
Product Owner cũng chịu trách nhiệm đảm bảo rằng khách hàng/người dùng và nhóm có sự hiểu biết chung về tầm nhìn dự án, mục tiêu dự án và chi tiết công việc sẽ được thực hiện, để nhóm có thể lập kế hoạch và xây dựng các hạng mục công việc một cách hiệu quả. Mặc dù Product Owner chịu trách nhiệm cuối cùng trong việc sắp xếp mức độ ưu tiên và cập nhật , nhưng Scrum Master hoặc Development Team cũng phải hỗ trợ quá trình này bằng cách chia sẻ thông tin về ước lượng (thời gian, chi phí, nguồn lực), tính phụ thuộc, các mục công việc kỹ thuật, v.v.
3. Scrum Master chịu trách nhiệm giúp nhóm hiểu và sử dụng Scrum hiệu quả
Scrum mô tả có thể đơn giản, nhưng không phải lúc nào cũng dễ dàng để hiểu đúng. Đó là lý do tại sao trong một nhóm cần có Scrum Master – người nắm toàn bộ công việc từ việc lên kế hoạch, phân công công việc, tổ chức các cuộc họp giúp Product Owner, Development Team và phần còn lại của công ty thực hiện Scrum một cách chính xác, hiệu quả nhất.
Scrum Master là một nhà lãnh đạo (đó là lý do tại sao từ “master” thể hiện trực tiếp ngay trong tên gọi). Nhưng Scrum Master lại thể hiện một kiểu lãnh đạo rất đặc biệt: Scrum Master is a servant leader – Scrum Master là một người lãnh đạo phục vụ. Điều này có nghĩa là người trong vai trò này dành toàn bộ thời gian của mình để giúp đỡ (hoặc “phục vụ”) cho Product Owner, Development Team và mọi người trong toàn tổ chức, giúp loại bỏ bất kỳ trở ngại nào đối với quá trình thực hiện và tạo điều kiện thuận lợi nhất cho họ, bao gồm:
▶ Giúp Product Owner tìm ra các cách hiệu quả để quản lý Backlog.
▶ Truyền đạt tầm nhìn dự án, mục tiêu dự án và chi tiết Backlog items cho Development Team, giúp Development Team hiểu các hoạt động đặc thù của Scrum và thực hiện chúng nếu cần.
▶ Giúp phần còn lại của tổ chức hiểu Scrum và phối hợp tốt với nhóm.
▶ Tạo điều kiện cho việc áp dụng Scrum không chỉ trong một dự án mà trên phạm vi rộng hơn là trong toàn tổ chức.
Như chúng ta cũng đã biết, Agile chia dự án thành những vòng lặp xoắn ốc – Iteration. Scrum cũng vậy, dự án được chia thành nhiều Sprint, mỗi Sprint tương ứng với một phân đoạn/giai đoạn được lặp đi lặp lại trong quá trình phát triển phần mềm/sản phẩm – còn được gọi là 1 timeboxed (time-limited) – khung thời gian giới hạn. Thông thường, mỗi Sprint kéo dài 1 tuần, 2 tuần, hoặc 4 tuần tùy theo team/công ty. Trong mỗi Sprint, những thay đổi nào mà ảnh hưởng đến mục tiêu Sprint (Sprint goal) sẽ không được thực hiện. Phạm vi dự án có thể được làm rõ hoặc bàn bạc lại khi có thông tin mới, nhưng nếu có một thay đổi mà Development team cần thực hiện thì điều này sẽ không được thực hiện trong Sprint đó.
Sprint có thể bị kết thúc trước khi timeboxed kết thúc, nếu mục tiêu Sprint trở nên lỗi thời vì sự thay đổi trong hướng kinh doanh hoặc điều kiện công nghệ không còn phù hợp. Tuy nhiên, chỉ Product owner mới có quyền kết thúc sớm một Sprint. Khi điều đó xảy ra, bất kỳ Backlog Items nào chưa hoàn thành sẽ được đánh giá lại và trả lại cho Product backlog.
Tuần tự các hoạt động trong mỗi Sprint bao gồm họp Sprint Planning (thực hiện đầu mỗi Sprint), họp Daily Scrums (thực hiện mỗi ngày trong một Sprint), họp Sprint Review (cuối Sprint), và họp Sprint Retrospective (sau Sprint Review).
Các hoạt động trong Scrum bao gồm: Product Backlog Refinement, Sprint Planning Meetings, Daily Scrum, Sprint Review và Sprint Retrospective.
Product Backlog Refinement:
Đây là một cuộc họp tập hợp tất cả mọi người cùng tham gia để thảo luận và cập nhật các mục trong Product Backlog. Bao gồm việc cập nhật chi tiết, xét độ ưu tiên cho từng backlog item. Giúp cho Product Backlog đạt được trạng thái “trau chuốt”, từ đó việc thực hiện các công việc cũng sẽ được suôn sẻ hơn, tập trung tối đa vào việc tạo ra sản phẩm/phần mềm tốt nhất.
Sprint Planning Meetings:
Được thực hiện đầu mỗi Sprint, trong Sprint Planning Meetings, mọi người sẽ quyết định lựa chọn những tính năng cần thực hiện, phân công công việc, phân rã những tính năng đó thành các nhiệm vụ (tasks) và lên kế hoạch xem công việc đó sẽ được thực hiện như thế nào trong Sprint này.
Product Owner sẽ cập nhật Backlog items và nhóm (Development Team + Scrum Master) sẽ thảo luận để đảm bảo tất cả mọi người cùng hiểu đúng về mục công việc đó.
Dựa trên ước tính, hiệu suất dự kiến và hiệu suất trong quá khứ, Development team sẽ dự đoán được khối lượng công việc có thể hoàn thành trong Sprint và từ đó sẽ xác định mục tiêu của Sprint – Sprint goal. Sau đó, Development team xác định cách xây dựng các chức năng cho sản phẩm/phần mềm và cách họ sẽ thực hiện để hoàn thành Sprint goal.
Sprint Planning Meetings sẽ có timeboxed thường là 2 – 4 tiếng. Cả nhóm sẽ tập trung phân rã, lập kế hoạch công việc cho ít nhất 1 tuần đầu của Sprint.
Daily Scrum:
Là cuộc họp có timeboxed thường kéo dài khoảng 15 phút, diễn ra mỗi ngày giúp nhóm hướng tới Sprint goal. Scrum Master đảm bảo cuộc họp diễn ra hàng ngày và theo dõi các trở ngại được xác định được trong cuộc họp. Daily Scrum chủ yếu dành cho các thành viên của Development team để đồng bộ hóa công việc và báo cáo bất kỳ những vấn đề, vướng mắc mà họ đang gặp phải. Phạm vi của cuộc họp này được giới hạn nghiêm ngặt, mỗi thành viên trong nhóm trả lời ngắn gọn ba câu hỏi về những gì họ đang làm để đáp ứng Sprint goal:
▶ Tính từ thời điểm kết thúc cuộc họp Daily cuối cùng đến nay bạn đã làm gì?
▶ Bạn dự định sẽ làm gì hôm nay?
▶ Có những cản trở, khó khăn nào trong quá trình thực hiện của bạn không
Sprint Review:
Sprint Review meeting được tổ chức vào cuối Sprint với sự tham gia gồm Development team, Product Owner và Scrum Master (và các bên liên quan khác). Trong cuộc họp này, nhóm sẽ giới thiệu về những tính năng mà họ đã xây dựng trong Sprint cho Product Owner. Product Owner sẽ kiểm tra công việc để xem liệu là sản phẩm/phần mềm có thật sự hoạt động tốt và được chấp nhận hay không. Nhóm và Product Owner thảo luận về phần gia tăng tính năng này và các mục còn lại trong Product Backlog, sẽ cùng nhau thực hiện những thay đổi cần thiết cho Backlog.
Sprint Retrospective:
Được diễn ra sau Sprint Review nhưng trước Sprint Planning meeting tiếp theo. Nội dung cuộc họp có thể bàn về bất kỳ điều gì đã xảy ra trong Sprint vừa qua, bao gồm các vấn đề về con người, quy trình và sản phẩm. Các thành viên trong nhóm khám phá những bài học kinh nghiệm tốt, những điều làm chưa tốt, tìm kiếm cơ hội để cải thiện và quyết định những thay đổi nào sẽ được thực hiện trong Sprint tiếp theo.
Scrum Artifacts
Trong quá trình phát triển phần mềm/sản phẩm, nhóm cần biết về tính năng sản phẩm/phần mềm mà họ đang làm việc, những gì họ sẽ xây dựng trong Sprint hiện tại và cách họ sẽ xây dựng nó. Scrum team sẽ sử dụng ba công cụ để quản lý tất cả các thông tin này bao gồm: Product Increment, Product Backlog và Sprint Backlog.
1. Product Increment
Phần tính năng gia tăng cho sản phẩm/phần mềm
Trong mỗi Sprint, các thành viên của Development team sẽ xây dựng giải pháp cho phần tính năng gia tăng của sản phẩm – Product Increment. Như đã trình bày ở trên, trong buổi Sprint Review, nhóm sẽ giới thiệu, demo về Product Increment mới nhất để nhận phản hồi từ Product Owner và xem liệu là sản phần gia tăng này có thật sự hoạt động tốt và được chấp nhận hay không. Để tối đa hóa cơ hội Product Increment được chấp thuận, nhóm và Product Owner cần phải thống nhất với nhau về các hạng mục được thực hiện, hoặc như thế nào là một Increment hoàn thiện (DOD – Definition of Done) trước khi nhóm bắt đầu làm việc.
2. Product Backlog
Là danh sách các công việc/yêu cầu của dự án được ưu tiên thực hiện để xây dựng sản phẩm/phần mềm.
Các mục trong Product Backlog (gọi là backlog items) có thể bao gồm các tính năng, chức năng, yêu cầu, cải tiến và sửa lỗi của sản phẩm/phần mềm. Danh sách này linh hoạt, sẽ phát triển khi sản phẩm phát triển và cần được cập nhật liên tục.
Các mục trong Product Backlog được Product Owner ưu tiên và sắp xếp sao cho công việc có mức độ ưu tiên từ cao xuống thấp. Nhóm sẽ thực hiện công việc dựa trên thứ tự ưu tiên đó. Các mục công việc này sẽ được cải tiến dần dần khi nhóm thực hiện, vì vậy các mục được ưu tiên cao nhất là chi tiết nhất và nhóm sẽ ước lượng (thời gian, chi phí, nguồn lực) cho các mục đó chính xác hơn. Còn các mục có mức độ ưu tiên thấp nhất có thể hoàn toàn không được thực hiện.
Backlog sẽ luôn được tinh chỉnh xuyên suốt quá trình làm dự án. Và quá trình cập nhật chi tiết cho từng mục con bên trong Backlog, cũng như con số ước lượng (về thời gian, chi phí, nguồn lực,…) được gọi là “Backlog Refinement”. Hoạt động này được Development Team và Product Owner thực hiện cùng nhau.
3. Sprint Backlog
Là tập hợp các mục con trong Product Backlog đã được chọn để làm mục tiêu của một Sprint cụ thể.
Cùng với Sprint Backlog, nhóm sẽ phát triển một bản kế hoạch về cách mà nhóm sẽ đạt được Sprint goal, đây là cam kết của nhóm đối với chức năng, tính năng mà họ sẽ cung cấp trong Sprint. Sprint Backlog thể hiện cái nhìn rõ ràng về công việc đang được thực hiện và có thể chỉ được cập nhật bởi Development Team.
Khi nhóm làm việc thông qua Sprint Backlog trong suốt Sprint, các thành viên sẽ được phân bổ để thực hiện các công việc trong Sprint Backlog, những thông tin này sẽ được chia sẻ với toàn team khi Daily Scrum.
Bộ năm giá trị cốt lõi của Scrum giúp cho nhóm hoạt động một cách hiệu quả nhất bao gồm: Openness, Respect, Courage, Focus và Commitment.
1. Openness – Cởi mở
Không ai trong chúng ta muốn phạm sai lầm, đặc biệt là trong công việc. Trong quá trình làm việc nếu bạn gặp một vấn đề, một trở ngại hay một rào cản nào đó, bạn có thể chia sẻ với nhóm của mình, để mọi người cùng trao đổi, chia sẻ và góp ý cho bạn, từ đó giúp công việc của bạn hoàn thành một cách hiệu quả nhất. Đó là lý do tại sao mọi người trong nhóm cần chia sẻ giá trị này.
2. Respect – Sự tôn trọng
Tin tưởng và tôn trọng luôn đi đôi với nhau. Mọi người trong nhóm khi làm việc cần lắng nghe ý kiến của nhau và đưa ra những ý kiến đóng góp để hiểu ý tưởng của nhau hơn. Nếu đồng đội không đồng tình với ý kiến của bạn, họ sẽ nêu ý kiến, phân tích về những gì bạn đang thực hiện, nhưng họ vẫn sẽ tôn trọng quyết định của bạn.
3. Courage – Can đảm
Các Scrum teams cần can đảm để thực hiện các thử thách. Nhưng từng cá nhân trong nhóm cũng cần có đủ can đảm để đưa ra ý kiến của mình. Ví dụ: Bạn sẽ làm gì khi sếp yêu cầu nhóm của bạn phải hoàn thành một mục tiêu bất khả thi? Điều gì sẽ xảy ra nếu sếp yêu cầu nhóm phải đáp ứng thời hạn hai tuần cho một dự án nhưng thực tế phải mất ít nhất hai tháng để thực hiện? Lúc này Scrum teams cần đủ can đảm để đứng lên trình bày cho sếp của mình về tính bất khả thi đó.
4. Focus – Sự tập trung
Mọi thành viên trong nhóm đều phải tập trung vào mục tiêu Sprint và mọi thứ họ làm trong Sprint sẽ giúp họ tiến tới mục tiêu đó. Trong Scrum Sprint, mỗi người trong Scrum team chỉ tập trung vào các mục trong Sprint Backlog và các nhiệm vụ mà họ đã được phân công trong cuộc họp Sprint Planning. Mỗi người làm việc trên một mục trong Sprint Backlog tại một thời điểm, chỉ tập trung vào một nhiệm vụ trong kế hoạch và chỉ chuyển sang nhiệm vụ tiếp theo khi hoàn thành nhiệm vụ hiện tại.
5. Commitment – Cam kết
Mọi người trong nhóm đều phải cam kết cung cấp sản phẩm / phần mềm có giá trị nhất mà họ có thể. Khi nhóm cam kết với dự án, điều đó có nghĩa là các nhiệm vụ mà họ đã lên kế hoạch để đáp ứng mục tiêu Sprint là nhiệm vụ quan trọng nhất mà họ phải thực hiện. Mỗi thành viên trong nhóm cần phải nhìn nhận rằng thành công của từng cá nhân gắn liền với thành công của dự án. Không chỉ vậy, mỗi người trong nhóm còn phải cam kết với từng mục mà team phải thực hiện. Điều này được gọi là cam kết tập thể.
Và để Scrum có hiệu quả, công ty cũng cần phải hoàn toàn cam kết với dự án, tôn trọng cam kết tập thể của nhóm đối với mục tiêu Sprint và tuân theo các quy tắc của Scrum.
Vậy làm thế nào để một công ty thể hiện việc cam kết đó?
Bằng cách trao cho nhóm quyền để xác định những tính năng nào sẽ được phát triển trong mỗi Sprint và tin tưởng rằng, nhóm sẽ cung cấp sản phẩm / phần mềm có giá trị nhất có thể. Công ty thực hiện điều đó bằng cách giao cho Product Owner thẩm quyền làm việc toàn thời gian với đội, nhóm của mình.
Định nghĩa của “Done” – Definition of Done – DOD
Ở các phần trên chúng ta đã đề cập đến khái niệm “Definition of Done” (định nghĩa hoàn thành), vậy “Done” được định nghĩa như thế nào? Các thành viên làm việc với Backlog item hoặc một nhiệm vụ đã được phân công tại một thời điểm cho đến khi “Done”. Nhưng chính xác khi nào nó được gọi là “Done”?
▶ Có thành viên nói code xong một tính năng sản phẩm / phần mềm nào đó là “Done”.
▶ Có thành viên khác lại cho rằng kiểm thử xong mới được xem là “Done”.
▶ Nhưng có thành viên chỉ cho là “Done” khi khách hàng “gật đầu”.
Đó là lý do tại sao Scrum team có “Definition of Done” cho mọi mục hoặc tính năng mà họ thêm vào Backlog. Trước khi một mục có thể đi vào Sprint Backlog, mọi người trong nhóm cần phải hiểu và thống nhất về “Definition of Done” để không chỉ thực hiện mà còn để “Done” đúng nghĩa.
Các nhóm dự án phải đưa ra quyết định mỗi ngày:
✔ Chúng ta sẽ xây dựng các tính năng nào trong Sprint này?
✔ Chúng ta sẽ xây dựng các tính năng theo thứ tự nào?
✔ Người dùng sẽ tương tác với tính năng này như thế nào?
✔ Phương pháp kỹ thuật nào chúng ta sẽ thực hiện?
Các nhóm theo Mô hình Waterfall (thác nước) có một câu trả lời: “Tất cả các kế hoạch đã được xây dựng từ khi bắt đầu dự án, cứ theo đó mà làm”. Vấn đề là tại thời điểm kế hoạch đang được xây dựng, hầu hết những câu hỏi đó đều không có câu trả lời.
Scrum teams cũng cho rằng mọi câu hỏi của dự án không thể được trả lời khi bắt đầu dự án, hoặc thậm chí khi bắt đầu một Sprint. Thay vào đó, Scrum teams sẽ thực hiện kế hoạch và điều chỉnh dựa vào báo cáo của các thành viên trong các cuộc họp.
Scrum teams làm điều này bằng cách sử dụng bộ “kiềng ba chân” của Scrum” (3 Pillars): sự minh bạch (transparency), kiểm tra (inspection) và thích ứng (adaptation).
Transparency:
Có nghĩa là mọi người trong nhóm hiểu những gì đồng đội của họ đang làm. Điều này liên quan đến việc từng cá nhân phải chia sẻ thông tin (về tiến độ, cách thức thực hiện,…) những công việc của mình đang thực hiện cho những người liên quan.
Inspection:
Có nghĩa là thường xuyên kiểm tra về những gì team đang xây dựng và cách team xây dựng thông qua việc trao đổi trong Daily Scrum và tại các cuộc họp Scrum khác, xem dự án đang tiến triển như thế nào so với các mục tiêu đã đề ra, tìm kiếm các sai lệch hoặc sự khác biệt có có khả năng gây ảnh hưởng tới mục tiêu của Sprint.
Adaptation:
Có nghĩa là nhóm liên tục điều chỉnh quy trình của nhóm để giảm thiểu tối đa các vấn đề không mong muốn sẽ xảy ra dựa trên những gì họ đúc kết được sau các cuộc họp Daily Scrum và tại các cuộc họp Scrum khác (như thêm hoặc xóa backlog items khỏi Sprint Backlog khi xảy ra vấn đề).
Tóm lại, các quy tắc của Scrum rất đơn giản, nhưng để áp dụng hiệu quả trong quá trình làm việc thì lại rất khó. Để Scrum đạt được hiệu quả nhất, team cần phải thực sự hiểu các giá trị của Scrum nói riêng và các giá trị, nguyên tắc trong Agile Manifesto nói chung.
Masterskills (PMP, PMI-ATP Instructor)
References: PMI-ACP Exam Prep, Head First Agile
Product Backlog là gì? Có quan hệ như thế nào với WBS
Bản tuyên ngôn Agile – lịch sử hình thành Agile
12 nguyên tắc của Agile
Trong dự án Agile, công việc ước tính có thật sự cần thiết?
Quản lý dự án với Scrum
Scrum of Scrums
User stories – Công cụ lên kế hoạch của Agile
Story points – Công cụ ước lượng của Agile
Velocity là gì – Công cụ đo lường tốc độ hoàn thành công việc của nhóm Agile
Story Map – Lập kế hoạch tổng quát trong Agile
Agile Retrospectives – Nhìn lại và cải tiến hiệu quả công việc dự án
Kanban – phương pháp giúp cải tiến quy trình làm việc của dự án
PDCA – Chu trình cải tiến liên tục
Personas – Công cụ xây dựng hình tượng khách hàng trong Agile
Lean – Tinh gọn hóa quy trình một cách hiệu quả
Hướng Dẫn Scrum – The Scrum Guide
Bóng đá có 3-5-2, Scrum có 3-5-3
Bắt đầu với Scrum từ đâu đây ta?
Một số cách chạy Daily scrum hiệu quả
