Agile không chỉ dành cho các nhà phát triển phần mềm — phương pháp này còn được ứng dụng và tạo ra tác động tích cực ở bất kỳ nơi nào trong doanh nghiệp mà nó được áp dụng. Dưới đây là sáu nguyên tắc Agile mà bạn có thể sử dụng ở hầu hết mọi nơi.
Mặc dù các nguyên tắc Agile ban đầu được phát triển dành cho phần mềm, nhưng chúng có thể được áp dụng cho hầu hết mọi lĩnh vực khác trong tổ chức của bạn. Cộng tác, giao tiếp cởi mở, tin cậy và độc lập, hiệu suất và chuyển giao liên tục là nền tảng của Agile và chúng có thể tạo ra tác động tích cực lâu dài ở hầu hết mọi nơi trong tổ chức của bạn. Tại hội nghị Agile Alliance 2015 ở Washington, D.C., Tim Ottinger, cố vấn cấp cao của Industrial Logic, đưa ra sáu nguyên tắc Agile mà bạn có thể sử dụng ở hầu hết mọi nơi.
Một quan niệm sai lầm phổ biến về Agile là phương pháp này bỏ qua việc lập kế hoạch và quy trình – và điều đó hoàn toàn sai sự thật. Điều quan trọng cần nắm rõ là việc lập kế hoạch và quy trình thường diễn ra đồng thời với việc hoàn thành công việc.
“Công việc nằm ở việc suy nghĩ, chứ không phải ở việc đánh máy. Động não, nói chuyện, thậm chí đùa giỡn với các thành viên trong nhóm – đó đều là một phần của công việc. Đôi khi những ý tưởng và giải pháp tốt nhất không đến từ việc cần mẫn code liên tục mà từ việc buông bỏ. Ottinger khẳng định: “Điều quan trọng không phải là ‘đặt ngón tay trên bàn phím’ mà là ‘đặt tâm trí vào cuộc chơi’”.
Agile cung cấp giá trị sớm cho các bên liên quan và thường sử dụng một tiến trình đơn giản bao gồm các bước: Lập kế hoạch, phát triển, hoàn thành, thử nghiệm và phát hành. Sau đó, lặp lại. Điều quan trọng là thực hiện điều đó trong một khoảng thời gian ngắn — Sprint — và sau đó tiến hành các điều chỉnh phần tăng trưởng dựa trên phản hồi của các bên liên quan.
Ottinger chia sẻ: “Các giới hạn về thời gian trong Agile làm giảm khả năng xảy ra sai sót, sự cố, lỗi và việc đi chệch hướng. Với tư cách là một nhóm sản phẩm, chúng ta không biết mọi người sẽ thực sự thích gì ở sản phẩm của chúng ta hoặc họ sẽ sử dụng những gì, bởi vì những người này thật điên rồ và họ luôn thay đổi suy nghĩ. Vì vậy, bạn phải trình bày mọi thứ trước mặt mọi người thường xuyên và càng sớm càng tốt để họ có thể nói ‘có’, ‘không’ hoặc ‘gần như vậy’. Bạn muốn làm họ thất vọng nhiều lần theo cách có kiểm soát trong nhiều tháng, để cuối cùng bạn có thể khiến họ cực kỳ hạnh phúc”.
Nếu nhóm của bạn bị choáng ngợp bởi quy mô và phạm vi của các dự án sắp tới, hãy bắt đầu việc cắt. Cắt và chia nhỏ công việc thành nhiều phần có thể hoàn thành trong giới hạn của một Sprint. Hãy tiếp tục cắt và chia nhỏ cho đến khi công việc có thể quản lý được và phân bổ dựa trên thế mạnh của mỗi nhóm.
“Đôi khi bạn sẽ nhận được một chỉ thị như, ‘Thêm thương mại điện tử vào đây.’ Chà, nó lớn đến mức nào? Bạn muốn nó hoạt động như thế nào? Nó sẽ trông như thế nào? Nó được sử dụng như thế nào? Tiếp tục hỏi những câu hỏi đó, và sau đó tiếp tục chia nhỏ câu trả lời thành nhiều phần nhỏ hơn. Đây là sức mạnh của sự hỗn loạn. Có vẻ như không có gì xảy ra và thoạt đầu có vẻ như còn nhiều việc phải làm vì có quá nhiều đầu việc, nhưng các nhóm liên chức năng có đầy đủ các năng lực cần thiết để hoàn thành công việc,” theo Ottinger.
Một quan niệm sai lầm phổ biến khác về Agile là phương pháp này có thể tăng tốc độ của nhóm sản phẩm. Mặc dù điều đó đúng ở một khía cạnh nào đó, nhưng không phải lúc nào cũng vậy; thay vào đó, điều thường xảy ra là một nhóm gia tăng năng lực và khả năng tạo ra các sản phẩm giá trị, từ đó tốc độ tăng lên.
Do đó, Ottinger tin rằng: năng lực hay tốc độ là hệ quả, không phải là sự lựa chọn. Năng lực thể hiện số lượng công việc có thể hoàn thành trong một khoảng thời gian nhất định mà không khiến các nhóm bị căng thẳng quá mức. Sau khi tìm ra điều đó, các doanh nghiệp và nhóm sẽ xác định số lượng nguồn lực cần thiết trong khung thời gian đó hoặc có thể điều chỉnh khung thời gian sao cho phù hợp.
“Trường phái tư tưởng cũ cho rằng để tăng tốc độ, ta phải tăng nỗ lực. Nhưng ta thường kết thúc với những sai lầm và một sản phẩm kém chất lượng. Để nâng cao năng lực, chúng ta sử dụng Agile để phát triển kỹ năng, nâng cao kiến thức, cải tiến công cụ, chia sẻ công việc hiệu quả, giảm thiểu sự kém hiệu quả và giảm lãng phí — và điều đó giúp chúng ta tiến nhanh hơn,” Ottinger cho biết.
Làm thế nào để bạn trả lời được câu hỏi không thể tránh khỏi, “Khi nào dự án sẽ được hoàn thành?” Câu trả lời là “không bao giờ”. Đó là cái được gọi là sự bất biến đáng sợ; đặc biệt là trong thế giới phần mềm, “hoàn thành” là một khái niệm linh hoạt vì các bản cập nhật, bản vá, sửa lỗi, thay đổi, bổ sung và giảm bớt tính năng là một nỗ lực không ngừng. “Khi người dùng cuối cùng xóa bản sao cuối cùng của phần mềm khỏi máy cuối cùng đang chạy nó – thì đó là lúc phần mềm sẽ hoàn thành. Không có gì gọi là Hoàn thành, chỉ có sự cải tiến. Nếu không, bạn đang nhìn thấy sự lỗi thời,” Ottinger nhấn mạnh.
“Khi thực hiện công việc, chúng ta học cách thực hiện công việc đó. Tất cả chúng ta đều làm những công việc khác nhau và không có “cách đúng đắn” nào để tạo ra sản phẩm hoặc để làm cho sản phẩm hoạt động hoàn hảo. Bạn phải “làm” Agile của riêng bạn. Bạn phải tìm ra cách của riêng mình, điều gì phù hợp với công ty, dự án và nhóm của bạn. Nhưng bạn sẽ thấy cũng chính là điều Agile sẽ chứng minh cho bạn thấy: phòng ngừa tốt hơn sửa chữa. Sự lặp đi lặp lại liên tục đó tốt hơn là đi đến cuối cùng và nhận ra mình đã thất bại,” Ottinger tổng kết.
Bài viết liên quan:
Bạn đã đăng ký thành công
Xin cảm ơn bạn đã đăng ký nhận tư vấn
Xin cảm ơn bạn đã đăng ký
Mời bạn kiểm tra Email để tải tài liệu.