Agile Scrum Methodology

1. Giới thiệu về Agile.

Agile là mô hình phát triển phần mềm linh hoạt được sử dụng và công nhận rộng rãi nhất trên thế giới.

1.1 Lịch sử của Agile

Agile ra đời năm 2001, khi mà 17 kỹ sư phần mềm cùng tụ họp tại resort Snowbird, bang Utah miền Tây nước Mỹ để cùng nhau suy nghĩ xem có một giải pháp thay thế 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ài liệu hơn không.

Họ đã đi đến thống nhất về quan điểm chung giữa các phương pháp và cho ra đời một tài liệu được gọi là: Tuyên ngôn phát triển phẩn mềm hoạt kèm với 12 nguyên lý Đây chính là thời điểm mà thuật ngữ Agile được sử dụng hiện nay ra đời, mặc dù các phương pháp riêng lẻ thì đã có trước đó.

1.2 Agile Promises là gì?

Agile không chỉ áp dụng trong việc thiết lập phát triển một phần mềm. Nó cũng mang đến một sự thay đổi trong tư duy của team, thúc đẩy họ hướng tới xây dựng một phần mềm tốt hơn, làm việc cùng nhau và cuối cùng là làm hài lòng khách hàng

Các giá trị và nguyên tắc agile cho phép nhóm chuyển sự tập trung của họ và thay đổi quá trình suy nghĩ của họ trong việc xây dựng một phần mềm tốt hơn.

=> Vậy chính xác Agile là gì ?

• Lặp, tăng trưởng: Phần lớn các phương pháp Agile đều phân chia công việc thành các chu trình nhỏ và không lập một kế hoạch dài hạn. Mỗi chu trình đều thực hiện đầy đủ các công đoạn, từ lập kế hoạch cho đến phân tích và thiết kế, viết code, kiểm thử, tích hợp để chuyển giao một phần tăng trưởng của sản phẩm.

• Giao tiếp thường xuyên và hiệu quả: Mỗi nhóm đều cần đến một người đại diện khách hàng làm việc cùng (chẳng hạn, trong Scrum thì là Product Owner). Người này đại diện cho quyền lợi của những người liên quan và có trách nhiệm làm rõ tất cả các yêu cầu cho các nhà phát triển.

• Vòng phản hồi ngắn và thích ứng thường xuyên: Các nhà phát triển thường xuyên trao đổi với nhau để cập nhật và đồng bộ công việc, phát hiện sớm các trở ngại và thích ứng với tình huống mới.

• Hướng chất lượng: Nhiều kỹ thuật và công cụ được sử dụng để hướng đến việc nâng cao chất lượng sản phẩm, chẳng hạn như: Tích hợp Liên tục, Kiểm thử Đơn vị Tự động, Lập trình cặp, Phát triển Hướng Kiểm thử, Mẫu Thiết kế, Tái cấu trúc mã nguồn, v.v..

1.3 Làm thế nào để thực hành Agile?

Có nhiều phương pháp agile.Tuy nhiên, các phương pháp phổ biến nhất trong số tất cả chúng là:

• Scrum
• Kanban
• Lập trình cực đoan

2. Phương pháp và mô hình Agile

2.1 Ưu điểm của phương pháp Agile

Đưa ra dưới đây là những ưu điểm khác nhau của phương pháp Agile:

• Khách hàng liên tục có được một cái nhìn và cảm nhận về tiến độ ở cuối mỗi chu kỳ của dự án

• Mỗi print sẽ cấp cho khách hàng một phần mềm hoạt động đáp ứng mong đợi của khách hàng

• Thường xuyên thích nghi với các thay đổi

• Có giao tiếp hai chiều liên tục với khách hàng, do đó tất cả các bên liên quan đều có tầm nhìn rõ ràng về tiến độ của dự án.

• Thiết kế của sản phẩm hiệu quả và đáp ứng các yêu cầu kinh doanh.

2.2 Nhược điểm của phương pháp Agile

Mặc dù có nhiều ưu điểm tuy nhiên agile cũng có một số nhược điểm:

• Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết. Điều này nên tránh bằng cách liên tục tự hỏi liệu đây có phải là thông tin đầy đủ để tiếp tục hay không.

• Đôi khi bắt đầu dự án, các yêu cầu không rõ ràng. Các team thấy rằng tầm nhìn của khách hàng đã được thay đổi lại và trong những tình huống như vậy, các team cần kết hợp nhiều thay đổi và rất khó để đánh giá kết quả cuối cùng.

• Chỉ những lập trình viên cao cấp mới có thể đưa ra các quyết định cần thiết trong quá trình phát triển

2.3 Các loại Agile

Có nhiều phương pháp agile, tuy nhiên trong bài viết này chúng ta sẽ đi tìm hiểu về sơ lược về 4 loại phổ biến sau:

2.3.1 Scrum

Scrum được coi là phương pháp Agile phổ biến nhất

Bước đầu tiên của Scrum là tạo một danh sách công việc phải làm được thực hiện bởi nhóm scrum. 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 1 khoảng thời gian gọi là print

Một số đặc điểm chính của SCRUM bao gồm:

• Nhóm tự tổ chức và tập trung
• Tập trung vào sản phẩm, sản phẩm mới là đích cuối cùng chứ không phải qui trình.
• Nhóm đa chức năng làm việc cùng nhau như một đơn vị duy nhất.
• Đóng giao tiếp với đại diện người dùng để hiểu các tính năng.
• Có thời hạn xác định tối đa một tháng.
• Khả năng tài nguyên và tính khả dụng được xem xét trước khi cam kết bất cứ điều gì.

Một dự án scrum có 3 vai trò, 3 công cụ và 5 sự kiện hay còn gọi là 3-3-5

• Vai trò: PO, Scrum master và team phát triển.

• Công cụ : Product Backlog, Sprint Backlog và tăng trưởng sản phẩm

• Sự kiện: Sprint, Sprint planning, Daily Scrum, Sprint review và Sprint retrospective.

Chúng hoạt động cùng nhau trong các khoảng thời gian lặp đi lặp lại được gọi là print

a, Vai trò

PO- Product Owner (chủ sản phẩm)

Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm.

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

Scrum master

Scrum Master là trợ lý của nhóm scrum. Scrum master đảm bảo rằng nhóm scrum có năng suất và hiệu quả. Trong trường hợp có bất kỳ trở ngại nào, scrum master theo dõi và giải quyết chúng. Scrum Master là người hòa giải giữa PO và team. Scrum master thông báo về tiến trình của Sprint cho PO . Nếu có bất kỳ rào cản hoặc mối quan tâm nào đối với team, hãy thảo luận với PO và giải quyết chúng. Giống như Standup hàng ngày của nhóm, một standup của SCRUM Master với PO xảy ra mỗi ngày.

Team phát triển

Một nhóm liên chức năng (cross-functional) tự quản lý để tiến hành chuyển đổi các yêu cầu được tổ chức trong Product Backlog thành chức năng của hệ thống.

b, Công cụ

Product Backlog

Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án.

Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa (thường là giá trị thương mại – business value).

- Print Backlog

Đây là bản kế hoạch cho một Sprint; là kết quả của buổi họp lập kế hoạch (Sprint Planning).

Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

- Tăng trưởng sản phẩm

Phần tăng trưởng Sản phẩm: Đôi khi còn được gọi ngắn gọi là Phần tăng trưởng. Là kết quả “hoàn thành” được Nhóm Phát triển chuyển giao sau mỗi Sprint. Để được coi là “hoàn thành” thì các hạng mục Product Backlog phải thỏa mãn với Định nghĩa Hoàn thành đã được thống nhất trước đó. Tính chất cốt lõi của Phần tăng trưởng đó là có khả năng chuyển giao được, tức là có thể đưa vào sử dụng ngay mà không cần làm thêm bất cứ công việc nào nữa.

c,. Sự kiện

Định nghĩa của Done:

Một Sprint được đánh dấu là Xong khi tất cả các vấn đề đều được hoàn thành, tất cả các nhiệm vụ dev, nghiên cứu, QA đều được đánh dấu là 'Đã hoàn tất', tất cả các lỗi đều được đóng cố định, những lỗi có thể được thực hiện sau này (như không hoàn toàn liên quan hoặc ít quan trọng hơn) được rút ra và bổ sung vào backlog, các đánh giá mã và kiểm tra đơn vị được hoàn thành, số giờ ước tính đã đáp ứng số giờ thực tế được đưa vào nhiệm vụ và quan trọng nhất là bản demo thành công đã được trao cho PO và các bên liên quan.

Các hoạt động đã hoàn thành trong phương pháp SCRUM:

1: Plan meeting

Sự kiện diễn ra đầu Sprint để lên kế hoạch làm việc cho toàn bộ Sprint. Dựa trên các cuộc thảo luận, nhóm scrum quyết định sự phức tạp của vấn đề và kích thước nó theo chuỗi Fibonacci. Nhóm nghiên cứu xác định các nhiệm vụ cùng với những nỗ lực (theo giờ) sẽ được thực hiện để hoàn thành công việc

Nhiều plan meeting được bắt đầu bằng “Pre-plan meeting”. Nó giống như một bài tập về nhà mà nhóm scrum làm trước khi họ ngồi họp chính. Nhóm nghiên cứu cố gắng viết ra các phụ thuộc hoặc các yếu tố khác mà họ muốn thảo luận trong cuộc họp lập kế hoạch.

2: Thực hiện các print tasks

Như tên cho thấy, đây là những công việc thực tế được thực hiện bởi nhóm scrum để hoàn thành nhiệm vụ của họ và đưa câu chuyện của người dùng vào trạng thái "Xong".

3: Daily meeting

Trong print, mỗi ngày nhóm scrum gặp nhau, không quá 15 phút (có thể là một cuộc gọi đứng lên, được đề nghị có trong thời gian đầu ngày) và ghi 3 điểm:

• Thành viên trong nhóm làm gì hôm qua
• Thành viên trong nhóm dự định làm gì hôm nay
• Có gặp phải vấn đề gì không?

Scrum master sẽ là người điều khiển cuộc họp này. Trong trường hợp, thành viên nào trong nhóm phải đối mặt với khó khăn thì Scrum master se theo dõi để giải quyết nó.

4. Review meeting

Vào cuối mỗi print, nhóm SCRUM gặp lại và trình bày các vấn đề của người dùng được triển khai cho PO. PO có thể qua xác minh vấn đề theo tiêu chí chấp nhận của nó. Một lần nữa, trách nhiệm của Scrum master là chủ trì cuộc họp này. Trong công cụ của SCRUM, Sprint sẽ đóng lại và các tác vụ được đánh dấu là hoàn thành.

5. Họp cải tiến print

Cuộc họp cải tiến diễn ra sau cuộc họp đánh giá. Nhóm SCRUM gặp gỡ và thảo luận và ghi lại các điểm sau:

• Điều gì đã hoàn thành tốt trong Sprint (Các phương pháp hay nhất)
• Điều gì đã xảy ra không thuận lợi trong print
• Bài học kinh nghiệm
• Các mục hành động.

2.3.2) Kanban

Kanban là một thuật ngữ tiếng Nhật có nghĩa là thẻ. Các thẻ này chứa các chi tiết về các hạng mục cần thực hiện trên phần mềm. Mỗi thành viên trong nhóm đều nhận thức được công việc cần thực hiện thông qua những hỗ trợ trực quan này.

Các nhóm sử dụng các thẻ Kanban này để delivery liên tục. Cũng giống như Scrum, Kanban cũng để giúp các team làm việc hiệu quả và thúc đẩy các team tự quản lý và hợp tác.

Nhưng có sự khác biệt giữa hai cái này , Trong Scrum ta không thể thêm các hạng mục vào print khi print đang thực thi. Trong khi ở Kanban, chúng ta có thể thêm các hạng mục nếu có khả năng. Điều này đặc biệt hữu ích khi các yêu cầu thay đổi thường xuyên.

Tương tự như vậy, một sự khác biệt là trong khi scrum đã xác định vai trò của một PO, scrum master và các nhóm phát triển, không có các vai trò được xác định trước như vậy trong Kanban.

Một sự khác biệt là trong khi scrum cho thấy ưu tiên các sản phẩm tồn đọng, Kanban không có yêu cầu như vậy và nó là hoàn toàn tùy chọn. Do đó Kanban yêu cầu tổ chức đơn giản hơn và tránh các hoạt động bổ sung không có giá trị và phù hợp với các quy trình đòi hỏi sự đáp ứng đối với các thay đổi.

2.3.3) Lean

Lean - Phát triển Phần Mềm Tinh gọn Tóm lại, Lean loại bỏ bất cứ điều gì không mang lại giá trị và chỉ thực hiện những gì chúng ta thực sự cần tại thời điểm thực hiện.

Loại bỏ lãng phí ở đây có nghĩa là loại bỏ các cuộc họp, công việc, tài liệu vô dụng. Đồng thời cũng loại bỏ những cách làm việc không hiệu quả – Như đa nhiệm – để chuyển giao sản phẩm nhanh hơn. Một quá trình leaner sẽ giúp delivery nhanh hơn và ít nỗ lực lãng phí trong các nhiệm vụ không giúp đạt được mục tiêu của nhóm. Điều này giúp tối ưu hóa mọi bước trong chu trình phát triển phần mềm. Đó là lý do tại sao các nguyên tắc lean được chuyển thể từ sản xuất lean thành phát triển phần mềm.

Phát triển phần mềm Lean áp dụng bảy nguyên tắc lean được trình bày dưới đây:

Bảy nguyên lí Tinh gọn

1. Loại bỏ lãng phí: Tất cả mọi thứ không tăng thêm giá trị cho khách hàng được coi là lãng phí (Muda)
2. Khuếch trương việc học
3. Quyết định càng muộn càng tốt
4. Chuyển giao càng nhanh càng tốt
5. Trao quyền cho nhóm
6. Tạo ra tính toàn vẹn tự thân
7. Thấy toàn cảnh

2.3.4) Lập trình cực đoan (XP)

XP (Extreme Programming) là một phương pháp phát triển phần mềm hướng đến việc nâng cao chất lượng phần mềm và khả năng đáp ứng với thay đổi yêu cầu người dùng

XP tập trung vào việc áp dụng tốt nhất những kỹ thuật lập trình, giao tiếp rõ ràng và làm việc nhóm để tạo những sản phẩm tốt nhất. Một số thành phần và đặc điểm của XP: Lập trình cặp, Rà soát mã nguồn, Kiểm thử đơn vị, Giữ mã nguồn đơn giản và rõ ràng, Sẵn sàng đón nhận các thay đổi, Trao đổi thường xuyên với khách hàng, Trao đổi thường xuyên giữa các nhà phát triển.

Các hoạt động trong XP:

• Viết mã: XP coi mã nguồn là thành phần quan trọng nhất trong quá trình phát triển phần mềm. Không có mã nguồn thì không có sản phẩm chạy được.

• Kiểm thử: XP nói về việc kiểm thử như sau: “Nếu một vài bài kiểm thử có thể loại bỏ được một ít lỗi thì nhiều bài kiểm thử sẽ loại bỏ được nhiều lỗi”. Do vậy XP khuyến khích việc tiến hành kiểm thử ở tất cả mọi mức độ. Từ Kiểm thử đơn vị cho đến Kiểm thử chấp nhận, Kiểm thử tích hợp,…

• Lắng nghe: Các lập trình viên cần lắng nghe khách hàng của họ để biết được họ thực sự cần gì.

• Thiết kế: Cố gắng thiết kế một kiến trúc cho phép loại bỏ phần lớn sự phụ thuộc trong hệ thống, cho phép thay đổi và mở rộng dễ dàng.

Tham khảo:

https://hocvienagile.com/agipedia/tong-quan-agile/

https://kipalog.com/posts/Agile-la-gi---Co-an-duoc-khong

https://itviec.com/blog/agile-la-gi-scrum-la-gi/