Từ việc theo dõi đến các nỗ lực hack, kể từ khi tôi bắt đầu nghiên cứu của các dự án Agile và các sáng kiến chuyển đổi, tôi đã đối mặt với chủ nghĩa chính thống tồn tại trong số những người theo Agile nhiệt thành nhất. tỷ lệ thất bại cao Khi những bệnh nhân dễ bị tổn thương của một người chữa bệnh bằng đức tin không chống chọi được với căn bệnh do một phương pháp điều trị giả tạo không hiệu quả (thường đã 'quyên góp' một số tiền đáng kể), 'người chữa lành' thường sẽ cho rằng đó là lỗi của bệnh nhân vì họ đã không cầu nguyện chăm chỉ. đủ. Đây là một chủ đề đã được Derren Brown khám phá rất lâu trong chương trình truyền hình đặc biệt và được trình chiếu trong chương trình đặc biệt của Netflix. Ngụy biện như vậy thường được mô tả như một phiên bản của ngụy biện “ ” hoặc “ ”. Miracles for Sale Miracle Không có người Scotland thực sự lời kêu gọi sự thuần khiết Những người theo chủ nghĩa cơ bản trong cộng đồng Agile thường sử dụng những tuyên bố tương tự khi các dự án Agile thất bại. Ví dụ, trong bài viết “ ”, Greg Kihlstrom viết: Thất bại ở Agile? Bạn đang làm sai rồi Ví dụ: bạn có thể có Scrum Master nhiệt tình nhất có thể trong nhóm của mình, nhưng nếu nhóm sản phẩm có một số người phản đối hoặc những người chỉ đơn giản là không làm theo hoặc hiểu những gì cần phải hoàn thành, bạn sẽ gặp phải thách thức. Đôi khi đây là vấn đề về giáo dục hoặc huấn luyện, và đôi khi đây là vấn đề về động lực và văn hóa của nhóm. Xác định nguyên nhân là gì và giải quyết nó cho phù hợp. Tuy nhiên, cơ sở khoa học cho niềm tin như vậy không tồn tại. Một bài báo vào tháng 11 năm 2021 có tựa đề ' ' đã tiến hành phân tích tổng hợp nhiều đánh giá về các nghiên cứu khoa học về Agile và nhận thấy: “Kết quả của nghiên cứu cấp ba thực sự là bằng chứng cho Phương pháp linh hoạt là khan hiếm nhất.” “Thực tiễn tốt nhất” không có bằng chứng - Phương pháp phần mềm Agile làm ví dụ Tuy nhiên, đây không phải là thành kiến nhận thức duy nhất được những người có quan điểm chính thống áp dụng khi nói đến Agile. Trong bài viết này, tôi muốn tập trung vào những lý do thường được sử dụng để biện minh cho phương pháp Agile. Người rơm nhanh nhẹn là gì? Trên cộng đồng Agile của LinkedIn, không có gì lạ khi thấy những bài đăng như sau - dường như là một cuộc trò chuyện khiến một người thực hành Agile tỏ ra nhanh trí và biện minh cho phương pháp luận khi đối mặt với một kỹ sư phần mềm dám đặt câu hỏi về nó. Theo quan điểm cá nhân của tôi, những cuộc trò chuyện này nhìn chung có vẻ là hư cấu: Từ điển tiếng Anh Oxford cung cấp định nghĩa sau đây về người rơm: Trong một cuộc tranh luận, tranh luận, v.v.: một mệnh đề có chủ ý yếu kém hoặc bị trình bày sai, được thiết lập vì nó dễ bị đánh bại hơn hoặc làm chệch hướng sự chú ý khỏi lập luận thực sự của đối thủ, tạo ấn tượng hời hợt rằng cáo buộc ban đầu đã bị bác bỏ hoặc đánh bại . Tuy nhiên, có nhiều người có gốc rễ sâu xa hơn dường như đã đi thẳng vào trọng tâm của đề xuất Agile. Một bài viết trên trang web SecretGeek đưa ra câu hỏi: “ ”. Trong khi tác giả khẳng định rằng các yếu tố giáo điều khác của Agile thực sự đã có sẵn, từ nghi lễ đến học thuyết, thì một lĩnh vực mà họ băn khoăn là liệu có một 'huyền thoại' trong Agile hay không. 'Agile' có phải là một tôn giáo không? (hoặc chỉ đơn thuần là một giáo phái) Tôi tin rằng những người rơm này về cơ bản là những gì hình thành nên huyền thoại về Agile. Huyền thoại thác nước Thật khó để thấy Agile được thảo luận mà không thảo luận về Waterfall. Một phương pháp quản lý dự án được cho là trái ngược với Agile. Một phương pháp yêu cầu các bước được ghi chép chặt chẽ và không bao giờ thực hiện bất kỳ thay đổi nào. Tuy nhiên, điều này đặt ra câu hỏi, các hội nghị hoặc nhóm người dùng Waterfall ở đâu, thậm chí trong lịch sử? Có lẽ nguồn gốc của phương pháp này sẽ cung cấp cho chúng ta một số manh mối. Trong của Jon Pearce tại Đại học Bang San Jose, ông nói: “ ” bài giảng Mô hình Vòng đời Thác nước là con người rơm của các mô hình vòng đời. Nó được Wynn Royce mô tả lần đầu tiên vào năm 1970 như một ví dụ về một quy trình thiếu sót… Nhà phát triển phần mềm Christian Findlay đã đưa ra quan điểm tương tự trong : . một bài đăng trên X nêu rõ “Phương pháp tiếp cận thác nước giống như một người rơm chưa bao giờ thực sự tồn tại” Tuy nhiên, tình hình trở nên phức tạp hơn khi chúng ta đi sâu hơn vào lịch sử của Agile. Huyền thoại Toyota Hệ thống Sản xuất Toyota (TPS) là cái nôi tinh thần của phương pháp Agile. Mặc dù phần lớn các sáng kiến chuyển đổi đều thất bại nhưng nhiều người sẽ chỉ ra phương pháp mà Toyota đã sử dụng. Tuy nhiên, bản thân Toyota cũng có một lịch sử không mấy lý tưởng khi nói đến công nghệ phần mềm. Một , “Không thừa nhận trách nhiệm pháp lý, Toyota kể từ năm 2014 đã giải quyết 537 khiếu nại đổ lỗi cho việc tăng tốc đột ngột gây ra các vụ va chạm khiến nhiều người thiệt mạng hoặc bị thương nặng, theo tài liệu tòa án mà Toyota nộp” vào tháng 9 năm 2019. báo cáo trên tờ Capitol Weekly cho biết Những lỗi tăng tốc ngoài ý muốn này không chỉ gây tử vong trong nhiều trường hợp mà trong trường hợp của Koua Fong Lee, lỗi này không chỉ dẫn đến một vụ tai nạn ô tô khiến 3 người thiệt mạng và những người khác bị thương khi đang chở người vợ đang mang thai và các con từ nhà thờ về nhà mà còn dẫn đến việc khiến anh ta bị đổ lỗi và bị kết án tù. Trong quá trình tố tụng tại tòa, Toyota đã cố gắng phản bác lý thuyết tại sao chiếc xe hoạt động thất thường bằng những tuyên bố về các quy trình thử nghiệm nghiêm ngặt, nhưng ngay trước phiên tòa, Toyota đã đệ trình một tuyên bố từ kỹ sư đó rằng . công ty thực sự không thực hiện thử nghiệm như vậy Sau khi ra sẽ trả tự do cho anh ta nhưng lại khiến anh ta bị coi là tội phạm, Lee cuối cùng đã được trả tự do sau khi có lệnh xét xử lại và bên công tố từ chối đưa vụ việc trở lại tòa án. từ chối thực hiện một thỏa thuận nhận tội lẽ Trường hợp của Bookout V. Toyota đã khiến các hoạt động kỹ thuật phần mềm của Toyota trở nên tập trung sau khi một lỗi tăng tốc ngoài ý muốn khác dẫn đến tử vong. Trong quá trình tố tụng này, cuối cùng phát hiện ra rằng hệ thống phần mềm có thể gây ra hiện tượng tăng tốc ngoài ý muốn, bằng chứng đã được đưa ra, bao gồm cả thông tin liên lạc nội bộ trong Toyota nêu rõ “sự thật là, công nghệ như hệ thống an toàn dự phòng không phải là một phần DNA của bộ phận Kỹ thuật Toyota”: Sau trường hợp này, Toyota là đã áp dụng cách tiếp cận truyền thống về công nghệ phần mềm cho các dự án có độ tin cậy cao, sử dụng ngôn ngữ SPARK Ada trong đó các hợp đồng thiết kế nghiêm ngặt giúp xác minh về mặt toán học tính đúng đắn của phần mềm - một cách tiếp cận được áp dụng trong các môi trường có độ tin cậy cao như ngành hàng không. và phòng thủ. được cho Cách tiếp cận này, được gọi là “thiết kế theo hợp đồng”, ban đầu được phát minh bởi kỹ sư phần mềm người Pháp Bertrand Meyer, người đã viết cuốn sách “ ”. Trong số những lời chỉ trích của Meyer về Agile là việc không dùng thiết kế trả trước và tập trung vào câu chuyện của người dùng hơn là các thông số kỹ thuật khái quát. Agile!: The Good, the Hype and the Ugly Những lời chỉ trích này được mô tả chi tiết hơn trong video - “ ” của Edensoft Labs: The Ugly of Agile (with Dr. Bertrand Meyer) https://youtube.com/watch?v=Xi4WG-FVT6Q Phần kết luận Những người khác nhau trong Agile nhấn mạnh với chúng tôi tầm quan trọng mà tất cả chúng ta phải có trong việc phê phán trước khi áp dụng các giải pháp chưa chứng minh được tính hiệu quả của chúng. Đừng hiểu sai ý tôi, chúng ta không cần phân tích tổng hợp các đánh giá có hệ thống về các thử nghiệm đối chứng ngẫu nhiên để đưa ra mọi phán đoán trong cuộc sống, nhưng chúng ta nên cẩn thận khi loại bỏ bằng chứng về cơ sở bằng chứng cao hơn cơ sở bằng chứng thấp hơn ( chẳng hạn như những điều được các nhân vật có thẩm quyền trình bày cho chúng ta như là sự thật giáo điều). Là con người, những câu chuyện về sự biến đổi, bất chấp những khó khăn, vẫn lay động trái tim chúng ta và tất cả chúng ta đều muốn tin rằng có những siêu anh hùng có thể chữa lành vết thương cho mình. Tuy nhiên, sự hoài nghi mù quáng cũng thường có thể khiến chúng ta tự che chắn mình trước những tiến bộ giúp xã hội tiến bộ. Bằng cách tìm cách phớt lờ những khía cạnh cảm xúc này thay vì thừa nhận chúng, chúng ta thấy mình bị chúng thương xót nhiều hơn khi cố gắng đưa ra những quyết định hợp lý. Một trong những điều tôi thấy đáng chú ý nhất kể từ khi tôi viết cuốn sách “ ” là làm thế nào những người giáo điều nhất ở cả hai phía của sự phân chia quan điểm về Agile sẽ bỏ qua các khía cạnh cảm xúc và tâm lý thực sự hình thành nên phần lớn cuốn sách và những gì bằng chứng cho thấy đối với tôi nằm ở trung tâm của những sáng kiến chuyển đổi thực sự thành công. Kỹ thuật tác động: Chuyển đổi ngoài quản lý dự án Agile Điều này đưa ra một lời nhắc nhở rõ ràng rằng trước khi đi quá xa vào hố thỏ, chúng ta phải nhớ rằng bài học về khoa học và kỹ thuật là việc đặt câu hỏi về tính chính thống và thu thập bằng chứng là trọng tâm của những khám phá thực sự đáng chú ý.
