Agile & Scrum

I. Sơ lược về Agile

1. Agile là gì?

• Agile là cách thức làm phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt càng sớm càng tốt và được xem như là sự cải tiến (ở một khía cạnh nào đó) khi đặt cạnh những mô hình cũ như Mô hình Thác nước
• Phát triển lặp & gia tăng
• Requirement có thể đáp ứng được việc thay đổi 1 cách nhanh chóng và linhhoạt
• Hình thức của agile:
  Scrum
  XP: eXtreme Programming
  DSDM: Dynamic System Development Method
  RUF: Rational Unified Process
  Kanban

2. Tuyên ngôn của Agile - AGILE Manifesto

1.     Cá nhân và sự tương hỗ quan trọng hơn quy trình và công cụ      
   

2.     Phần mềm chạy tốt quan trọng hơn là tài liệu đầy đủ
   

3.     Cộng tác với khách hàng  quan trọng hơn đàm phán hợp đồng  
   

4.     Phản hồi với sự thay đổi quan trọng hơn bám sát kế hoạch 
   

II. Sơ lược về Scrum

1. Ba vai trò (Role):

• Product Owner: là người sở hữu sản phẩm, người quyết định sản phẩm có những chức năng nào và là người quyết định Product Backlog. Thông thường Role này được khách hàng hoặc người đại diện cho khách hàng đảm nhận.
• ScrumMaster: là người đảm bảo các qui trình của Scrum được thực hiện đúng và thuận lợi, giúp đỡ cho Team thực hiện công việc phát triển sản phẩm một cách tốt nhất.
• Development Team: Một nhóm từ 5-9 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm. Nhóm dự án phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint (giai đoạn) này và kết quả sẽ ra sao. Đồng thời nhóm cũng thảo luận để đưa ra các giải pháp, ước lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc. Nếu dự án lớn chúng ta cần chia ra thành các dự án nhỏ.

2. Các công cụ (artifacts) Scrum

• 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).
• Sprint 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).
• Burndown Chart: Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết còn lại để hoàn tất công việc. Burndown Chart có thể được dùng để theo dõi tiến độ của Sprint (được gọi là Sprint Burndown Chart) hoặc của cả dự án (Project Burndown Chart). Biểu đồ burndown không phải là một thành tố tiêu chuẩn của Scrum theo định nghĩa mới, nhưng vẫn được sử dụng rộng rãi do tính hữu ích của nó.

3. Bốn cuộc họp (4 Events)

• Sprint Planning meeting (Họp để hoạch định cho mỗi giai đoạn)
• Daily Scrum Meeting (Họp review hàng ngày)
• Sprint Review (Họp để tổng kết cho mỗi giai đoạn)
• Sprint Retrospective meeting - Họp cải tiến Sprint

4. Scrum vận hành như thế nào:

Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn nước rút từ 2 đến 4 tuần làm việc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment).
Trước khi cả nhóm cùng đua nước rút trong Sprint, đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint . Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint.
Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint. Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến.
Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.
Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà Scrum mang lại cho tổ chức.

III. So sánh mô hình Waterfall với Scrum

IV. Thách thức và giải pháp

1. Thay đổi requirement: Product backlog
2. Phạm vi kiểmthử sẽ gia tăng: Automate regression test – Tự động hóa kiểm thử hồi quy Priority test – Sắp xếp thứ tự kiểm thử Light document – tài liệu gọn nhẹ
3. Tester cần phải có nhiều kỹ năng khác nhau: Đào tạo (Training) / huấn luyện (coaching) / vận dụng trí tuệ tập thể để giải quyết một vấn đề phức tạp (brainstorming)
4. Tester cần thay đổi từ cách làm truyền thống sang Agile: Khái niệm, kinh nghiệm / thái độ và văn hóa

V. Chiến lược kiểm thử

• Cách tiếp cận toàn bộ nhóm (Whole team)
• Tự động hóa: tích hợp liên tục: liên tục xây dựng và triển khai tự động

• Kiểm thử đơn vị
• Kiểm thử hồi quy

• TDD (Test Driven Development) là một phương thức làm việc, hay một quy trình viết mã hiện đại. Lập trình viên sẽ thực hiện thông qua các bước nhỏ (BabyStep) và tiến độ được đảm bảo liên tục bằng cách viết và chạy các bài test tự động (automated tests). Quá trình lập trình trong TDD cực kỳ chú trọng vào các bước liên tục sau:

1.         Viết 1 test cho hàm mới. Đảm bảo rằng test sẽ fail.
   

2.         Chuyển qua viết code sơ khai nhất cho hàm đó để test có thể pass.
   

3.         Tối ưu hóa đoạn code của hàm vừa viết sao cho đảm bảo test vẫn pass và tối ưu nhất cho việc lập trình kế tiếp
   

4.         Lặp lại cho các hàm khác từ bước 1
   

   Quy trình phát triển TDD:

   

• Pair testing: Developers & Testers
• Kiểm thử dựa vào rủi ro: Để giảm thiểu rủi ro, chúng ta sẽ phải sắp xếp độ ưu tiên cho việc kiểm thử.

Tài liệu tham khảo:
https://agilemanifesto.org/
https://www.educba.com/scrum-vs-waterfall/
https://dzone.com/articles/what-is-scrum-software-development-how-it-works-be