Doanh nghiệp áp dụng Agile có thực sự thành công?

Arvind Arcot với 13 năm kinh nghiệm trong vai trò tư vấn và Business Analyst đã chia sẻ kinh nghiệm của ông về việc các doanh nghiệp đang bắt đầu áp dụng xu hướng Agile. Bài viết thể hiện quan điểm của tác giả và những trải nghiệm thực tế, đây cũng là chủ đề được rất nhiều bạn đọc quan tâm trong năm 2022.

Agile đang được các doanh nghiệp đón nhận rộng rãi

Khi làm việc tại các công ty khác nhau, tôi đã thấy nhiều công ty học cách trở thành agile trong khi một số giả vờ là agile và số khác thậm chí không phải là agile. Mặc dù, chúng ta không ở đây để nói về danh mục cuối cùng (giả sử họ không có lý do để đi theo agile), tôi sẽ liệt kê những khó khăn mà một doanh nghiệp sẽ gặp phải trên chặng đường trở thành agile và những doanh nghiệp nghĩ rằng họ là Agile nhưng không phải. Bài viết này, tôi xin chia sẻ hiểu biết của mình về những lý do chính khiến một số doanh nghiệp đấu tranh để đạt được điều đó.

1. Nhiều bản phát hành

Các tổ chức đã quá quen với việc sử dụng mô hình làm việc thác nước, có điều kiện dành thời gian cho việc lập kế hoạch, thiết kế, phát triển, kiểm thử và triển khai. Điều này cho phép họ đủ cơ sở để sửa chữa những sai lầm mà không ảnh hưởng đến công việc kinh doanh vốn thường phải lùi ngày ra mắt.

Có thể có một yếu tố áp lực ở đó, vì các bản phát hành thường xuyên hơn đồng nghĩa chúng ta cần phải đề phòng những sai lầm. “Chúng tôi không thể phát hành thứ gì đó có lỗi” là một lý do phổ biến để lo lắng về Agile. Cách giảm áp lực là hiểu chìa khóa nằm ở việc chia nhỏ user stories (câu chuyện người dùng) đến mức độ chi tiết tốt. Các user stories được chia càng nhỏ càng tốt, nhóm phân phối càng tự tin hơn. Họ có một gói công việc tương đối đơn giản để giao cho doanh nghiệp, có thể đạt được một cách dễ dàng. Hơn nữa, có nhiều cách để đảm bảo bạn có ít lỗi hơn trong quá trình sản xuất bằng cách chạy các bài kiểm tra tự động (hồi quy và tiến trình).

2. Cấu trúc tổ chức phẳng

Agile là về một nhóm gồm những cá nhân có hiệu suất cao cùng nhau tạo nên điều kỳ diệu. Điều đầu tiên mà các tổ chức cần làm (để trở thành agile) là từ bỏ quyền hạn (chưa từ bỏ trách nhiệm giải trình) trong dự án. Đây thường là điều không thể chấp nhận đối với hầu hết công ty và một số nền văn hóa nhất định.

Điều quan trọng cần nhớ đối với các tổ chức là dù các đội agile vẫn sẽ nằm dưới hệ thống phân cấp tổ chức bao quát nhưng quyền hạn là thứ vẫn sẽ được áp dụng cho các cá nhân bên ngoài nhóm và không chỉ nằm trong dự án.

3. Hiểu sai hoặc chỉ một nửa về cách hoạt động của Agile

Một nửa kiến thức nguy hiểm hơn cả việc không có kiến thức. Các tổ chức thường sử dụng các từ như Agile wall (bức tường), daily stand up, sprints, MVP, user stories trong số những người khác nhưng không hiểu cách tiếp cận Agile toàn diện. Tôi đã xem Agile walls với những tấm thẻ những tấm thẻ không có user stories, thay vào đó là tên của chính dự án. Mặc dù, việc này có thể tốt để ban quản lý hiểu vị trí của từng dự án nhưng chúng ta cần một bức tường tương tự cho từng dự án ở mức độ chi tiết sâu hơn nhiều.

Tôi đã thấy các tổ chức chia các dự án thác nước (waterfall) thành các cuộc chạy nước rút (sprint) và đạt được các nhiệm vụ dựa trên cách tiếp cận SDLC. Các tổ chức tin rằng nếu chúng ta chạy nước rút, chúng ta đang trên đường trở thành agile.

Tôi đã tham dự một hội nghị Agile nơi tôi bắt gặp sơ đồ dưới đây bởi Henrik Kniberg mà tôi nghĩ đó là ví dụ hoàn hảo về cách các tổ chức mắc sai lầm. Henrik Kniberg giải thích chi tiết điều này trong bài viết của anh ấy “Making sense of MVP (Minimum Viable Product) và tại sao tôi thích Earliest.

Nguồn: (Henrik Kniberg: Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable)

Đây chỉ là đại diện cho việc chúng ta làm sai Agile như thế nào. Người ta có thể tranh luận rằng tôi muốn có một chiếc ô tô và tất cả những gì bạn cho tôi là một chiếc ván trượt, đây là những gì Agile gọi là walking skeleton (bộ xương biết đi).

Bộ xương biết đi là một triển khai nhỏ của hệ thống thực hiện một chức năng nhỏ từ đầu đến cuối. Nó không cần sử dụng kiến trúc cuối cùng nhưng nó nên liên kết các thành phần kiến trúc chính với nhau. Sau đó, kiến trúc và chức năng có thể phát triển song song.

Lưu ý rằng khuôn mặt cười không thực sự cười sau khi nhận được một chiếc ván trượt nhưng chắc chắn đang trên đường đến những gì nó thực sự muốn.

4. Quá nhanh chóng

Điều này liên kết trở lại luận điểm đầu tiên. Nhiều bản phát hành đặt ra một áp lực lên các đội nhóm thực hiện vì các nhóm phải liên tục chuyển từ tập hợp user stories này đến user stories khác, nên có vẻ như bạn đang làm việc liên tục và có thể xem là tốc độ nhanh. Mặc dù, nó có thể không quá xa với sự thật nhưng niềm vui thật sự nằm ở việc cộng tác với một nhóm các chuyên gia cùng chí hướng. Khi những tâm trí vĩ đại kết hợp cùng với nhau, những điều vĩ đại được tạo ra.

5. Những điều thần kỳ về Agile

Đã có rất nhiều bài viết vạch trần những sự lầm tưởng về Agile. Chúng ta sẽ không đi sâu vào đó nhưng tác giả muốn khuyến nghị bạn đọc nên hiểu mục đích của Agile và không đưa ra bất kỳ giả định nào về mục đích của nó, trước khi bắt đầu cam kết bản thân và tổ chức theo Agile.

Nếu không, bạn chỉ đang giả vờ là Agile với một nửa sự hiểu biết và điều này thì rất nguy hiểm.

Trên đây là những chia sẻ từ một người có nhiều năm kinh nghiệm làm việc thực tế về Agile. Mong rằng những thông tin này sẽ hữu ích với bạn đọc, đừng quên đón xem các bài viết mới nhất sẽ được cập nhật thường xuyên tại BAC’s Blog.

Nguồn tham khảo:

https://www.modernanalyst.com

Nhu cầu đào tạo doanh nghiệp