(1) Ưu tiên cao nhất là thoả mãn khách hàng bằng cách sớm giao cho họ những gói sản phẩm có giá trị. Việc này phải được duy trì thường xuyên trong 1 khoảng thời gian ngắn: "Gói" ở đây có thể hiểu là 1 mảng nhỏ của cả 1 chương trình lớn, có thể là một hay một vài chức năng (function). "Giá trị" ở đây có nghĩ là những chức năng đó phải làm được 1 chuyện gì đó cụ thể, khách hàng có thể trực quan nhận thấy được "giá trị" đó. Còn nếu không thì không được xem là "giá trị" và cũng sẽ vô ích nếu đưa cho khách hàng những gói mà khách hàng không biết rằng sẽ làm gì với nó.
(2) Chấp nhận khách hàng thay đổi yêu cầu, thậm chí là thay đổi ở những giai đoạn trễ trong quá trình phát triển: đây có thể xem là điểm cốt lõi của Agile, điểm dùng để phân biệt những phương thức đi theo triết lý Agile như XP và Scrum với những phương thức đi theo các cách truyền thống.
(3) Bàn giao những gói sản phẩm "hoạt động được" trong 1 quãng thời gian ngắn, khoảng vài ba tuần cho đến vài ba tháng. Chu kì càng ngắn càng tốt: điều này đã được giải thích rõ ở điểm thứ nhất.
(4) Nhóm hiểu nghiệp vụ (Buiness people) và nhóm phát triển (Developer team) sản phẩm phải cùng hợp tác và làm việc sâu sát với nhau trong quá trình phát triển sản phầm: vấn đề này rất quan trọng, không chỉ đối với Agile mà còn đối với bất kì phương pháp quản lý dự án nào khác, vì nó đảm bảo cho sự thành bại của 1 dự án, đặc biệt là những dự án có tính hay thay đổi như Agile.
Cần chú ý rằng nhóm hiểu nghiệp vụ là những người đưa ra những quyết định về khía cạnh kinh doanh (business decisions) như: "khách hàng cần cái gì, cần phải implement những cái nào trước, cái nào sau, điểm nào là quan trọng nhất trong sản phẩm..etc., còn Developer team là những người đưa ra những quyết định về khía cạnh kĩ thuật (Technical decisions) như: Phải làm chuyện đó như thế nào, tốn bao nhiêu lâu, cần bao nhiêu nhân sự để hoàn tất...etc. Nếu những quyết định về mặt kỹ thuật mà được quyết định bởi Business people và ngược lại, Business decisions mà được quyết định bởi nhóm phát triển thì sẽ là 1 thảm hoạ cho dự án đó. Tiếc rằng việc này trong thực tế rất hay xảy ra, ví dụ rõ nhất là chuyện các sếp ở phòng kinh doanh luôn thích ấn định thời hạn cuối cho sản phẩm hoặc những người phân tích nghiệp vụ (Business Analyst), những người đi lấy requirement, hay cam kết quá đà (over promise) với khách hàng về tính năng của sản phẩm mà không cần tham khảo ý kiến của nhóm phát triển.
(5) Phát triển dự án bằng cách khuyến khích từng cá nhân trong nhóm, tin tưởng vào công việc họ sẽ làm và làm tốt, đồng thời cung cấp mọi sự hỗ trợ khi họ cần hoặc gặp khó khăn.
(6) Cách thức hữu hiệu nhất để có được thông tin hữu ích là lắng nghe đội ngũ phát triển sản phẩm trình bày ý kiến của họ trong những cuộc đối thoại trực tiếp (face-to-face dialog): Đây cũng là 1 đặc điểm chính yếu của các phương thức Agile.
(7) Những gói phần mềm hoạt động được (working software) là thước đo chính cho tiến trình phát triển: như mình đã trình bày ở bên trên, "hoạt động được" tức là phải làm được chuyện gì đó cụ thể mà trực quan cảm nhận được. Nếu không thể thấy, không thể nghe hoặc không đem lại điểm ích lợi cho người dùng gì từ gói phần mềm đó thì không xem là "hoạt động được". Ví dụ bạn nói với cấp trên: tôi sẽ viết 1 phần mềm để xử lý văn bản như MS Word. Sau đó, mỗi tuần bạn đều báo cáo lên tiến độ công việc bằng cách chạy demo cho cấp trên xem 1 vài chức năng như mở file, đọc file hoặc lưu dữ liệu .v.v. Nói ngắn gọn là phải đưa ra được cái gì đấy chạy được. Không thể báo cáo chung chung là "tôi vẫn đang làm" hay "tôi đang nghiên cứu".
(8) Agile là 1 tiến trình phát triển được duy trì chặt chẽ. Khách hàng, đội ngũ phát triển và người sử dụng (khách hàng có thể là người mua cho người khác sử dụng) phải nên được duy trì khả năng tham gia liên tục vào dự án: nói cách khác, họ phải thường xuyên làm việc, xem xét tiến độ và kiểm soát quá trình làm việc. Công việc này trong các phương pháp truyền thống không xảy ra ở vai trò của khách hàng và người dùng, những người chỉ thường xuất hiện ở đầu hoặc cuối của dự án.
(9) Liên tục cải tiến về kĩ thuật và thiết kế: Đây cũng là 1 điểm thu hút của Agile so với các cách truyền thống.
(10) Tính đơn giản: một điểm nữa rất hay ở Agile chính là làm sao để chỉ làm những gì cần phải làm. Ví dụ yêu cầu của khách hàng là vẽ 1 con rắn thì nhóm phát triển chỉ cần phải vẽ đúng con rắn, không nên vẽ thêm chân hay họa tiết cho con rắn vì làm như thế là phức tạp hoá vấn đề, không cần thiết và lãng phí, mặc dầu trong mắt những người lập trình, điều này rất hấp dẫn.
(11) Nhóm làm việc độc lập về tổ chức nhóm, tìm hiểu yêu cầu sản phẩm và đưa ra kết cấu, thiết kế của chương trình: Như đã trình bày ở trên, khách hàng đôi khi chính họ cũng không biết rằng họ thực sự cần gì và muốn gì, ý kiến của họ chỉ nên được viết thành "user stories" và "user pain points" không nên quá tin và lời của họ mà mất đi cái nhìn tổng quan, dẫn đến những sản phẩm lệch hướng như cái hình minh hoạ ở trên.
(12) Nhóm phát triển phải thường xuyên gặp gỡ để bàn bạc công việc, đánh giá tiến độ của từng cá nhân và định ra hướng đi phù hợp tiếp theo cũng như những hành động cụ thể để giải quyết những vấn đề đang khúc mắc.
» Tin mới nhất:
» Các tin khác: