fbpx

6 Nguyên Tắc Agile có thể áp dụng rộng rãi trong mọi lĩnh vực

Các phương pháp Agile, dù ban đầu được thiết kế cho phát triển phần mềm, đã chứng minh hiệu quả cao trong nhiều lĩnh vực tổ chức khác nhau. Các nguyên tắc về sự hợp tác, giao tiếp mở, tin tưởng và độc lập, hiệu quả và cung cấp liên tục có thể biến đổi nhiều khía cạnh của hoạt động kinh doanh. Dưới đây là sáu nguyên tắc Agile bạn có thể áp dụng trong nhiều bối cảnh để nâng cao năng suất và kết quả

6 Nguyên Tắc Agile có thể áp dụng rộng rãi trong mọi lĩnh vực

12/08/2024
Chia sẻ:
6 Nguyên Tắc Agile có thể áp dụng rộng rãi trong mọi lĩnh vực

Các phương pháp Agile, dù ban đầu được thiết kế cho phát triển phần mềm, đã chứng minh hiệu quả cao trong nhiều lĩnh vực tổ chức khác nhau. Các nguyên tắc về sự hợp tác, giao tiếp mở, tin tưởng và độc lập, hiệu quả và cung cấp liên tục có thể biến đổi nhiều khía cạnh của hoạt động kinh doanh. Dưới đây là sáu nguyên tắc Agile bạn có thể áp dụng trong nhiều bối cảnh để nâng cao năng suất và kết quả

Nguồn bài viết: 6 agile principles that apply to everything

10 Agile Terms You Should Know - number8

Nguyên tắc 1 trong 6 nguyên tắc Agile:
Đôi Khi Công Việc Không Trông Giống Công Việc

Agile bao gồm nhiều công việc lập kế hoạch và quy trình quan trọng. Một hiểu 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 – điều này hoàn toàn không đúng. Điều quan trọng là phải hiểu rằng thường thì việc lập kế hoạch và quy trình diễn ra đồng thời với công việc được hoàn thành.
“Công việc nằm ở suy nghĩ, không phải ở việc gõ phím. Tư duy, nói chuyện, thậm chí vui đùa với các thành viên trong nhóm – tất cả đều là một phần của nó. Đôi khi những ý tưởng và giải pháp tốt nhất không đến từ việc mãi mãi cúi đầu gõ phím mà từ việc thả lỏng. Điều quan trọng không phải là ‘ngón tay trên bàn phím’ mà là ‘đầu óc tập trung,’” Tim Ottinger, cố vấn cao cấp tại Industrial Logic, nói.

Cung Cấp Giá Trị Sớm Và Thường Xuyên

Agile là về việc cung cấp giá trị cho các bên liên quan sớm và thường xuyên bằng cách sử dụng một loạt các bước đơn giản: Lập kế hoạch, phát triển, hoàn thành, kiểm tra và phát hành. Sau đó, lặp lại. Chìa khóa là thực hiện trong một khoảng thời gian ngắn – một sprint – và sau đó thực hiện các điều chỉnh nhỏ dựa trên phản hồi của các bên liên quan.
“Các ràng buộc thời gian trong Agile giảm thiểu khả năng xảy ra tai nạn, vấn đề, lỗi và sai hướng. Nó giới hạn sự tiếp xúc của chúng ta. Như một nhóm sản phẩm, chúng ta không biết chính xác những gì người dùng thực sự thích hoặc sẽ sử dụng, vì họ thay đổi ý kiến liên tục. Vì vậy, bạn phải đưa sản phẩm trước mắt người dùng càng sớm và thường xuyên càng tốt để họ có thể nói ‘có,’ ‘không,’ hoặc ‘gần đúng.’ Bạn muốn làm họ thất vọng liên tục trong một cách kiểm soát qua nhiều tháng, để cuối cùng bạn có thể làm họ cực kỳ hài lòng,” Ottinger nói.

Chia Nhỏ Công Việc (Hoặc, Chấp Nhận Sự Hỗn Loạn)

Nếu các nhóm của bạn cảm thấy choáng ngợp bởi kích thước và phạm vi của các dự án sắp tới, hãy bắt đầu chia nhỏ. Cắt nhỏ công việc thành những phần có thể hoàn thành trong phạm vi một sprint và tiếp tục chia nhỏ cho đến khi công việc trở nên quản lý được và được phân bổ dựa trên thế mạnh của từng nhóm. Đây là lúc công việc lập kế hoạch nặng nề ban đầu trở nên cần thiết; bạn phải đảm bảo rằng các yêu cầu kinh doanh được xác định rõ ràng và cụ thể.
“Đôi khi bạn sẽ nhận được chỉ thị như, ‘Thêm e-commerce vào cái này.’ Vậy, nó lớn cỡ nào? Bạn muốn nó làm gì? Nó nên trông như thế nào? Nó được sử dụng như thế nào? Tiếp tục đặt những câu hỏi đó, và sau đó tiếp tục chia nhỏ các câu trả lời thành các phần nhỏ hơn nữa. Đây là sức mạnh của sự hỗn loạn. Ban đầu, có vẻ như không có gì xảy ra – xem #1 – và đầu tiên có vẻ như có nhiều việc phải làm hơn vì có quá nhiều mảnh ghép, nhưng các nhóm đa chức năng có tất cả các năng lực cần thiết để hoàn thành công việc,” theo Ottinger.

Tập Trung Vào Khả Năng, Không Phải Tốc Độ

Một hiểu 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 tăng khả năng và khả năng sản xuất các sản phẩm khả thi, dẫn đến tốc độ tăng.
Khả năng hay, vận tốc, Ottinger nói, do đó là hệ quả, không phải là lựa chọn. Khả năng cho thấy bao nhiêu công việc có thể hoàn thành trong một khoảng thời gian nhất định mà không làm căng thẳng các nhóm. Khi đó đã được xác định, các doanh nghiệp và nhóm sẽ xác định cần bao nhiêu tài nguyên trong khoảng thời gian đó, hoặc khoảng thời gian có thể được điều chỉnh để phù hợp với thời gian và tài nguyên hạn chế.
“Trường phái cũ nghĩ rằng để tăng tốc độ, bạn phải tăng nỗ lực. Cắt góc, chấp nhận rủi ro. Nhưng bạn thường kết thúc với những sai lầm và sản phẩm kém chất lượng. Để tăng khả năng, chúng ta sử dụng Agile để phát triển kỹ năng, tăng kiến thức, cải thiện công cụ, chia sẻ công việc hiệu quả, giảm lãng phí – và điều đó giúp chúng ta di chuyển nhanh hơn,” Ottinger nói.

Trả Lời Câu Hỏi Không Thể Tránh Khỏi

Làm thế nào bạn trả lời câu hỏi không thể tránh khỏi, “Khi nào dự án sẽ hoàn thành?” Câu trả lời là, “không bao giờ.” Đây được gọi là sự thường xuyê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 và thay đổi tính năng, thêm vào và bớt đi là một nỗ lực liên tục. “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ó – đó là khi phần mềm sẽ hoàn thành. Không có cái gọi là hoàn thành, chỉ có sự cải tiến. Nếu không, bạn đang đối mặt với sự lỗi thời,” Ottinger nói.

Phương Pháp Agile Là Kinh Nghiệm

“Trong quá trình làm việc, chúng ta học cách làm việc. Chúng ta đều làm các công việc khác nhau, và không có ‘cách đúng’ 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 tự tìm ra cách Agile của mình. Bạn phải tìm ra điều gì phù hợp với công ty, dự án và nhóm của bạn. Nhưng điều bạn sẽ nhận thấy, điều mà Agile sẽ chứng minh cho bạn, là phòng ngừa tốt hơn sửa chữa. Việc lặp đi lặp lại liên tục tốt hơn là đến cuối cùng mới nhận ra mình đã thất bại,” Ottinger nói.

Tags