Cập nhật lần cuối vào 21/07/2022 bởi Phạm Mạnh Cường
Chuyển đổi sang Agile có lẽ là điều mà rất nhiều doanh nghiệp mong muốn. Tuy nhiên điều này thì không hề dễ, sự khó khăn tới từ cả tư duy lẫn vận hành. Đây là 10 điều mà bạn nên làm để chuyển đổi Agile thành công. Bài viết này là phần 1, sẽ gồm 5 điều đầu tiên.
Cam kết về an toàn trong công tác quản lý
Để thành công, cam kết về công tác quản lý phải được bảo đảm và ưu tiên trước khi bắt đầu một chương trình. Điều này đúng đối với một chương trình Agile hoặc bất kỳ công việc tổ chức lớn nào.
Người điều hành, thường là nhà tài trợ chương trình, người dẫn dắt sáng kiến chương trình và chịu trách nhiệm cung cấp các nguồn lực cho chương trình và chịu trách nhiệm cuối cùng trong việc cung cấp các lợi ích.
Có nhiều cách để người điều hành tạo điều kiện cho chương trình thành công, bao gồm:
- Đóng vai trò là người đứng đầu chương trình và loại bỏ các rào cản
- Bảo mật và quản lý các nguồn lực của chương trình (ngân sách, con người, điều kiện, v.v.)
- Giúp đảm bảo cam kết từ cả doanh nghiệp và tổ chức CNTT
- Xác định các bên liên quan và giúp truyền đạt nhu cầu của họ.
- Dự đoán các thay đổi đối với chương trình dựa trên sự thay đổi của tổ chức
- Duy trì tầm nhìn và sự phù hợp với các chiến lược của tổ chức và giúp chương trình đạt được sự tuân thủ
- Thiết lập cấu trúc thông tin liên lạc để tạo điều kiện liên lạc từ trên xuống dưới
- Xác định người quản lý chương trình, Product Owner và ScrumMaster có năng lực
Mặc dù cam kết về công tác quản lý và điều hành là điều tối quan trọng đối với sự thành công của một chương trình, nhưng cũng nên có sự tham gia của các cấp cơ sở. Mọi người ở tất cả các cấp có thể là tác nhân thay đổi và nên tham gia để giúp các quy mô thành công đi đúng hướng.
Trao quyền cho đội nhóm
Về bản chất, Agile yêu cầu một cấu trúc nơi các quyết định được đưa ra thường xuyên và nhanh chóng. Với tính chất nhanh chóng và lặp đi lặp lại, việc đưa ra quyết định kịp thời là rất quan trọng để thực hiện thành công.
Không giống như các phương pháp truyền thống, Agile cung cấp sự minh bạch đáng kể và giảm nhu cầu về các khâu kiểm tra. Sự minh bạch này cung cấp cho các nhà quản lý cái nhìn sâu sắc và tạo cơ hội cho các thành viên trong nhóm được trao quyền để đưa ra các quyết định nhất định mà không cần phải liên hệ lại thông qua một loạt các phê duyệt.
Với các nguồn lực phù hợp trong nhóm, bao gồm người dùng cuối, người ra quyết định và các bên liên quan chính khác giúp tạo điều kiện thuận lợi cho quá trình ra quyết định.
Khi chuyển đổi sang Agile, các tổ chức thường đánh giá thấp tác động của việc trao quyền. Nếu cơ cấu tổ chức quản trị không hỗ trợ việc xem xét này, thì khó có thể đạt được thành công.
Trước đây, sử dụng cách tiếp cận truyền thống, đại diện doanh nghiệp chủ yếu tham gia vào giai đoạn đầu (giai đoạn yêu cầu) và cuối cùng (giai đoạn chấp nhận). Với Agile, đại diện doanh nghiệp hiện có vai trò chủ chốt – Product Owner. Không giống như cách tiếp cận truyền thống, trong đó nhóm phát triển lấy thông tin từ phía doanh nghiệp và đặt ra kế hoạch của riêng họ, thường không có kiến thức về các ưu tiên kinh doanh, Product Owner có liên quan trong suốt vòng đời.
Vai trò Product Owner
Product Owner dành một lượng đáng kể thời gian của mình khi bắt đầu chương trình (thường là 40% –50%). Trong thời gian này, họ hỗ trợ việc xác định phạm vi của chương trình, mô tả / làm rõ các yêu cầu và thể hiện chúng dưới dạng user story (user story), và phát triển các công việc tồn đọng được ưu tiên ban đầu.
Trong các giai đoạn tiếp theo, họ thường dành 25% –30% thời gian để xác định, sửa đổi, xây dựng và làm rõ các yêu cầu và user story, đồng thời liên tục ưu tiên công việc để phù hợp với nhu cầu hiện tại của tổ chức và cung cấp hướng dẫn khi cần thiết.
Khi sản phẩm được phát triển, Product Owner nên sẵn sàng cung cấp thông tin làm rõ và gỡ bỏ rào cản cho đội ngũ Agile, tham gia các buổi đánh giá và cung cấp phản hồi. Product Owner chịu trách nhiệm đạt được sự chấp nhận user story và duy trì liên lạc với các bên liên quan trong kinh doanh cũng như các nhà tài trợ điều hành.
Cuối cùng, như cách tiếp cận truyền thống, họ tham dự các buổi trình diễn và thử nghiệm để xác minh sản phẩm hoạt động theo yêu cầu.
Các vai trò khác
Các vai trò khác, ScrumMaster và Agile Team, cũng phải được trao quyền để trở nên tự quản lý và cộng tác trong cộng đồng các bên liên quan. Không giống như cách tiếp cận truyền thống nơi tất cả thông tin được thu thập từ trước, các thành viên trong nhóm chương trình Agile (cả kinh doanh và CNTT) sẽ cộng tác trong suốt vòng đời.
Khi các sản phẩm được phát triển từng bước, các bản mẫu được sử dụng để tạo điều kiện phát triển sản phẩm phù hợp. Các thay đổi được thực hiện gần thời gian thực và các mức độ ưu tiên được cập nhật với mỗi sprint. Sự hợp tác và tham gia của cộng đồng các bên liên quan vào những thời điểm thích hợp giữ cho sản phẩm đi đúng hướng và kết quả phù hợp với nhu cầu hiện tại.
Hiểu văn hóa hợp tác
Cho dù bạn sử dụng cách tiếp cận truyền thống hay Agile, trong phát triển phần mềm, có rất ít dự án tập trung vào công nghệ thông tin (CNTT). Hầu hết các dự án đều tập trung vào sứ mệnh hoặc hỗ trợ doanh nghiệp theo một cách nào đó và tình cờ có các thành phần CNTT.
Điều này rất quan trọng để giúp các tổ chức hiểu được nhu cầu phân bổ các nguồn lực kinh doanh, kỹ thuật và quản lý để hợp tác. Do đó, các đại diện từ các khu vực kinh doanh cần phải điều khiển các chương trình linh hoạt; sự tham gia của họ là nền tảng của một cách tiếp cận nhanh nhẹn. Trọng tâm của các dự án nhanh là ba vai trò chính: Product Owner, ScrumMaster và nhóm (nhóm các bên liên quan, các nguồn lực kinh doanh và kỹ thuật).
Để tạo điều kiện thuận lợi cho văn hóa cộng tác, các nhóm hoặc ít nhất là các thành viên cốt lõi (Product Owner, Scrum Master, Trưởng nhóm), nên có chung một địa điểm làm việc hoặc một phòng họp trực tuyến.
Với các nhóm cộng tác toàn cầu, khi mà múi giờ có sự chênh lệch thì nên có một thời điểm thuận lợi hàng tuần cho cả đôi bên trao đổi thông tin cần thiết.
Các nhóm Agile, bất kể thỏa thuận hợp đồng của họ như thế nào, nên được tích hợp thành một nhóm duy nhất. Cho dù một nhóm được ký hợp đồng riêng để thực hiện thử nghiệm độc lập hoặc cung cấp sự giám sát của ban quản lý, điều quan trọng là phải tích hợp các nhóm để giảm nguy cơ chậm trễ quy trình.
Bản chất của sự tích hợp này không phải là làm mất đi tính độc lập, mà là cung cấp quyền truy cập cho tất cả các nhóm để tạo điều kiện thuận lợi cho vai trò tương đối của họ.
Ví dụ: Một nhóm giám sát quản lý độc lập, nếu được cấp quyền truy cập trực tiếp vào công việc đang thực hiện, sẽ không chỉ có thể cung cấp thông tin đầu vào theo thời gian thực mà còn có thể cho phép nhóm áp dụng các hành động khắc phục mà không bị chậm trễ.
Các nhóm kiểm tra độc lập cần phải tham gia (và tích hợp) trong suốt quá trình. Trong quá trình phát triển các yêu cầu, user story, v.v., nhóm kiểm tra phát triển xem xét các tiêu chí chấp nhận và hiểu được “Definition of Done” .
Việc tích hợp các nhóm kiểm thử không chỉ giúp giảm độ trễ mà còn thường xuyên tiết lộ các cơ hội trong quy trình.
Ví dụ: Nếu các nhóm kiểm thử độc lập thiếu nhân lực, có thể tạo ra một công việc tồn đọng trong giai đoạn kiểm thử, làm cho việc tích hợp và quản lý cấu hình trở nên khó khăn hơn. Nếu các nhóm có thời gian rảnh, công việc có thể được tiến hành theo cách chủ động hơn, hỗ trợ các quá trình hạ nguồn. Nếu những thiếu sót được nhận ra sớm hơn, có thể thực hiện hành động sửa chữa trước khi các vấn đề xuất hiện.
Áp dụng các phương pháp Agile
Nhiều tổ chức đã thử nghiệm với agile bằng cách áp dụng một số phương pháp hay nhất và áp dụng nó vào các phương pháp tiếp cận truyền thống, sau đó điều chỉnh cho phù hợp với mô hình truyền thống cũ của họ, dẫn đến một phương pháp kết hợp Waterfall / Agile.
Mặc dù cách tiếp cận này hiệu quả hơn so với Waterfall, nhưng tài liệu không cần thiết đã được phát triển để lập bản đồ các phương pháp và lợi ích đầy đủ của phát triển Agile có thể không được thực hiện.
Có rất nhiều cách để áp dụng phương pháp Agile, thậm chí có thể phối hợp các phương pháp với nhau.
Ví dụ như đây là một phương pháp được xây dựng dựa trên Scrum, nhưng còn phối hợp từ RUD, DSDM, XP, Kanban, SAFe, DAD và PMI Agile.
Kanban là một phương pháp hiệu quả để quản lý các chương trình loại bảo trì phần mềm lỗi / sửa chữa. Kanban cung cấp cho các chuyên gia phát triển ứng dụng một cách để cải thiện quy trình, tối ưu hóa quy mô và đảm bảo thành công trong thực thi trong các tình huống.
Kanban cũng có thể tăng cường các dự án Agile có liên quan đến nhiều hơn một nhóm, cung cấp các biển chỉ dẫn rõ ràng để cho phép thành công giữa các nhóm.
Xem thêm: Tìm hiểu Kanban từ những điều cơ bản nhất.
Xây dựng lộ trình và các kế hoạch ban đầu
Điều quan trọng cần lưu ý là Agile là một phương pháp phát triển phần mềm và nó không thay thế cho việc lập kế hoạch và chiến lược của tổ chức. Cũng như các phương pháp phát triển phần mềm truyền thống, Agile là một thành phần của quá trình lập kế hoạch tổng thể.
Lập kế hoạch cho Agile có thể kể đến 5 cấp độ: product vision, product roadmap, release plan, sprint plan và daily commitment.
Product vision
Product Vision hay Tầm nhìn Sản phẩm đại diện cho trạng thái tương lai của sản phẩm, tổ chức hoặc các quy trình kinh doanh hỗ trợ.
Tầm nhìn này được phát triển bởi nhà tài trợ hoặc Product Owner để truyền đạt trạng thái tương lai sẽ như thế nào khi kết thúc dự án. Họ chia sẻ cách thức hệ thống / quy trình sẽ thay đổi và doanh nghiệp mong muốn những thay đổi này theo thứ tự nào (thiết lập mức độ ưu tiên).
Họ cũng mô tả một ước tính cấp cao về những gì sẽ cần để hoàn thành dự án (thiết lập các ước tính và cam kết). Việc xem xét định kỳ các cấp kế hoạch khác nhau sẽ giúp tạo điều kiện thuận lợi cho những thay đổi về nhu cầu / mong muốn / ưu tiên của doanh nghiệp và được phản ánh trong các phiên bản cập nhật của kế hoạch ở tất cả các cấp.
Product Roadmap
Product Roadmap hay Lộ trình Sản phẩm được tạo ra để truyền đạt kế hoạch sản phẩm tổng thể cho nhiều bên liên quan.
Lộ trình, thường được mô tả dưới dạng hình ảnh hoặc dòng thời gian, mô tả chức năng được lên kế hoạch để phân phối. Lộ trình sản phẩm sẽ phát triển theo thời gian để phản ánh hướng đi hiện tại của sản phẩm.
Product Owner sẽ giám sát việc cập nhật lộ trình dựa trên nhu cầu hiện tại và mức độ ưu tiên của tổ chức. Các lộ trình được xem xét từ trên xuống ít nhất hàng quý; và từ dưới lên như một phần của việc lập kế hoạch cho mỗi bản phát hành. Thách thức với các lộ trình trong agile là chúng phải được cập nhật để truyền đạt hướng đi hiện tại, với cảnh báo rằng khi các ưu tiên kinh doanh thay đổi, thì lộ trình cũng vậy.
Release Plan
Release plan hay Kế hoạch phát hành – Product Owner chịu trách nhiệm lập kế hoạch phát hành và tận dụng Lộ trình sản phẩm làm điểm khởi đầu cho kế hoạch phát hành.
Các thành phần và tính năng của sản phẩm được ghi lại trong Epics và được phân tách thành các user story. Các user story được ưu tiên, ước tính và đặt trong Release Backlog. Vì các tính năng từ Product Backlog được nhóm thành các bản phát hành, Product Owner có thể tham khảo lại lộ trình để xác minh trình tự phù hợp với kế hoạch tổng thể.
Vì liên tục lập kế hoạch lại là một đặc điểm cốt lõi của nhanh nhẹn, điều quan trọng là không lập kế hoạch quá xa ban đầu. Điều này có thể đặt ra các kỳ vọng, giống như Waterfall, rằng tất cả các khả năng được lên kế hoạch sẽ khả dụng trước khi các khả năng mới được xây dựng.
Sprint Plan
Sprint Plan hay Kế hoạch lặp lại Sprint – Đối với mỗi sprint trong bản phát hành, một phiên lập kế hoạch được tổ chức để áp dụng các hạng mục trong backlog được ưu tiên cho các sprint sắp tới.
Tốc độ làm việc được xem xét từ các sprint trước và sự sẵn có của tài nguyên được xác nhận và sau đó bắt đầu lập kế hoạch. Các user story có thể được xem xét trước hoặc trong phiên và thông tin chi tiết được thêm vào để hỗ trợ việc ước tính.
Việc kết hợp thêm chi tiết vào user story, xem xét tốc độ và khả năng cung cấp tài nguyên giúp nhóm cam kết và cung cấp các tính năng được lên kế hoạch trong quá trình lặp lại đó.
Daily Commitment
Daily commitment hay Kế hoạch hàng ngày – ScrumMaster tạo điều kiện cho một cuộc họp đứng hàng ngày (Scrum).
Trong Cuộc họp Scrum, ba câu hỏi chính được đặt ra:
- Bạn đã làm gì ngày hôm qua?
- Bạn sẽ làm gì hôm nay?
- Bạn có gặp trở ngại gì không?
Ba câu hỏi này giúp ScrumMaster và Product Owner quản lý các kế hoạch sprint, áp dụng hoặc tìm kiếm các nguồn lực bổ sung và truyền đạt tiến độ cho các bên liên quan thích hợp.
Phần tiếp theo: 10 điều nên làm để chuyển đổi Agile thành công (Phần 2)
