Ken Schwaber, cha đẻ của Scrum: Agile là một sự tiến hóa của sự sống còn dành cho những người mạnh nhất (Phỏng vấn Turing)

Ken Schwaber, cha đẻ của Scrum: Agile là một sự tiến hóa của sự sống còn dành cho những người mạnh nhất (Phỏng vấn Turing)

Tôi tình cờ tìm thấy một cuộc phỏng vấn về Ken Schwaber, (cha đẻ của Scrum) tại Trung Quốc do Turing tổ chức. Tôi nghĩ nó cũng có thể áp dụng được cho phần lớn người châu Á về việc liệu Scrum có phù hợp để triển khai tại Trung Quốc (hoặc các nước châu Á). Dưới đây là bản dịch tiếng Anh như sau:

Ken Schwaber là một trong những người lãnh đạo trong phong trào phát triển phần mềm linh hoạt. Ông cũng là một nhà phát triển, quản lý sản phẩm và chuyên gia tư vấn ngành. Ken và Jeff Sutherland (Giám đốc điều hành Scrum Boston) đã cùng nhau xây dựng phiên bản ban đầu của phương pháp phát triển Scrum, và tại hội nghị thường niên OOPSLA năm 1995, họ đã nộp Scrum như một phương pháp chính thức lần đầu tiên. Schwaber và Sutherland là một trong những người ký tên ban đầu vào Tuyên ngôn Agile. Họ là tác giả của cuốn Sách hướng dẫn Scrum uy tín. Hiện nay Schwaber phụ trách Scrum.org, nơi cung cấp tài nguyên, đào tạo, đánh giá và chứng nhận Scrum cho các ‘Master Scrum’, ‘Nhà phát triển Scrum’, ‘Chủ sở hữu sản phẩm Scrum’ và các tổ chức đang sử dụng Scrum.

Cộng đồng Turing: Động lực ban đầu của bạn khi xây dựng một Scrum?

Schwaber: Vì Scrum hoạt động hiệu quả. Vào thời điểm đó, công ty tôi đang bận rộn cung cấp một sản phẩm cao cấp, thị trường cho sản phẩm này đang bùng nổ và cần những thay đổi liên tục. Nếu chúng tôi áp dụng chu kỳ phát triển dài, công ty tôi sẽ phá sản. Vì vậy, chúng tôi đã thiết kế Scrum, giúp chúng tôi được tái sinh như cõi tiên.

Cộng đồng Turing: Bạn có nghĩ rằng việc thúc đẩy Scrum tại Trung Quốc gặp rào cản văn hóa không?

Schwaber: Không khó hơn bất kỳ nền văn hóa nào khác. Yếu tố then chốt để một nền văn hóa có thể chấp nhận và sử dụng Scrum là mức độ tin tưởng vào tính dự đoán được.

Những người hiểu và chấp nhận tính dự đoán được trong văn hóa sẽ tin rằng họ có thể dự đoán tương lai. Mục đích công việc của họ là biến tương lai thành hiện thực thực tế bằng cách sử dụng con người và nguồn lực.

Những người sử dụng Scrum đã có quan điểm này, và tính phức tạp cũng như sự sáng tạo trong phát triển phần mềm là không thể dự đoán được. Kết quả là rất tệ: phần mềm kém chất lượng, không theo kịp tiến độ, lãng phí tiền bạc và nhân viên nản lòng. Vì vậy, họ hiểu rằng điều quan trọng nhất là dự đoán được nhu cầu thực sự, giúp nhân viên nhận thức được điều đó, rồi làm mọi thứ có thể để hỗ trợ mọi người đạt được mục tiêu này. Cốt lõi của con đường Scrum là ‘có việc để làm’, tận dụng cơ hội, tránh né rào cản và trở nên linh hoạt.

Cộng đồng Turing: Những người thường than phiền về sự khó khăn khi từ bỏ mô hình thác nước. Bạn có nghĩ rằng cần kết hợp mô hình Agile và mô hình thác nước không? Vì sao? Làm thế nào nếu có thể?

Schwaber: Hai mô hình này phù hợp với hai tình huống hoàn toàn khác nhau.

Đối với mô hình thác nước, chúng tôi dự đoán điều chúng tôi sẽ xây dựng, cách thức xây dựng, lập kế hoạch, rồi tuân theo tiến độ. Yếu tố then chốt là xác định chính xác mức độ chính xác mong muốn và độ chính xác trong giao tiếp hiệu quả cho đến khi sản phẩm cuối cùng được hình thành. Nếu liên kết giao tiếp hoàn hảo và không cần thay đổi, thì việc làm như vậy là khả thi.

Giả định của Scrum là giao tiếp có vấn đề, và thay đổi là điều không thể tránh khỏi. Trong một khoảng thời gian ngắn không quá 30 ngày, con người sẽ xây dựng những gì họ nghĩ là mong muốn cuối cùng. Điều này sẽ được kiểm tra vào cuối chu kỳ. Dựa trên mức độ hài hòa giữa kết quả và nhu cầu, chúng ta phải lập kế hoạch cho chu kỳ tiếp theo. Đây là một vòng phản hồi liên tục đang thay đổi, thực hiện thay đổi dựa trên kết quả kiểm tra và sự thay đổi trong nhu cầu.

Một số người đã thử kết hợp hai phương pháp này, và kết quả là thất vọng và vô nghĩa. Tốt hơn hết là nên tách biệt.

Cộng đồng Turing: Làm sao một công ty biết được Scrum có phù hợp với doanh nghiệp và sản phẩm của họ không?

Schwaber: Scrum gần như không bao giờ phù hợp với văn hóa doanh nghiệp của một số công ty phần mềm đang chịu áp lực do mô hình thác nước không phù hợp, và họ đã sử dụng công nghệ nhàm chán trong suốt 30 năm qua.

Scrum lại phù hợp với một số văn hóa doanh nghiệp, bắt chước chu kỳ bán hàng cho dự báo hàng năm, sau đó chuyển đổi dự báo hàng năm thành dự báo hàng tháng, rồi kiểm tra kết quả và thực hiện những thay đổi phù hợp.

Hầu hết các công ty đều không hài lòng với các bộ phận phát triển phần mềm cho họ, vì lãng phí, thất bại và chất lượng kém không phải là điều hiếm gặp. Những người cực kỳ tuyệt vọng hoặc có tầm nhìn sẽ cố gắng chuyển sang Scrum, một cách tiếp cận phù hợp hơn để phản ánh cách hoạt động của phần còn lại của công ty.

Cộng đồng Turing:Trong phát triển thực tế, một số công ty bị ám ảnh bởi các phương pháp cứng nhắc và sẽ không điều chỉnh các phương pháp này cho môi trường riêng của họ. Bạn nghĩ gì về những công ty này? Bạn có đề xuất gì cho họ không?

Schwaber:Sự phát triển nhanh chóng của phần mềm đã trở thành chìa khóa để công ty tồn tại, không chỉ về cách công ty vận hành, mà còn về phần mềm được tích hợp vào sản phẩm của họ. Các công ty không tiến hóa, các công ty không áp dụng các phương pháp linh hoạt trong phát triển phần mềm và sản phẩm, sẽ không thể cạnh tranh và tồn tại.

Lời khuyên của tôi là phương pháp linh hoạt là một sự tiến hóa của sự sống sót dành cho những cá thể thích nghi tốt nhất.

Cộng đồng Turing:Người sở hữu sản phẩm có rất nhiều trách nhiệm. Đôi khi, họ sẽ trở thành nút thắt cổ chai của cả đội. Làm thế nào để giải quyết vấn đề này?

Schwaber:Vấn đề này thực sự tồn tại. Vì vậy, chúng ta phải giải quyết nó. Có rất nhiều cách để giải quyết vấn đề này, bao gồm việc bổ sung thêm kiến thức chuyên môn cho đội. Nếu đội không có kiến thức chuyên môn, thì người sở hữu sản phẩm sẽ không tồn tại, và tôi đoán toàn bộ quá trình phát triển sẽ chậm lại cho đến khi vấn đề được giải quyết. Ngược lại, bạn sẽ phải chờ đến khi phát hành một sản phẩm kém chất lượng.

Cộng đồng Turing: NhữngPhương pháp Pomodoro là một cách để cải thiện hiệu suất cá nhân. Bạn có thể sử dụng phương pháp Pomodoro trong Scrum không?

Schwaber:Nếu bạn muốn, Scrum là một khung khổ có thể được tích hợp vào phương pháp Pomodoro. Tuy nhiên, áp dụng mù quáng bất kỳ kỹ thuật nào mà không điều chỉnh sẽ gây hại.

Cộng đồng Turing:Làm thế nào để kiểm soát và quản lý các khoản nợ công nghệ?

Schwaber:Khi bạn viết từng tính năng, hãy giả định rằng bạn sẽ duy trì và nâng cấp tính năng này suốt đời. Ngay cả khi bạn muốn bắt đầu với một chương trình cũ đã rữa nát trong xương thịt, hãy làm điều đó. Ngược lại, ngân sách phát triển dùng để duy trì và hỗ trợ các sản phẩm cũ sẽ tiêu hết toàn bộ chi phí cho công việc mới.

Cộng đồng Turing:Bạn có nghĩ rằng các phương pháp linh hoạt quá nhấn mạnh YAGNI (bạn sẽ không cần nó)? Điều này có dẫn đến việc bỏ qua các mục tiêu dài hạn không?

Schwaber:Các phương pháp linh hoạt không bao gồm YAGNI. Nhưng linh hoạt cần phải dọn dẹp những thứ không cần thiết. Ví dụ, tại sao phải trao đổi với người khác khi đã có tài liệu ghi chép, thay vì nói trực tiếp với họ? Dù sao đi nữa, tài liệu cần thiết để duy trì sản phẩm cần phải phát triển qua mỗi chu kỳ. Làm những điều hữu ích và cần thiết, loại bỏ tất cả những thứ còn lại.

Cộng đồng Turing:Một số người cho rằng các phương pháp linh hoạt đang đi xuống. Theo bạn, tại sao lại có những ý kiến như vậy? Quan điểm của bạn là gì?

Schwaber:Tôi đã nghe nhiều người hỏi, liệu tính linh hoạt có phải là một trào lưu không? Tôi nghĩ rằng linh hoạt là một tập hợp các giá trị và nguyên tắc. Mặc dù Scrum được xây dựng trên nền tảng linh hoạt, nhưng Scrum được xây dựng trênsự tập trung, dũng cảm, cởi mở, cam kết và sự tôn trọngnhững giá trị này.

Các giá trị không phải là trào lưu. Theo tôi, những người làm việc theo các giá trị và nguyên tắc này sẽ trở thành xu hướng, và phương pháp của họ vượt xa các phương pháp khác, hay thậm chí là các trào lưu.

Cộng đồng Turing:Bạn nhìn nhận phe Agile như thế nào? Bạn có nghĩ rằng giữa họ có những mâu thuẫn và mâu thuẫn không? Những khác biệt của họ bắt nguồn từ đâu?

Schwaber:Agile và Scrum là những phương pháp rất, rất đơn giản. Những khác biệt và mâu thuẫn xuất phát từ các tổ chức muốn kiếm tiền bằng cách tạo ra công cụ, phương pháp và phát triển các phương pháp mới dựa trên ý tưởng Agile. Khi tiền bạc tham gia vào một đầu của phương trình, mâu thuẫn sẽ xảy ra. Những mâu thuẫn này không phải là điều tất yếu. Hãy dùng mắt mình để chọn một phương pháp phù hợp với bạn. Thử nghiệm và tiếp tục cải tiến.