Hiện nay, các quy trình Agile đã được chấp nhận là những giải pháp thay thế hiệu quả cho các quy trình phát triển phần mềm truyền thống. Hầu hết những người áp dụng Agile đã thấy được những ích lợi của việc chuyển giao nhanh hơn, chất lượng cao hơn, sản phẩm đáp ứng tốt hơn nhu cầu người dùng, v.v.

Không phải tất cả mọi người đều yêu thích Agile. Nhiều người vẫn ái ngại với việc áp dụng Agile dù đó là quyết định từ các sếp hay quyết định tự phát của những người trẻ xông xáo muốn đổi mới. Việc chuyển sang Agile thường xung đột với các mục đích cá nhân như giữ nguyên hiện trạng, không muốn rủi ro nghề nghiệp, không muốn làm việc quá mức cần thiết, hoặc duy trì quyền lực dưới hình thức báo cáo trực tiếp.

Bài viết này gồm những lời khuyên dành cho những người như vậy, những người phải trở nên Agile nhưng không muốn. Đừng lo. Chúng tôi sẽ không cố gắng dụ dỗ bạn dùng thử Agile, thuyết phục bạn về những lợi ích của Agile hay nói cho bạn cách để thành công. Không, chúng tôi sẽ giúp bạn đảm bảo Agile bị thất bại. Sau đó bạn có thể trở lại với vùng an toàn của mình.

Dù có nhiều cách để phá hoại một dự án Agile, để thuận tiện chúng ta sẽ nhóm chúng lại thành bốn danh mục: các vấn đề về quản lý, vấn đề về nhóm, vấn đề về Product Owner và các vấn đề về quy trình. Trong mỗi danh mục, chúng tôi sẽ đưa ra một ví dụ về người đã làm cho Agile thất bại, đưa ra danh sách các hướng dẫn chung cho thất bại mà ví dụ đã thể hiện ra, và danh sách những kĩ thuật thay thế khác bạn có thể thử để tái tạo lại thất bại đó. Chúng tôi hi vọng cách này sẽ giúp bạn thất bại nhanh hơn và tránh được những thành công tiềm ẩn.

CÁC VẤN ĐỀ QUẢN LÝ

Drew đã thấy các trào lưu quản lý đến và đi. Trong suy nghĩ của Drew, Agile cũng vậy. Là một người học nhanh, anh đã đọc vài cuốn sách và thậm chí còn học một lớp về Agile. Anh không tin Agile, nhưng là người có tinh thần đồng đội, anh có nghĩa vụ phải thử Agile một lần.

Drew chọn các thành viên cho  nhóm và yêu cầu họ 'hãy Agile'. Drew yêu cầu nhóm cần họp hàng ngày, ước lượng công việc, và mỗi tháng  làm ra được một phiên bản của sản phẩm (một công cụ cơ sở dữ liệu để lưu trữ tác phẩm nghệ thuật).

Bởi vì Drew không tin Agile và khả năng của nhóm, anh ta tham gia tất cả các phiên Scrum Hằng ngày, hết sức để ý và chỉ ra điều gì nhóm làm đúng, điều gì làm sai. Cuộc họp hàng ngày nhanh chóng trở thành một phiên bản mẫu mực để sửa lỗi về cách làm và ngôn từ. Do đó, không ai nói về các vấn đề – đặc biệt là trước mặt Drew. Drew đã thành công làm theo hướng dẫn đầu tiên để làm Agile thất bại của chúng tôi.

còn tiếp…

HÃY LIÊN HỆ VỚI CHÚNG TÔI ĐỂ NHẬN THÔNG TIN ĐẦY ĐỦ VỀ BÀI VIẾT

Tên của bạn (*)

Địa chỉ Email (*)

Chức vụ (*)

Số điện thoại

HÃY BẮT TAY VỚI CHÚNG TÔI ĐỂ BẮT ĐẦU HÀNH TRÌNH AGILE