Tìm hiểu về Agile và Scrum

Bài đăng này đã không được cập nhật trong 5 năm

Trước tiên chúng ta hãy tìm hiểu về quy trình phát triển phần mềm Thác nước quen thuộc. Quy trình này bao gồm 5 bước:

Xác định yêu cầu của khách hàng
Thiết kế hệ thống
Developer phát triển hệ thống
Tester kiểm thử hệ thống
Sửa lỗi, bảo trì hệ thống

Quy trình này được thực hiện tuần tự tuy nhiên quy trình này không chỉ được thực hiện 1 lần nếu như requirement thay đổi. Khách hàng sẽ luôn muốn có những thay đổi khi nhìn thấy sản phẩm của mình.

Lịch sử ra đời của Alige

Agile được sinh ra khi 17 nhà phát triển cùng nhau nghĩ đến một giải pháp thay thế khả thi cho phát triển phần mềm có thể dẫn đến thời gian phát triển nhanh hơn và ít tốn chi phí hơn.

Vào thời điểm đó, việc phát triển phần mềm đã từng xảy ra quá chậm chễ đến mức khi các dự án được giao cho doanh nghiệp thì doanh nghiệp đã thay đổi yêu cầu của họ. Do đó, một dự án không thể đáp ứng nhu cầu kinh doanh ngay cả khi nó có thể đáp ứng các mục tiêu đã xác định.

Sau khi các nhà phát triển thảo luận thì bản tuyên ngôn Agile ra đời. Tuyên ngôn đó là:

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

Ưu điểm của Alige

Sau khi Agile ra đời, nó đã giúp tỉ lệ thành công của các dự án cao hơn. Không thể phủ nhận những điểm mới mẻ mà Agile đã mang lại cho những người làm phần mềm:

Khách hàng tham gia vào mỗi giai đoạn của quá trình phát triển phần mềm do đó khách hàng sẽ có được một cái nhìn và cảm nhận về tiến độ dự án. Khách hàng sẽ thấy sản phẩm thường xuyên do đó sẽ có thể đưa ra những góp ý hoặc thay đổi mới.
Dự án đáp ứng nhanh chóng với những thay đổi liên tục
Tập trung hơn vào chất lượng của sản phẩm thay vì quá tập trung vào tài liệu
Tăng khả năng tương tác giữa các khách hàng và nhà phát triển, giữa các thành viên trong dự án
Giảm chi phí cho giai đoạn sửa lỗi, bảo trì sản phẩm

Nhược điểm của Alige

Mặc dù có một số ưu điểm của phương pháp Agile, nhưng cũng có những nhược điểm:

Việc hiểu sai tài liệu, mất tài liệu do Agile không yêu cầu tài liệu. Những yêu cầu được gửi đến cho đội sản xuất khi chưa đầy đủ các thông tin cần thiết.
Những thay đổi requirement là quá nhiều và dồn dập sẽ gây ra những đánh giá và kế hoạch không đúng đắn.

Các phương pháp Agile

Có một vài phương pháp Agile trên toàn thế giới, dựa vào những nguyên lý Agile, người ta đã đề ra những bộ khung (framework) hoặc qui trình phát triển phần mềm như: Lean, Kanban, XP, FDD, Scrum...

Tìm hiểu về Scrum

Scrum là Agile framework phổ biến nhất trên thế giới. Scrum là từ xuất phát từ bóng bầu dục thể thao. Nơi các cầu thủ rúc vào nhau trong tư thế đan xen nhau chống lại các đối thủ. Mỗi người chơi có một vai trò được xác định trong vị trí của họ và có thể chơi cả tấn công và phòng thủ theo yêu cầu của tình huống.

Tương tự, scrum trong CNTT tin vào các nhóm phát triển tự quản lý được trao quyền với 3 vai trò cụ thể và được xác định rõ ràng. Những vai trò này bao gồm Product Owner (PO), Scrum Master (SM) and Development team. Họ làm việc cùng nhau trong một thời gian nhất định được gọi là Sprint.

Bước đầu tiên là đưa ra các công việc còn tồn động bởi PO. Nó có một danh sách những việc cần làm được thực hiện. Sau đó, nhóm scrum chọn các mục ưu tiên hàng đầu và cố gắng hoàn thành chúng trong Sprint.

Một cách dễ dàng hơn để ghi nhớ tất cả những điều này là ghi nhớ khung 3-3-5. Điều đó có nghĩa là một dự án Scrum có 3 Roles, 3 Artifacts và 5 Events.

Giờ chúng ta cùng tìm hiểu ý nghĩa của 3-3-5 là gì.

Một số vị trí (role) trong Scrum

Product Owner (PO)

PO là các bên liên quan chính hoặc người dùng chính của ứng dụng sẽ được phát triển. PO là người đại diện cho phía khách hàng và là người có thẩm quyền cuối cùng. Anh ấy / cô ấy nên có thể truy cập khi bất cứ ai có bất kỳ nghi ngờ cần làm rõ. Điều quan trọng là PO phải hiểu và không chỉ định bất kỳ yêu cầu mới nào ở giữa giai đoạn nước rút hoặc khi nước rút đã bắt đầu.
Scrum Master (SM)

Scrum Master là người hỗ trợ của nhóm scrum. Anh ấy / cô ấy đảm bảo rằng nhóm Scrum có năng suất và tiến bộ. Trong trường hợp có bất kỳ trở ngại, SM theo dõi và giải quyết chúng cho nhóm. SM là người trung gian giữa PO và nhóm. Anh ấy / cô ấy giữ cho PO thông báo về tiến trình của Sprint. Nếu có bất kỳ rào cản hoặc mối quan tâm nào cho nhóm, hãy thảo luận với PO và giải quyết chúng.
Development Team

Các thành viên này là một hỗn hợp của năng lực và bao gồm các developers, testers, database people, support people ... cùng với PO và SM. Tất cả các thành viên này làm việc cùng nhau trong sự hợp tác chặt chẽ trong một khoảng thời gian đệ quy và xác định, để phát triển và thực hiện các tính năng đã nói. Sắp xếp chỗ ngồi của đội Scrum đóng một vai trò rất quan trọng trong sự tương tác của họ.

Artifacts

Product Backlog

Là danh sách công việc mà team cần phải làm để hoàn thành sản phẩm
Sprint Backlog

Ở đầu mỗi Sprint, cả team sẽ có một cuộc họp để lựa chọn những user story (Kịch bản người dùng) quan trọng được lấy từ Product Backlog, sau đó xác định tính khả thi và quyết định hoàn thành trong Sprint này. Những user story này sẽ được bỏ vào Sprint Backlog.

Các cuộc họp

Trong quy trình Scrum, thành viên thường phải tham gia các cuộc họp sau:

Sprint Planning Meeting:

Một cuộc họp lập kế hoạch là điểm khởi đầu của Sprint. Đó là cuộc họp mà toàn bộ nhóm Scrum tập hợp, SM chọn ra những công việc cần làm trong Sprint này.

Dựa trên cuộc thảo luận, nhóm Scrum quyết định mức độ phức tạp của user story . Nhóm xác định các nhiệm vụ cùng với những nỗ lực (tính bằng giờ) sẽ được thực hiện để hoàn thành việc thực hiện công việc.
Review Meeting

Cuộc họp này diễn ra sau khi kết thúc Sprint. Nhóm Scrum gặp lại và demo sản phẩm cho các PO. PO có thể xác minh các user story theo tiêu chí chấp nhận của nó.
Retrospective Meeting

Cuộc họp này diễn ra sau cuộc họp Review. Nhóm Scrum gặp gỡ, thảo luận và ghi lại các điểm sau:
- Điều gì diễn ra tốt đẹp trong Sprint (Thực tiễn tốt nhất)?
- Điều gì đã không diễn ra tốt đẹp trong Sprint?
- Bài học kinh nghiệm Nhóm Scrum nên tiếp tục theo dõi thực tiễn tốt nhất, bỏ qua các hoạt động không phải là thực tiễn tốt nhất và thực hiện các bài học kinh nghiệm trong các lần Sprint.
Daily Meeting

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ì?

Ví dụ về một quá trình Scrum được thực hiện như thế nào?

Đã đọc về các thuật ngữ kỹ thuật của Scrum, hãy để tôi thử chứng minh toàn bộ quá trình bằng một ví dụ.

Bước # 1: Leto có một nhóm Scrum gồm 9 người bao gồm 1 product owner, 1 Scrum master, 2 testers, 4 developers and 1 DBA.

Bước # 2: Sprint được quyết định theo chu kỳ 4 tuần. Vì vậy, chúng tôi có Sprint 1 tháng bắt đầu từ ngày 5 tháng 6 đến ngày 4 tháng 7.

Bước # 3: PO có danh sách ưu tiên các user story trong product backlog.

Bước # 4: Nhóm quyết định gặp nhau vào ngày 4 tháng 6 cho cuộc họp “Pre Planning” meeting..

PO đưa ra một user story và yêu cầu đội SCRUM hoàn thành nó. Toàn bộ nhóm thảo luận, tìm hiểu kĩ yêu cầu và lên kế hoạch hoàn thành công việc này.

Tổng số giờ làm việc = 9 Trừ 1 giờ để nghỉ ngơi, trừ 1 giờ cho các cuộc họp, trừ 1 giờ cho email, thảo luận, khắc phục sự cố, v.v. Vậy giờ làm việc thực tế = 6. Tổng số ngày làm việc trong Sprint = 21 ngày. Tổng số giờ khả dụng = 21 * 6 = 126. Thành viên được nghỉ 2 ngày = 12 giờ (Điều này thay đổi cho mỗi thành viên, một số có thể nghỉ và một số thì không.) Số giờ thực tế = 126 - 12 = 114 giờ.

Điều này có nghĩa là thành viên sẽ thực sự có sẵn trong 114 giờ cho lần Sprint.

Bước # 5: Vào ngày 5 tháng 6, toàn bộ nhóm Scrum sẽ họp cho Cuộc họp Lập kế hoạch.

Bước # 6: Khi Sprint đã bắt đầu, dựa trên các nhiệm vụ được giao, mỗi thành viên trong nhóm bắt đầu làm việc với các nhiệm vụ đó.

Bước # 7: Nhóm họp hàng ngày trong 15 phút và thảo luận về 3 điều: