Bỏ qua để đến nội dung

Phát triển Agile là gì?

Agile là tên gọi chung cho một họ các phương pháp được xây dựng quanh một niềm tin duy nhất: phần mềm quá khó đoán để có thể lập kế hoạch chi tiết ngay từ đầu, nên hãy giao hàng theo từng lát nhỏ, lắng nghe những gì phản hồi về, và điều chỉnh liên tục.

Trang này trình bày phần nền tảng. Nếu bạn đã biết tất cả những điều này, hãy lướt nhanh đến East Agile Tracker ánh xạ sang agile như thế nào.

Vào tháng Hai năm 2001, mười bảy người thực hành phần mềm — Kent Beck, Martin Fowler, Robert Martin, Ron Jeffries, và những người khác — đã gặp nhau tại một nhà nghỉ trượt tuyết ở Utah và viết ra những điểm chung của họ. Họ gọi đó là Tuyên ngôn Agile. Nó gồm bốn dòng:

Chúng tôi đang khám phá những cách tốt hơn để phát triển phần mềm bằng cách tự mình làm và giúp người khác làm. Qua công việc này, chúng tôi đã đi đến chỗ coi trọng:

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

Nghĩa là, dù những thứ ở bên phải có giá trị, chúng tôi coi trọng những thứ ở bên trái hơn.

Chỉ vậy thôi. Một trang lời mở đầu, mười hai nguyên tắc hỗ trợ, và bốn dòng ở trên. Đó là tài liệu có ảnh hưởng nhất trong thực hành phần mềm hiện đại.

Đằng sau bốn giá trị, mười hai nguyên tắc của tuyên ngôn chỉ rõ “agile” thực sự trông như thế nào trong từng ngày:

  1. Ưu tiên cao nhất là làm hài lòng khách hàng thông qua việc giao phần mềm có giá trị sớm và liên tục.
  2. Chào đón những yêu cầu thay đổi, ngay cả muộn màng. Các quy trình agile khai thác thay đổi để tạo lợi thế cạnh tranh cho khách hàng.
  3. Giao phần mềm hoạt động được một cách thường xuyên — theo tuần thay vì theo tháng.
  4. Người làm kinh doanh và nhà phát triển phải làm việc cùng nhau hàng ngày.
  5. Xây dựng dự án quanh những cá nhân có động lực. Cho họ những gì họ cần và tin tưởng họ hoàn thành công việc.
  6. Cách hiệu quả nhất để truyền đạt thông tin là trò chuyện trực tiếp.
  7. Phần mềm hoạt động được là thước đo chính của tiến độ.
  8. Các quy trình agile thúc đẩy phát triển bền vững — một nhịp độ ổn định, vô thời hạn.
  9. Sự chú ý liên tục đến sự xuất sắc về kỹ thuật và thiết kế tốt làm tăng tính linh hoạt.
  10. Sự đơn giản — nghệ thuật tối đa hóa khối lượng công việc không phải làm — là thiết yếu.
  11. Những kiến trúc, yêu cầu, và thiết kế tốt nhất nảy sinh từ các đội ngũ tự tổ chức.
  12. Đội ngũ thường xuyên phản ánh về cách trở nên hiệu quả hơn, rồi tinh chỉnh và điều chỉnh.

“Agile” là một cái ô. Dưới nó là một số phương pháp luận riêng biệt:

  • eXtreme Programming (XP) — Đòi hỏi khắt khe nhất trong họ. Lập trình theo cặp, TDD, tích hợp liên tục, khách hàng tại chỗ, các release nhỏ. Xem trang XP của chúng tôi.
  • Scrum — Các iteration đóng khung thời gian gọi là sprint, standup hàng ngày, các vai trò có tên (Product Owner, Scrum Master). Nhẹ về thực hành kỹ thuật hơn XP.
  • Kanban — Trực quan hóa luồng công việc, giới hạn công việc đang dở, tối ưu hóa luồng. Không có khung thời gian; kéo (pull) thay vì đẩy (push).
  • Lean — Vay mượn từ hệ thống sản xuất của Toyota: loại bỏ lãng phí, tối ưu hóa tổng thể, giao hàng nhanh, xây dựng chất lượng vào trong.

Các phương pháp này chồng lấn và kết hợp với nhau. Hầu hết các đội ngũ thực tế đều chọn lọc từ cả bốn. East Agile Tracker thiên về quan điểm XP — xem eXtreme Programming — nhưng hầu hết những gì nó cung cấp đều phù hợp với bất kỳ hương vị agile nào.

Một vài quan niệm sai lầm dai dẳng đáng được nêu tên:

  • Agile không phải là “không lập kế hoạch.” Các kế hoạch nhỏ hơn và ngắn hơn, nhưng việc lập kế hoạch thì liên tục.
  • Agile không phải là “không có tài liệu.” Viết những gì cần thiết. Tuyên ngôn nói rằng phần mềm hoạt động được có giá trị hơn tài liệu đầy đủ — không phải rằng tài liệu là xấu.
  • Agile không phải là Scrum. Scrum là một phương pháp agile. Còn có nhiều phương pháp khác.
  • Agile không phải là một công cụ. Không công cụ nào làm cho bạn agile. Agile là một cách làm việc. Công cụ (bao gồm cả công cụ này) giúp ích; chúng không thay thế.

East Agile Tracker ánh xạ sang agile như thế nào

Phần tiêu đề “East Agile Tracker ánh xạ sang agile như thế nào”

East Agile Tracker được thiết kế quanh các nguyên tắc ở trên. Đây là sự tương ứng:

Nguyên tắcTracker hỗ trợ nó như thế nào
Giao hàng liên tụcIteration 1–4 tuần; tự lập kế hoạch dựa trên velocity; release là một loại story hạng nhất.
Chào đón thay đổiSắp xếp lại backlog bất cứ lúc nào; story di chuyển qua các iteration tự do; không có “khóa iteration.”
Phần mềm hoạt động được là thước đoVelocity mặc định tính số điểm được chấp nhận — chỉ công việc đã giao, hoạt động được mới tính.
Nhịp độ bền vữngVelocity không phải là một mục tiêu; nó là một quan sát. Hệ thống lập kế hoạch iteration tiếp theo bằng những gì bạn thực sự làm.
Phản ánhPhân tích theo từng iteration: burndown, tỷ lệ từ chối, cycle time, dự báo.
Đội ngũ tự tổ chứcCác vai trò được giữ tối thiểu một cách có chủ đích: owner / member / viewer. Đội ngũ tự quyết định.
Sự đơn giảnBảng chi tiết gói gọn trong một màn hình. Board vừa trên một trang. Chúng tôi cưỡng lại những tính năng làm phân tâm khỏi việc phát hành.

Tuyên ngôn được viết vào năm 2001. Kể từ đó, phát triển phần mềm đã có thêm một loại người tham gia mới: các AI agent.

Chúng tôi nghĩ agent thuộc về đội ngũ agile — như những bên tham gia có tên, với các vai trò riêng, làm công việc thực sự song song cùng con người. Các nguyên tắc vẫn đúng. Cá nhân và sự tương tác giờ bao gồm cả những bên tham gia là agent. Đội ngũ tự tổ chức giờ bao gồm việc quyết định mang agent nào vào và chúng được phép làm gì. Phản ánh giờ bao gồm việc nhìn vào các đóng góp của agent trong nhật ký hoạt động và tinh chỉnh những gì chúng đang làm.

East Agile Tracker được xây dựng để biến điều này thành thực tế. Mỗi story đều có thể được sở hữu bởi một con người hoặc một agent. Mỗi mục audit log đều quy cho tác nhân thực sự. Mọi hành động một agent thực hiện đều hiển thị, có thể đánh giá, và có thể thu hồi.

Được xây dựng bởi East Agile.