Đó chính là lời hứa thầm lặng đằng sau Agile khi được triển khai đúng cách. Không phải nhanh hơn chỉ để nhanh hơn. Mà nhanh hơn bởi vì bản thân cách thức thực hiện công việc đã thay đổi.
Tôi đã chứng kiến nhiều quản lý dự án biến Agile thành một nghi thức. Họp đứng mỗi sáng, một bảng công việc với những thẻ màu, số sprint tăng dần như một bộ đếm. Các cuộc họp vẫn diễn ra, các nghi thức trông vẫn đúng bài bản, vậy mà thời hạn bàn giao vẫn liên tục bị trễ. Vấn đề hiếm khi nằm ở đội ngũ. Vấn đề là Agile đã được áp dụng như một nhịp hoạt động thay vì một kỷ luật.
DevVina xem Agile là một kỷ luật, và sự khác biệt thể hiện rõ ở hai điều quan trọng nhất đối với bạn: người dùng được trải nghiệm phần mềm hoạt động sớm đến đâu, và ngân sách có thể duy trì tính dự đoán đến mức nào.
Hãy để tôi giải thích cụ thể điều đó trông như thế nào, bởi cụm từ “phát triển Agile” đã bị sử dụng quá rộng rãi đến mức gần như chẳng còn mang nhiều ý nghĩa.
Hãy bắt đầu với đơn vị công việc. Rất nhiều đội ngũ vẫn lập kế hoạch theo từng giai đoạn. Thiết kế trong sáu tuần, xây dựng trong mười hai tuần, kiểm thử trong bốn tuần, rồi phát hành khi lịch trình cho phép. Nếu có bất kỳ vấn đề nào xảy ra — và chắc chắn sẽ có vấn đề — toàn bộ chuỗi công việc sẽ bị dịch chuyển. Một phụ thuộc bị trễ sẽ kéo theo mọi thứ phía sau, và chi phí của sự chậm trễ ngày càng lớn bởi bạn chỉ phát hiện vấn đề ở cuối quy trình, khi việc sửa chữa đã trở nên tốn kém nhất.
Agile tại DevVina đảo ngược cách tiếp cận đó. Chúng tôi chia sản phẩm thành những lát cắt nhỏ, trong đó mỗi lát cắt đều mang lại một thứ có thể sử dụng được. Khách hàng có thể đăng nhập. Một khoản thanh toán có thể được xử lý. Một báo cáo có thể được tạo ra. Chưa phải toàn bộ hệ thống, nhưng đó là một phần thực sự hoạt động của hệ thống mà ai đó có thể trực tiếp sử dụng và phản hồi.
Mỗi lát cắt sẽ đi qua một chu kỳ thu nhỏ của riêng nó. Lập kế hoạch, xây dựng, kiểm thử, đánh giá, rồi quyết định bước tiếp theo dựa trên những gì vừa học được. Vòng lặp này được lặp lại sau mỗi vài tuần, và mỗi vòng đều kết thúc bằng một thứ có thể trình diễn được.
Đây là cách nó tác động đến thời gian đưa sản phẩm ra thị trường. Bạn không phải chờ đến cuối dự án mới biết hướng đi có đúng hay không. Sau ba tuần, bạn đã có thể biết giả định cốt lõi có đúng hay không. Nếu không đúng, bạn có thể chuyển hướng khi chi phí chuyển hướng vẫn còn thấp. Nếu đúng, bạn tiếp tục với sự tự tin cao hơn. Dù theo hướng nào, bạn cũng không bao giờ rơi vào tình huống đã dành sáu tháng cho một dự án rồi mới tự hỏi liệu mình có xây nhầm thứ hay không.
Tôi đã chứng kiến những đội ngũ dành cả một năm để xây dựng chính xác những gì bản đặc tả yêu cầu, chỉ để phát hiện ra rằng thị trường đã thay đổi. Agile rút ngắn đáng kể khoảng thời gian rủi ro đó, bởi phản hồi xuất hiện trong vài tuần thay vì vài mùa.
Bây giờ đến phần mà các quản lý dự án quan tâm nhất: ngân sách.
Chi phí có thể dự đoán nghe có vẻ trái ngược với Agile. Agile chấp nhận sự thay đổi, mà thay đổi thì nghe có vẻ tốn kém. Nhưng đây mới là điểm khác biệt quan trọng.
Các dự án theo mô hình báo giá cố định truyền thống cố gắng khóa phạm vi công việc ngay từ đầu. Mỗi yêu cầu được định giá, mỗi tính năng có một con số cụ thể, và hợp đồng nói rằng đây là những gì chúng ta sẽ xây dựng với số tiền này. Vấn đề là ngay từ đầu, không ai thực sự biết sản phẩm phù hợp cần phải như thế nào.
Vì vậy, bản đặc tả được viết ở mức khái quát, đội ngũ xây dựng dựa trên một mục tiêu còn mơ hồ, và các yêu cầu thay đổi bắt đầu xuất hiện ngay khi bất kỳ ai nhìn thấy một màn hình thực tế. Mỗi thay đổi lại mở ra một vòng đàm phán. Mỗi vòng đàm phán tiêu tốn thời gian và thiện chí. Đến cuối cùng, mức giá “cố định” đã tăng lên qua hàng chục phụ lục thay đổi, và tất cả các bên đều có cảm giác như mình đã chịu thiệt một chút.
DevVina tiếp cận chi phí theo cách khác. Chúng tôi không giả vờ rằng mình biết mọi thứ ngay từ ngày đầu tiên, và cũng không yêu cầu bạn phải biết tất cả. Thay vào đó, chúng tôi làm việc theo một mô hình trong đó bạn nhìn thấy khoản chi tiêu diễn ra như thế nào, gắn trực tiếp với giá trị mà khoản chi đó tạo ra.
Mỗi sprint có một chi phí. Mỗi sprint tạo ra một thứ hữu hình để bạn nhìn thấy. Bạn không bao giờ phải bỏ tiền vào một “hộp đen” có nhãn “giai đoạn hai”. Bạn đang đầu tư vào một chuỗi các phần gia tăng có thể phát hành, và tại mỗi điểm kiểm tra, bạn có thể giảm tốc, tăng tốc hoặc thay đổi hướng.
Đó mới là ý nghĩa thực sự của tính dự đoán. Không phải một con số được khắc vào đá, mà là một nhịp làm việc trong đó những bất ngờ luôn ở mức nhỏ và có thể kiểm soát. Khi một ưu tiên mới xuất hiện — và chắc chắn sẽ xuất hiện — bạn cân nhắc nó dựa trên sprint hiện tại thay vì so với một kế hoạch kéo dài mười hai tháng. Việc điều chỉnh có thể chỉ tiêu tốn một tuần làm việc, thay vì phải đàm phán lại cả hợp đồng.
Cũng cần nói thẳng về sự đánh đổi. Agile không mang đến cho bạn một báo giá cố định chắc chắn cho toàn bộ sản phẩm ngay từ ngày đầu tiên. Nếu tổ chức của bạn bắt buộc phải có điều đó, nếu bộ phận mua sắm sẽ không thể tiến hành nếu không có một con số duy nhất cho toàn bộ dự án, Agile sẽ khiến bạn cảm thấy không thoải mái.
Thay vào đó, bạn có một mức chi phí đáng tin cậy cho mỗi sprint, một bức tranh rõ ràng về những gì mỗi sprint mang lại, và khả năng dừng lại bất cứ lúc nào khi giá trị không còn tương xứng với chi phí. Với nhiều đội ngũ, sự đánh đổi đó hoàn toàn đáng giá. Với một số đội ngũ khác thì không, và việc biết trước điều này cũng rất quan trọng.
Có một loại chi phí khác hiếm khi được nhắc đến. Agile đòi hỏi Product Owner tham gia nhiều hơn so với Waterfall. Bạn không thể bàn giao một bản đặc tả vào tháng Một rồi đến tháng Bảy mới quay lại kiểm tra. Bạn cần có mặt trong các buổi review, đưa ra quyết định về thứ tự ưu tiên và trả lời các câu hỏi khi đội ngũ gặp phải những điểm chưa rõ ràng.
Đó là công việc thực sự ở phía bạn. Đổi lại, bạn có thể liên tục định hướng sản phẩm thay vì đặt cược tất cả vào một tài liệu được viết từ rất sớm.
Nếu mức độ tham gia đó khiến bạn cảm thấy như một gánh nặng, hãy thành thật với chính mình trước khi bắt đầu. Nếu nó khiến bạn cảm thấy mình đang có quyền kiểm soát, thì Agile chính xác là mô hình bạn đang tìm kiếm, bởi nó mang lại cho bạn nhiều ảnh hưởng đối với kết quả hơn bất kỳ phương pháp nào dựa trên việc chốt đặc tả ngay từ đầu.
Hãy để tôi cho bạn một hình dung cụ thể về nhịp làm việc này, bởi những khái niệm trừu tượng chỉ có thể giúp chúng ta đến một mức nhất định. Hãy tưởng tượng một sprint hai tuần điển hình tại DevVina.
Ngày đầu tiên, chúng tôi xem lại những gì sprint trước đã tạo ra. Bạn nhìn thấy phần mềm đang hoạt động, chứ không phải slide trình chiếu. Bạn trực tiếp dùng thử, kiểm tra, tương tác và nêu ra những điểm bạn cảm thấy chưa ổn.
Đội ngũ tiếp nhận những phản hồi đó và cùng với bạn quyết định hai tuần tiếp theo sẽ tập trung vào điều gì. Các ưu tiên được xác định dựa trên giá trị kinh doanh, không phải sự thuận tiện về mặt kỹ thuật. Sau đó, đội ngũ tập trung vào công việc.
Trong suốt sprint, không có sự im lặng. Đội ngũ cập nhật tiến độ trong một không gian chung mà bạn có thể kiểm tra bất cứ lúc nào. Các trở ngại được đưa ra ngay trong ngày chúng xuất hiện, thay vì đợi đến khi chúng trở nên nghiêm trọng.
Nếu một nhiệm vụ hóa ra lớn hơn dự kiến, điều đó sẽ được phát hiện ngay giữa sprint, khi vẫn còn thời gian để điều chỉnh phạm vi thay vì làm trễ toàn bộ tiến độ.
Kết thúc hai tuần, bạn lại gặp đội ngũ. Một buổi demo khác. Một loạt quyết định khác. Một sprint tiếp theo được cấp ngân sách hoặc thu gọn lại dựa trên những gì bạn vừa nhìn thấy.
Hãy để ý những điều không xuất hiện trong bức tranh này.
Không có chuyện đến tháng thứ sáu mới phát hiện kiến trúc hệ thống không thể hỗ trợ tính năng mà bạn đã cam kết. Không có chuyện đến tuần cuối cùng mới phát hiện việc kiểm thử sẽ mất thời gian gấp đôi việc xây dựng. Không có khoảnh khắc nào bạn nhận ra đội ngũ đã hiểu sai yêu cầu và dành ba tháng để xây dựng sai thứ.
Tất cả những thảm họa đó đều có chung một nguyên nhân gốc rễ: phản hồi đến quá muộn.
Agile đưa phản hồi lên phía trước của quy trình, nơi nó thực sự có thể tạo ra tác động.
Đối với các quản lý dự án và Product Owner, điều này thay đổi công việc theo hướng tích cực. Bạn không còn là người giám sát liên tục xem kế hoạch có đang đúng tiến độ hay không. Bạn trở thành một chiến lược gia, người quyết định phần gia tăng tiếp theo nên là gì.
Các báo cáo trạng thái trở nên ngắn hơn vì bạn đã trực tiếp nhìn thấy công việc diễn ra. Danh sách rủi ro trở nên nhẹ hơn vì rủi ro được phát hiện khi chi phí xử lý chúng vẫn còn thấp.
Cách đo lường thành công cũng thay đổi.
Thay vì hỏi: “Chúng ta có đang bám sát bản đặc tả ban đầu không?”, bạn hỏi: “Mỗi phần gia tăng có đang tạo ra giá trị không?”
Đó là hai câu hỏi khác nhau, và câu hỏi thứ hai dẫn đến những sản phẩm tốt hơn.
Cũng cần nói một chút về cách chúng tôi xây dựng đội ngũ, bởi phương pháp chỉ hiệu quả khi con người có khả năng thực thi nó.
DevVina xây dựng đội ngũ xoay quanh sản phẩm thay vì xoay quanh một nguồn nhân lực lập trình viên chung chung. Những người bắt đầu dự án với bạn sẽ tiếp tục đồng hành cùng dự án. Họ tích lũy bối cảnh qua từng sprint, vì vậy bạn không phải trả “chi phí tái đào tạo” cho một người mới phải mất thời gian tìm hiểu lại lý do tại sao một quyết định nào đó được đưa ra vào tháng Ba.
Tính liên tục đó là một phần lý do giúp chi phí có thể dự đoán được.
Việc thay đổi nhân sự rất tốn kém, không chỉ về tiền bạc mà còn về động lực và đà phát triển. Khi cùng một nhóm kỹ sư đưa sản phẩm từ sprint đầu tiên đến lúc ra mắt, họ nhớ những đánh đổi đã được thực hiện, nhận biết trước những điểm dễ phát sinh vấn đề và làm việc nhanh hơn vì không phải liên tục học lại từ đầu.
Các đội ngũ cũng thực hành những gì Agile đề cao ngay trong nội bộ. Họ tổ chức retrospective của riêng mình, không phải để đánh dấu hoàn thành một checklist, mà thực sự xem xét điều gì đã làm họ chậm lại và họ sẽ thay đổi điều gì.
Những hiệu quả nhỏ sẽ cộng dồn theo thời gian.
Một quy trình build giúp tiết kiệm hai mươi phút mỗi ngày. Một phương pháp kiểm thử phát hiện một nhóm lỗi trước khi chúng đến tay bạn. Một thói quen giao tiếp loại bỏ hai ngày chờ đợi qua email.
Không điều nào trong số đó quá lớn nếu xét riêng lẻ. Nhưng khi kết hợp lại, đó chính là lý do một đội ngũ DevVina có thể hoàn thành trong vài tháng một công việc mà một đội ngũ kém kỷ luật hơn có thể kéo dài thành cả năm.
Tôi cũng muốn nói rõ rằng Agile không phải phép màu.
Agile sẽ không thể cứu một sản phẩm không có người chịu trách nhiệm rõ ràng, một đội ngũ không có kỹ sư cấp cao, hay một stakeholder từ chối đưa ra quyết định. Những vấn đề đó có thể phá vỡ bất kỳ phương pháp nào.
Điều Agile làm được là loại bỏ những trì hoãn nhân tạo xuất phát từ sự ma sát trong quy trình, để công việc thực sự có thể tiến triển với tốc độ mà bản chất của công việc cho phép.
Nếu bạn đã quen với một thế giới mà mọi tiến độ đều có phần đệm và mọi ước tính đều được cộng thêm thời gian dự phòng, sự minh bạch này ban đầu có thể khiến bạn cảm thấy lạ.
Bạn sẽ thấy một nhiệm vụ được ước tính mất ba ngày nhưng không hoàn thành trong ba ngày, và đội ngũ sẽ giải thích lý do cho bạn ngay trong ngày thứ hai, chứ không phải đến ngày thứ hai mươi.
Sự trung thực đó chính là một tính năng, không phải một lỗi.
Đó là cách bạn luôn bám sát thực tế thay vì chỉ phát hiện khoảng cách giữa kế hoạch và thực tế vào phút cuối.
Có một câu hỏi đáng để bạn suy ngẫm:
Lần gần nhất dự án phần mềm của bạn kết thúc đúng thời điểm dự kiến, đúng chi phí đã lên kế hoạch và tạo ra đúng sản phẩm mà bạn thực sự mong muốn là khi nào?
Nếu câu hỏi đó khiến bạn cảm thấy như đang nhớ về một điều rất xa xôi, vấn đề có thể không nằm ở nỗ lực của đội ngũ.
Có thể vấn đề nằm ở chính cấu trúc mà họ đang làm việc bên trong.
DevVina xây dựng mô hình triển khai dựa trên một niềm tin rằng: cấu trúc chính là đòn bẩy.
Hãy trao cho những người có năng lực một nhịp làm việc giúp phát hiện vấn đề sớm, giữ họ luôn gần với nhu cầu kinh doanh và cho phép họ trình diễn tiến độ thực tế sau mỗi hai tuần — khi đó, kết quả sẽ tự nhiên được cải thiện.
Đó là lời giới thiệu, và cũng là cách chúng tôi thực hành.
Không có những lời hứa lớn lao về một phép màu. Chỉ có một nhịp làm việc có thể lặp lại, biến việc phát triển phần mềm từ một canh bạc thành một quy trình mà bạn có thể chủ động điều hướng.
Sprint tiếp theo có thể bắt đầu bất cứ khi nào bạn sẵn sàng.
Sprint đầu tiên — sprint mà bạn có thể kiểm chứng xem nhịp làm việc này có phù hợp với cách bạn vận hành hay không — cũng là sprint có chi phí thấp nhất nhưng mang lại nhiều bài học nhất.
Trong hai tuần tới, bạn sẽ đưa sản phẩm nào ra mắt?
Hãy cho chúng tôi biết bạn đang xây dựng điều gì, và chúng tôi sẽ cho bạn thấy sprint đầu tiên có thể mang lại những gì.
#AgileDevelopment #ProjectManagement #SoftwareDelivery #DevVina
