Hướng dẫn phương pháp Agile

Agile là một phương pháp luận phát triển phần mềm để xây dựng một phần mềm từng bước bằng cách sử dụng các lần lặp ngắn từ 1 đến 4 tuần để quá trình phát triển phù hợp với nhu cầu kinh doanh đang thay đổi.

Thay vì một quá trình phát triển kéo dài từ 6 đến 18 tháng trong đó tất cả các yêu cầu và rủi ro được dự đoán từ trước, Agile áp dụng quy trình phản hồi thường xuyên trong đó sản phẩm khả thi được phân phối sau 1 đến 4 tuần lặp lại.

Phương pháp Agile

Hướng dẫn đơn giản này sử dụng các ví dụ thích hợp để giúp bạn hiểu về phương pháp phát triển agile một cách tổng quát và nhanh chóng.

Đối tượng độc giả

Hướng dẫn này đã được chuẩn bị cho người mới bắt đầu để giúp họ hiểu những điều cơ bản về các nguyên tắc Agile và cách thực hiện nó. Sau khi hoàn thành hướng dẫn này, bạn sẽ thấy mình ở mức độ chuyên môn vừa phải, từ đó bạn có thể tiến xa hơn.

Điều kiện tiên quyết

Trước khi tiếp tục hướng dẫn này, bạn cần có kiến ​​thức cơ bản về các khái niệm phát triển phần mềm như yêu cầu phần mềm, viết mã, kiểm thử, v.v.

Các vai trò trong Agile

Scrum Master

Scrum Master là người lãnh đạo và hỗ trợ nhóm, người giúp các thành viên trong nhóm tuân theo các phương pháp thực hành nhanh để họ có thể đáp ứng các cam kết của mình. Các trách nhiệm của một Scrum Master như sau:

  • Cho phép hợp tác chặt chẽ giữa tất cả các vai trò và chức năng.
  • Loại bỏ bất kỳ khối nào.
  • Bảo vệ team khỏi bất kỳ sự xáo trộn nào.
  • Làm việc với tổ chức để theo dõi tiến trình và quy trình của công ty.
  • Đảm bảo rằng các quy trình kiểm tra & thích ứng Agile được tận dụng đúng cách.

Quy trình kiểm tra & thích ứng Agile bao gồm:

  • Daily meeting.
  • Planned meeting.
  • Demo.
  • Review.
  • Retrospective meeting
  • Tạo điều kiện cho các cuộc họp nhóm và quá trình ra quyết định.

Product Owner

Product Owner là người định hướng sản phẩm từ góc độ kinh doanh. Các trách nhiệm hoặc Product Owner như sau:

  • Xác định các yêu cầu và ưu tiên các giá trị của chúng.
  • Xác định ngày phát hành và nội dung.
  • Giữ vai trò tích cực trong việc lập kế hoạch lặp lại và các cuộc họp lập kế hoạch phát hành.
  • Đảm bảo rằng nhóm đang làm việc theo yêu cầu có giá trị nhất.
  • Đại diện cho tiếng nói của khách hàng.
  • Chấp nhận các user story để định nghĩa tiêu chí hoàn thành và các tiêu chí chấp nhận.

Nhóm đa chức năng

Mỗi nhóm Agile nên là một nhóm tự túc với 5 đến 9 thành viên trong nhóm và kinh nghiệm trung bình từ 6 đến 10 năm. Thông thường, một nhóm Agile bao gồm 3 đến 4 nhà phát triển, 1 người kiểm tra, 1 trưởng nhóm kỹ thuật, 1 product owner và 1 chuyên gia thiết kế.

Nhóm Agile

Product Owner và Scrum Master được coi là một phần của Team Interface, trong khi các thành viên khác là một phần của Technical Interface.

Làm thế nào một nhóm Agile lập kế hoạch công việc của mình?

Một nhóm Agile làm việc lặp lại nhiều lần để phân phối các user story trong đó mỗi lần lặp là từ 10 đến 15 ngày. Mỗi user story được lập kế hoạch dựa trên mức độ ưu tiên và kích thước backlog của nó. Nhóm sử dụng năng lực của mình - bao nhiêu giờ có sẵn cùng nhóm để thực hiện các nhiệm vụ - để quyết định họ phải lập kế hoạch phạm vi bao nhiêu.

Làm thế nào một nhóm Agile lập kế hoạch công việc của mình?

Point

Một Point (Điểm) xác định mức độ mà một nhóm có thể cam kết. Một điểm thường đề cập đến 8 giờ. Mỗi user story được ước tính bằng điểm.

Capacity

Capacity (Năng lực) xác định mức độ mà một cá nhân có thể cam kết. Công suất được ước tính bằng giờ.

User Story là gì?

User Story (Câu chuyện người dùng) là một yêu cầu xác định những gì được người dùng yêu cầu dưới dạng chức năng. User Story có thể ở hai dạng:

  • Với tư cách là <Vai trò người dùng>, tôi muốn <Chức năng> để <Giá trị doanh nghiệp>
  • Để <Giá trị doanh nghiệp> với tư cách là <Vai trò người dùng>, tôi muốn <Chức năng>

Trong quá trình lập kế hoạch phát hành, một ước tính sơ bộ được đưa ra cho một câu chuyện của người dùng bằng cách sử dụng thang điểm tương đối làm điểm. Trong quá trình lập kế hoạch lặp lại, User Story được chia thành các Task.

Mối quan hệ của User Story và Task

  • User story nói về những gì sẽ được thực hiện. Nó xác định những gì người dùng cần.
  • Task nói về cách nó được thực hiện. Nó xác định cách một chức năng được triển khai.
  • Các user story được triển khai bởi các task. Mỗi user story là một tập hợp các task.
  • User story được chia thành các task khi nó được lập kế hoạch trong quá trình lặp lại hiện tại.
  • Các task được ước tính bằng giờ, thường từ 2 đến 12 giờ.
  • Các user story được xác thực bằng cách sử dụng các bài kiểm tra chấp nhận (acceptance test).
Mối quan hệ của User Story và Task

Khi nào một user story hoàn thành?

Nhóm quyết định định nghĩa khi nào thì một user story hoàn thành? Các tiêu chí có thể là:

  • Tất cả các task (phát triển, thử nghiệm) được hoàn thành.
  • Tất cả các bài kiểm tra chấp nhận được thông qua.
  • Không có khuyết tật nào được tạo.
  • Product Owner đã chấp nhận.
  • Cung cấp cho người dùng cuối.

Acceptance Criteria là gì?

Acceptance Criteria (Tiêu chí chấp nhận) xác định chức năng, hành vi và hiệu suất mà một tính năng yêu cầu để nó có thể được Product Owner chấp nhận. Nó xác định những gì phải làm để nhà phát triển biết khi nào User Story hoàn tất.

Yêu cầu được xác định như thế nào?

Các yêu cầu được định nghĩa là:

  • Một User Story,
  • Với Acceptance Criteria, và
  • Task để thực hiện User Story.

Tuyên ngôn Agile

Vào tháng 2 năm 2001, tại khu nghỉ mát Snowbird ở Utah, 17 nhà phát triển phần mềm đã gặp nhau để thảo luận về các phương pháp phát triển phần mềm. Kết quả của cuộc họp của họ là Tuyên ngôn Agile sau đây để phát triển phần mềm

Chúng tôi đã phát hiện ra cách phát triển phần mềm tốt hơn bằng cách thực hiện nó và giúp đỡ người khác thực hiện. Qua công việc này, chúng tôi đã đi đến việc đánh giá cao:

  • Cá nhân và 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 thay đổi hơn là bám sát kế hoạch

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

Mười hai nguyên tắc của Tuyên ngôn Agile

  1. Ưu tiên cao nhất của chúng tôi là thỏa mãn khách hàng thông qua việc chuyển giao sớm và liên tục các phần mềm có giá trị.
  2. Chào đón việc thay đổi yêu cầu, thậm chí rất muộn trong quá trình phát triển. Các quy trình linh hoạt tận dụng sự thay đổi cho các lợi thế cạnh tranh của khách hàng.
  3. Thường xuyên chuyển giao phần mềm chạy tốt tới khách hàng, từ vài tuần đến vài tháng, ưu tiên cho các khoảng thời gian ngắn hơn.
  4. Nhà kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày trong suốt dự án.
  5. Xây dựng các dự án xung quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng họ để hoàn thành công việc.
  6. Phương pháp hiệu quả nhất để truyền đạt thông tin tới nhóm phát triển và trong nội bộ nhóm phát triển là hội thoại trực tiếp.
  7. Phần mềm chạy tốt là thước đo chính của tiến độ.
  8. Các quy trình linh hoạt thúc đẩy phát triển bền vững. Các nhà tài trợ, nhà phát triển, và người dùng có thể duy trì một nhịp độ liên tục không giới hạn.
  9. Liên tục quan tâm đến các kĩ thuật và thiết kế tốt để gia tăng sự linh hoạt.
  10. Sự đơn giản – nghệ thuật tối đa hóa lượng công việc chưa xong – là căn bản.
  11. Các kiến ​​trúc tốt nhất, yêu cầu tốt nhất, và thiết kế tốt nhất sẽ được làm ra bởi các nhóm tự tổ chức.
  12. Nhóm phát triển sẽ thường xuyên suy nghĩ về việc làm sao để trở nên hiệu quả hơn, sau đó họ sẽ điều chỉnh và thay đổi các hành vi của mình cho phù hợp.

Nếu Comdy hữu ích và giúp bạn tiết kiệm thời gian làm việc

Bạn có thể vui lòng đưa Comdy vào whitelist của trình chặn quảng cáo ❤️ để hỗ trợ chúng tôi trong việc trả tiền cho dịch vụ lưu trữ web để duy trì hoạt động của trang web.

Software Development MethodologyAgile