Phát triển phần mềm Agile
Agile là cách tiếp cận phát triển phần mềm trong đó tổ xây dựng phần mềm trong vài lần lặp ngắn, thay vì mọi thứ đi từ bắt đầu tới kết thúc. Agile cung cấp ích lợi như linh hoạt, dễ thay đổi, chất lượng tốt, ít rủi ro và thoả mãn khách hàng tốt hơn nhưng có “tiền điều kiện” mà tổ chức phải có để đạt tới những ích lợi này.
Agile yêu cầu sự tham gia của khách hàng trong mọi khía cạnh của dự án. Nếu khách hàng bận rộn và không thể tham gia được thì Agile sẽ KHÔNG có tác dụng. Một trong các phương pháp phổ biến nhất trong Agile là “Scrum”. Phương pháp này định nghĩa ba vai trò then chốt: “Người chủ sản phẩm” người đại diện cho khách hàng và chịu trách nhiệm viết yêu cầu và ưu tiên hoá chúng trong “tồn dư sản phẩm”. “Thầy Scrum,” người hướng dẫn và giúp đỡ tổ dự án vượt qua các chướng ngại và giữ cho họ hội tụ vào những điều họ phải làm. Tổ dự án, một nhóm “tự tổ chức” làm mọi điều một cách hiệu quả nhất để đạt tới kết quả. Dùng cách tiếp cận Agile là thay đổi chính trong tổ chức với cấu trúc phân cấp và mọi người thường nhận được “chỉ đạo” từ ông chủ. Đó là lí do tại sao tôi mạnh mẽ khuyến cáo rằng trước khi vào từng dự án, tổ phải nhận được đào tạo Agile “chính thức” để chắc rằng sẽ KHÔNG có hiểu lầm nào hay quan niệm lầm nào về cách tiếp cận này. Không có đào tạo đúng, Agile có thể bị DÙNG SAI vì một số người lập trình coi nó là “Làm bất kì điều gì bạn muốn,” “Mã trước, hỏi câu hỏi sau,” “Không tài liệu, không qui trình.”
Agile bao gồm một số thực hành mà hình thành nên nền tảng cho tổ chức muốn tuân theo cách tiếp cận này.
1) Tổ Agile phải xác định cho bản thân họ cách họ sẽ làm việc (thiết lập qui trình) và cách họ sẽ làm công việc (phát triển sản phẩm). Tổ Agile phải hiểu giá trị của dự án. Giá trị có thể được mô tả là “Linh hoạt”, “Chất lượng”, “Dễ thay đổi”, “Tự học, tổ học” v.v. Trong cách tiếp cận Agile, tổ đi qua “các giai đoạn phát triển tổ” khi họ thực hiện công việc của họ. Kết quả của phát triển tổ là bản thân tổ, và không phải là kĩ năng và năng lực mà các cá nhân học. Làm việc tổ là bản chất trong Agile, không có nó, Agile sẽ KHÔNG có tác dụng.
2) Lúc bắt đầu dự án, người chủ sản phẩm chuẩn bị một danh sách các yêu cầu của khách hàng hay “Tồn dư sản phẩm”, danh sách các tính năng được sắp ưu tiên bởi giá trị được chuyển giao cho khách hàng. Với từng lần lặp (Sprint - chặng nước rút), một số trong những khoản mục đó trong tồn dư sản phẩm được lựa ra và đưa vào trong “Sprint Backlog - Tồn dư nước rút”, danh sách những điều cần được làm trong từng chặng nước rút Sprint. Trong cách tiếp cận Agile, thay đổi là bình thường và được đưa vào trong tồn dư sản phẩm bởi người chủ sản phẩm vì khách hàng liên tục cung cấp phản hồi hay thêm nhiều tính năng. Tổ tiếp tục công việc trong vài lần lặp (Sprint) cho tới khi họ hoàn thành tồn dư sản phẩm.
3) Agile dùng các thời kì thời gian ngắn hay “Sprint” (phương pháp Scrum) điển hình quãng 2 tới 4 tuần, để chuyển giao cái gì đó cho khách hàng. Từng “Sprint” được tổ chức để cho tổ thực tế hoàn thành một mảnh của sản phẩm toàn bộ. Ngay khi mảnh này của sản phẩm có thể được chuyển giao, nhiều giá trị hơn có thể được thu lấy. Tính linh hoạt này giúp khách hàng có cái gì đó nhanh chóng để dùng, tổ cũng nhận phản hồi ngay lập tức, và giảm rủi ro dự án.
4) Mọi “Sprint” đều được cai quản bởi “phạm vi được xác định” trong tồn dư nước rút Sprint. Tổ ước lượng nỗ lực và chi phí của từng Sprint và điều phối với người chủ sản phẩm. Cách tiếp cận Agile dùng “chu kì học” tường minh (tức là, lập kế hoạch, làm, kiểm tra, hành động) hay (Lập kế hoạch, hành động, suy nghĩ, học) để cho tổ thường xuyên học, cải tiến và sẵn sàng điều chỉnh khớp theo thay đổi. Sau từng lần lặp (Sprint), tổ sẽ kiểm điểm công việc riêng của họ hay “nội quan-quan sát bên trong” để nhận diện công việc nào, cái gì không có tác dụng để cải tiến qui trình riêng của họ để cho họ có thể làm nó tốt hơn lần sau. Đó là lí do tại sao dự án Agile thường có chất lượng cao.
5) Tổ Agile phải có phương tiện trao đổi hiệu quả giữa các thành viên tổ và khách hàng. Để đạt tới điều đó, tổ cần trao đổi giữa con người thay vì bất kì cách nào khác như email, thư, văn bản hay tài liệu. Mặc dầu một số người nói rằng Agile cũng có thể được thực hiện trong phát triển toàn cầu, có các thành viên tổ ở nhiều chỗ hay ở nhiều nước. Theo kinh nghiệm của tôi, tôi thấy điều đó khá khó. Không có trao đổi tốt, tổ có thể phí thời gian về thông tin, các thành viên có thể hiểu lầm nhau, dự án có thể có nhiều lỗi hay phải làm lại. Không có trao đổi mặt đối mặt điều đó có thể làm chậm phát triển dự án, khó xây dựng tin cậy giữa các thành viên tổ, khó xây dựng tổ, và có thể KHÔNG có khả năng gióng thẳng cảm nhận về thực tại. Khuyến cáo cá nhân của tôi là đối với cách tiếp cận Agile, cách tốt nhất là để mọi thành viên tổ ở cùng một chỗ nơi họ có thể làm việc cùng nhau, hỗ trợ lẫn nhau, và chia sẻ thông tin một cách tự do.
6) Bằng kiểm thử mọi thứ, bằng việc tạo ra các trường hợp kiểm thử để kiểm tra mọi công việc, tổ có thể đạt tới mức chất lượng cực kì cao. Khả năng này để ngăn cản khiếm khuyết là rất quan trọng trong Agile bởi vì “chất lượng là KHÔNG thương lượng được”. Trong cách tiếp cận này, loại bỏ khiếm khuyết là kiểu làm việc duy nhất được coi là ưu tiên so với bất kì tính năng /chức năng/sản xuất mới. Nếu kết quả cuối cùng được mong muốn là làm cực đại chất lượng, thì loại bỏ khiếm khuyết là điều quan trọng nhất. Tổ có nghĩa vụ đạo đức để kiểm tra một cách hiệu quả công việc của họ bằng bất kì phương tiện nào họ có thể làm bằng việc dùng công cụ, cơ chế phản hồi đa dạng, tự động hoá để chắc họ có sản phẩm chất lượng cao nhất có thể được.
7) Mọi thành viên tổ Agile đều phải nhận trách nhiệm “phát quang con đường” hay loại bỏ chướng ngại ngăn cản công việc được thực hiện một cách hiệu quả. “Phát quang con đường” KHÔNG chỉ có nghĩa là mưu kế cách thức, sửa nhanh vấn đề, mà thay vì thế là để thời gian nhìn vào chướng ngại và làm tốt nhất có thể được để loại bỏ nó vĩnh viễn để cho nó không bao giờ chắn đường lần nữa. Trong cách tiếp cận Agile, người dẫn qui trình (thầy Scrum) là người chịu trách nhiệm theo dõi chướng ngại và đảm bảo rằng con đường được phát quang. Phát quan con đường đôi khi là công việc đau đớn làm phơi bày những điều mọi người thà không giải quyết. Kết quả là, điều mấu chốt là mọi người xây dựng năng lực của họ để chân thực và làm việc để phát triển tin cậy lẫn nhau.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
