Chuyện giờ mới kể - Sổ tay xoá mù Agile và Scurm

Phần mềm không tự nó sinh ra cũng không tự nó nâng cấp, mà phải được phát triển và bảo trì bởi các lập trình viên. Nhiều quy trình được thành lập để giúp việc phát triển phần mềm trở nên dễ dàng và bài bản hơn.

Lưu ý: Bản thân Agile và Scrum là những chủ đề rất rộng, cần đến vài quyển sách và khóa học để nói về chúng. Trong phạm vi bài viết, mình chỉ đưa ra những điểm chính yếu để bạn đọc có nền tảng kiến thức và có thể tự tìm hiểu sâu hơn.

Quy trình phát triển phần mềm

Để hiểu hơn về Agile, trước hết ta hãy xem lại quy trình thường dùng để phát triển phần mềm. Qui trình này thường bao gồm 5 quá trình:

Lấy yêu cầu (requirement): Xác định yêu cầu và ưu tiên từ khách hàng.
Thiết kế hệ thống: Xác định công việc cần làm trong mỗi Sprint (chu kỳ phát triển ngắn), .
Phát triển: Developer phát triển hệ thống
Kiểm thử và Đánh giá: Tester kiểm thử hệ thống và để khách hàng xác nhận.
Bảo trì, sửa chữa hoặc thêm chức năng cho hệ thống.

Với mô hình phát triển truyền thống (còn gọi là waterfall), các quá trình này được thực hiện tuần tự từ đầu đến cuối. Tuy nhiên, rất khó để lấy chính xác yêu cầu (requirement) của khách hàng ở giai đoạn đầu, vì họ thường không biết mình cần gì cho đến khi nhìn thấy sản phẩm (phần mềm).

Khi requirement thay đổi, ta phải làm lại các bước thiết kế và phát triển, kiểm thử, viết lại tài liệu… Kết quả là sản phẩm làm ra không đúng yêu cầu của khách hàng, hoặc bị trễ thời gian, quá ngân sách.

Sự ra đời của Agile

Agile nhấn mạnh:

Cá nhân và tương tác quan trọng hơn quy trình và công cụ
Phần mềm chạy tốt quan trọng hơn tài liệu đầy đủ
Cộng tác với khách hàng quan trọng hơn đàm phán hợp đồng
Phản hồi với thay đổi quan trọng hơn bám sát kế hoạch

Mặc dù các yếu tố bên phải vẫn có giá trị, nhưng chúng tôi đánh giá cao hơn các mục ở bên trái.

Những điểm hay của Agile

Agile mang đến nhiều góc nhìn mới mẻ trong việc phát triển phần mềm:

Xây dựng phần mềm theo kiểu “cuốn chiếu”: Phát triển phần mềm theo các iteration ngắn (2-4 tuần). Mỗi iteration bao gồm các bước như lấy yêu cầu, thiết kế, code, và test, giúp khách hàng dễ dàng đưa ra phản hồi sớm.
Sự tham gia của khách hàng: Khách hàng tham gia trực tiếp vào quá trình phát triển phần mềm qua các iteration, không chỉ đưa ra yêu cầu ban đầu rồi chờ đợi kết quả cuối cùng như trong waterfall.
Tập trung vào sản phẩm, không phải tài liệu: Agile giảm thiểu việc tạo tài liệu dư thừa. Thay vào đó, tập trung vào việc xây dựng phần mềm thực sự, giúp quá trình phát triển nhanh chóng và linh hoạt hơn.
Giao tiếp và hợp tác giữa các thành viên: Thay vì sử dụng tài liệu, Agile ưu tiên trao đổi trực tiếp, giúp thông tin được truyền đạt hiệu quả và nhanh chóng giữa các thành viên trong nhóm.
Giảm chi phí thay đổi: Agile giúp giảm chi phí thay đổi nhờ vào quy trình phát triển ngắn hạn. Khách hàng có thể dễ dàng đưa ra yêu cầu mới sau mỗi iteration mà không gặp phải khó khăn như trong waterfall.

Agile không phải là một quy trình hoàn thiện mà chỉ là một tập hợp các nguyên lý chung chung mà chúng ta nên tuân theo để phát triển phần mềm một cách uyển chuyển tinh gọn.

Dựa theo những nguyên lý của Agile, người ta đề ra những bộ khung (framework) hoặc quy trình phát triển phần mềm như: Lean, Kanban, XP, Crystal, Scrum.

Học thuyết Scrum - Scrum theory

Scrum hình thành dựa trên chủ nghĩa thực nghiệm và tư duy tinh gọn. Chủ nghĩa thực nghiệm khẳng định kiến thức đến từ thực nghiệm và việc ra quyết định dựa trên những gì quan sát được. Tư duy tinh gọn là loại bỏ những phần thừa thãi và tập trung vào những gì cần thiết.

Bản chất của Scrum là một khung làm việc (framework) dùng để phát triển sản phẩm hoặc giải quyết những vấn đề phức tạp.

Sprint: Scrum gói tất cả các bước cần thiết để phát triển một sản phẩm như lấy yêu cầu (requirements), phân tích (analyses), thiết kế (design), phát triển (development) và thử nghiệm (testing) vào một khoảng thời gian lặp, cố định được gọi là Sprint.

Ngay từ Sprint đầu tiên, chúng ta sẽ cần cố gắng tạo ra một flow chức năng hoàn chỉnh có thể hoạt động được,

ví dụ:

Nên: Đăng ký và đăng nhập nên làm cùng trong 1 Sprint.
Không nên: Đăng ký xong rồi tạo post là cùng với nhau.

Đăng ký xong không đăng nhập được thì chức năng post bài, khách hàng không test được hoặc không đúng thực tế nếu đăng bài mà ko cần đăng nhập.

Sau mỗi Sprint, team sẽ demo ngay chức năng đó cho khách hàng để lấy phản hồi. Và sau đó cùng nhau bàn về những gì nên làm tiếp theo. Khách hàng thường chỉ có thể biết được những gì họ thực sự muốn sau khi được xem demo sản phẩm. Các Sprint cho phép phản hồi và cải tiến liên tục. Từ đó, tạo ra được sản phẩm phù hợp với yêu cầu thực tế.

Khái niệm quan trọng Scrum

User Story: Đây là một cách diễn đạt yêu cầu của khách hàng dưới dạng một câu ngắn gọn và đơn giản. Mỗi user story thường miêu tả một tính năng của sản phẩm từ góc nhìn của người sử dụng. Ví dụ:

Là khách hàng mua sách, tôi có thể xem toàn bộ sách có trong cửa hàng.
Là quản lý, tôi có thể thay đổi số lượng sách trong kho.

Story Point: Đây là một đơn vị đo lường được dùng để đánh giá mức độ công sức và thời gian cần thiết để hoàn thành một user story. Các story point càng lớn thì công việc sẽ càng phức tạp và cần nhiều thời gian thực hiện.

Product Backlog: Là danh sách toàn bộ các công việc hoặc tính năng cần thực hiện để hoàn thành sản phẩm. Product Backlog có thể bao gồm cả các yêu cầu chức năng (user stories) và các công việc kỹ thuật (như tích hợp API, xây dựng database).

Sprint (Iteration): Là một chu kỳ làm việc ngắn từ 2 đến 4 tuần, trong đó nhóm Scrum tập trung vào việc thực hiện các công việc đã được lựa chọn từ Product Backlog. Mỗi Sprint sẽ bao gồm các giai đoạn như thiết kế, phát triển, kiểm thử và cuối cùng là cung cấp một sản phẩm có thể demo được.

Sprint Backlog: Là danh sách các user stories và công việc cụ thể mà đội ngũ sẽ thực hiện trong một Sprint. Danh sách này được xây dựng trong cuộc họp Sprint Planning và sẽ được thực hiện trong suốt Sprint. Ví dụ, nếu mục tiêu của Sprint là làm một bản demo cho khách hàng, team sẽ chọn những user stories liên quan đến người dùng để thêm vào Sprint Backlog.

Definition of Done (Định nghĩa hoàn thành): Là tiêu chí mà đội ngũ Scrum sử dụng để xác định khi nào một công việc hoặc tính năng được coi là “hoàn thành”. Definition of Done có thể bao gồm việc user story đã được lập trình, kiểm thử và được khách hàng phê duyệt trong demo. Mỗi nhóm có thể có một Definition of Done khác nhau tùy vào yêu cầu và đặc thù công việc của họ.

Scrum Team

Một Scrum Team bao gồm 3 vai trò: Product Owner, Developer và Scrum Master.

Với Scrum thì không có sub-team, mục tiêu của team là Product Goal. Scrum team là đa chức năng, nghĩa là các thành viên trong team có đầy đủ kỹ năng cần thiết để tạo ra value ở mỗi Sprint. Họ cũng tự quản và tự quyết định nội bộ Ai làm, làm cái gì, làm khi nào và làm như thế nào.

Số lượng thành viên trong team chỉ từ 10 hoặc ít hơn. Nếu team lớn thì phải tái cấu trúc thành nhiều team nhỏ, các team này tập trung cùng 1 Product Backlog, 1 Product goal và 1 Product Owner.

Product Owner là người có trách nhiệm tối đa hóa giá trị sản phẩm từ kết quả công việc của Scrum team

Product Owner sẽ tạo một danh sách các tính năng (features) được gọi là Product Backlog. Và sau đó sắp xếp chúng theo mức độ quan trọng. Các features quan trọng hơn được ở trên cùng. Khi lập kế hoạch Sprint (Sprint Planning), team sẽ chọn một danh sách các features trong Product Backlog từ trên xuống. Và làm rõ các chức năng đảm bảo:

Team có thể thực hiện được các chức năng đó trong khoảng thời gian của một Sprint.
Mọi người trong team đều nắm rõ mục tiêu của Sprint (Sprint Goal). Hiểu các chức năng cần thực hiện và thực hiện như thế nào.

Team sẽ họp hàng ngày (Daily Scrum) để nắm được công việc đã hoàn thành, xác định các vấn đề và công việc tiếp theo sẽ làm trong 24h tiếp theo. Scrum Master là người đảm bảo team tập trung vào mục tiêu của Sprint.

Vào cuối Sprint, Scrum Team cùng với các bên liên quan (khách hàng,…) tiến hành demo, đánh giá chức năng đã hoàn thành trong buổi Sprint Review. Kết thúc một Sprint là họp tối ưu Sprint (Sprint Retrospective) để cùng đưa ra các vấn đề và các cải tiến của thể thực hiện trong Sprint tiếp theo.

Developers là những người cam kết tạo ra bất cứ khía cạnh của Increment có thể sử dụng trong Sprint.

Trong Scrum thì không có Project manager hay tester… ; những người này gợi chung là developers

Tạo kế hoạch cho sprint, the Sprint Backlog
Nâng cao chất lượng bằng cách tuân thủ định nghĩa hoàn thành
Điều chỉnh kế hoạch mỗi ngày để hướng đến Sprint Goal
Chịu trách nhiệm với nhau như những người chuyên nghiệp.

Scrum Master có trách nhiệm thiết lập Scrum theo đúng định nghĩa trong Scrum Guide, là 1 người lãnh đạo thực thụ phục vụ Scrum team và tổ chức lớn hơn.

Scrum Master phục vụ Scrum team:

Huấn luyện team member về tự quản và chức năng chéo;
Giúp Scrum team tập trung tạo ra giá trị tăng trưởng cao nhất theo đúng định nghĩa hoàn thành
Loại bỏ những trở ngại đến phát triển của Scrum team
Đảm bảo tất cả các sự kiện được diễn ra, tích cực, hiệu quả và đúng thời gian

Scrum Master phục vụ Product Owner:

Giúp PO tìm kiếm kỹ thuật để định nghĩa Product Goal và quản lý Product Backlog hiệu quả
Giúp Scrum team hiểu được sự cần thiết của việc Product Backlog items ngắn ngọn và rõ ràng
Giúp thiết lập sản phẩm thực nghiệm trong 1 môi trường phức tạp
Tạo sự hợp tác thuận lợi các bên tùy theo yêu cầu hoặc cần thiết

Scrum Master phục vụ Organization:

Lãnh đạo, hướng dẫn, đào tạo tổ chức trong việc áp dụng Scrum
Lên kế hoạch và tư vấn triển khai Scrum trong tổ chức
Giúp đỡ nhân viên cũng như các bên liên quan hiểu và đưa ra giải pháp tiếp cận thực nghiệm cho những công việc phức tạp
Loại bỏ rào cản giữa các bên liên quan và Scrum team

3 trụ cột của Scrum - Scrum pillars

Transparency: Quy trình và công việc phải được minh bạch với những người thực hiện công việc cũng như những người nhận nhận công việc.

Inspection: Các tạo tác Scrum (Product Backlog, Sprint Backlog và Increment.) và phát triển nhắm đến mục tiêu đã thống nhất phải được giám sát thường xuyên để phát hiện những vấn đề hoặc những sat sót không mong muốn.

Adaptation: Nếu bất kỳ khía cạnh nào của quy trình làm việc bị chệch hướng ra khỏi giới hạn cho phép hoặc nếu kết quả của sản phẩm không được chấp nhận thì quy trình đang được áp dụng hay vật liệu sản xuất phải được điều chỉnh.

Chuyện họp hành

Trong quy trình Scrum, có một số cuộc họp quan trọng mà thành viên phải tham gia:

Sprint Planning Meeting: Cuộc họp này được bắt đầu mỗi Sprint, kéo dài khoảng 4 tiếng. Cuộc họp giúp xác định mục tiêu cần đạt được trong Sprint và những công việc (user story) cần làm. Trong cuộc họp này, cả nhóm cũng ước đoán story point cho mỗi user story.

Daily Meeting/Standup: Xuyên suốt Sprint, mỗi ngày cả team sẽ bỏ ra khoảng 15 phút để tổ chức một cuộc họp ngắn. Việc họp này giúp các thành viên nắm được tình hình dự án. Trong cuộc họp, mỗi thành viên trả lời 3 câu hỏi:

Hôm qua tôi đã làm được gì?
Hôm nay tôi sẽ làm gì?
Tôi đang gặp trở ngại, vướng mắc gì?

Sprint Review Meeting: Cuộc họp này diễn ra sau khi kết thúc Sprint. Cả nhóm sẽ xem xét lại những việc đã hoàn thành, chưa hoàn thành, sau đó demo những phần đã hoàn thành cho Product Owner. Product Backlog sẽ được cập nhật lại.

Retrospective Meeting: Trong buổi họp này, cả nhóm cùng ngồi nhìn lại và đánh giá những điểm được và chưa được trong Sprint vừa qua, đồng thời đề xuất các biện pháp cải tiến.

Một Sprint làm việc của Team Scrum tại BookStore

Giả sử mình là một thành viên trong Development Team của BookStore.com, một nền tảng bán sách trực tuyến. Sprint của mình sẽ diễn ra như sau:

Ngày đầu tiên của Sprint: Sprint Planning Meeting

Vào đầu tháng 3, nhóm bắt đầu Sprint mới. Mình tham dự Sprint Planning Meeting, trong đó, Product Owner thông báo mục tiêu của Sprint là “Cải thiện trải nghiệm người dùng khi tìm kiếm và đánh giá sách trên hệ thống.” Các user story được chọn cho Sprint Backlog là:

Là một người dùng, tôi muốn có thể tìm sách theo thể loại (5 points).
Là một người dùng, tôi muốn xem đánh giá của người mua trước khi quyết định mua sách (3 points).
Là một người dùng, tôi muốn có thể thêm đánh giá cho sách sau khi mua (8 points).
Là một người dùng, tôi muốn xem những sách được đánh giá cao nhất (5 points).

Sau khi cuộc họp kết thúc, mình và các thành viên trong nhóm xác định các công việc cụ thể cần làm, phân chia nhiệm vụ và bắt đầu làm việc.

Cuộc họp hàng ngày: Daily Meeting/Standup

Mỗi sáng, từ 10h đến 10h15, mình tham gia Daily Meeting. Mỗi thành viên sẽ cập nhật công việc của mình bằng cách trả lời 3 câu hỏi:

Hôm qua tôi đã làm gì? Ví dụ: “Hôm qua tôi đã hoàn thành giao diện cho chức năng tìm kiếm sách theo thể loại.”
Hôm nay tôi sẽ làm gì? Ví dụ: “Hôm nay tôi sẽ tích hợp chức năng tìm kiếm với database và kiểm tra xem các bộ lọc có hoạt động đúng không.”
Tôi gặp khó khăn gì? Ví dụ: “Tôi gặp vấn đề với việc kết nối API với cơ sở dữ liệu sách, có thể cần thêm thời gian để khắc phục.”

Ngày cuối của Sprint: Sprint Review Meeting

Sau khi Sprint kết thúc, mình tham dự Sprint Review Meeting, nơi nhóm trình bày những tính năng đã hoàn thành. Mình cùng nhóm demo tính năng tìm kiếm sách theo thể loại và chức năng hiển thị đánh giá sách.

Sau khi xem demo, Product Owner đưa ra phản hồi và yêu cầu thêm một số tính năng mới, ví dụ: “Cần thêm tính năng lọc sách theo mức giá.”

Buổi họp cuối cùng của Sprint: Retrospective Meeting

Sau khi Sprint Review kết thúc, chúng mình tham gia Retrospective Meeting. Cả nhóm cùng đánh giá những điểm mạnh và yếu trong quá trình làm việc:

Điểm mạnh: “Chúng ta đã hoàn thành các tính năng đúng hạn và đáp ứng yêu cầu của khách hàng.”
Điểm cần cải tiến: “Vẫn còn một số điểm chưa thống nhất trong quy trình code và thiết kế, ví dụ, mọi người có thói quen sử dụng những cách làm khác nhau.”
Cải tiến: Cả nhóm thống nhất sẽ tạo ra một coding convention chung để áp dụng cho các Sprint tiếp theo, nhằm đảm bảo sự nhất quán trong mã nguồn và quy trình thiết kế.

Lưu ý: Hầu hết các công ty không tuân theo qui trình Scrum “chuẩn” hoàn toàn mà sẽ biến đổi nó để phù hợp với văn hóa và qui trình của công ty. Thứ quan trọng nhất là hiệu quả công việc, sản phẩm làm ra chứ không phải là “theo đúng qui trình”.