ĐỂ AGILE THẤT BẠI: 20 HƯỚNG DẪN GIÚP BẠN TRÁNH XA THÀNH CÔNG

ĐỂ AGILE THẤT BẠI: 20 HƯỚNG DẪN GIÚP BẠN TRÁNH XA THÀNH CÔNG Các vấn đề quản lý Các vấn đề nhóm Các vấn đề Product Owner Các vấn đề quy trình 10 Hiện nay, quy trình Agile chấp nhận giải pháp thay hiệu cho quy trình phát triển phần mềm truyền thống Hầu hết người áp dụng Agile thấy ích lợi việc chuyển giao nhanh hơn, chất lượng cao hơn, sản phẩm đáp ứng tốt nhu cầu người dùng, v.v Khơng phải tất người u thích Agile Nhiều người ngại với việc áp dụng Agile dù định từ sếp hay định tự phát người trẻ xông xáo muốn đổi Việc chuyển sang Agile thường xung đột với mục đích cá nhân giữ nguyên trạng, không muốn rủi ro nghề nghiệp, không muốn làm việc mức cần thiết, trì quyền lực hình thức báo cáo trực tiếp Bài viết gồm lời khuyên dành cho người vậy, người phải trở nên Agile không muốn Đừng lo Chúng không cố gắng dụ dỗ bạn dùng thử Agile, thuyết phục bạn lợi ích Agile hay nói cho bạn cách để thành cơng Không, giúp bạn đảm bảo Agile bị thất bại Sau bạn trở lại với vùng an tồn Dù có nhiều cách để phá hoại dự án Agile, để thuận tiện nhóm chúng lại thành bốn danh mục: vấn đề quản lý, vấn đề nhóm, vấn đề Product Owner vấn đề quy trình Trong danh mục, chúng tơi đưa ví dụ người làm cho Agile thất bại, đưa danh sách hướng dẫn chung cho thất bại mà ví dụ thể ra, danh sách kĩ thuật thay khác bạn thử để tái tạo lại thất bại Chúng hi vọng cách giúp bạn thất bại nhanh tránh thành công tiềm ẩn CÁC VẤN ĐỀ QUẢN LÝ Drew thấy trào lưu quản lý đến Trong suy nghĩ Drew, Agile Là người học nhanh, anh đọc vài sách chí cịn học lớp Agile Anh không tin Agile, người có tinh thần đồng đội, anh có nghĩa vụ phải thử Agile lần Drew chọn thành viên cho nhóm yêu cầu họ “hãy Agile” Drew yêu cầu nhóm cần họp hàng ngày, ước lượng cơng việc, tháng làm phiên sản phẩm (một công cụ sở liệu để lưu trữ tác phẩm nghệ thuật) Bởi Drew khơng tin Agile khả nhóm, tham gia tất phiên Scrum Hằng ngày, để ý điều nhóm làm đúng, điều làm sai Cuộc họp hàng ngày nhanh chóng trở thành phiên mẫu mực để sửa lỗi cách làm ngơn từ Do đó, khơng nói vấn đề - đặc biệt trước mặt Drew Drew thành công làm theo hướng dẫn để làm Agile thất bại HƯỚNG DẪN 1: Đừng tin vào nhóm hay Agile Hãy quản lý vi mơ tất thành viên nhóm quy trình Khơng ngồi dự đốn người, nhóm khơng tạo kết ấn tượng Nhóm không đạt mục tiêu phân đoạn không suất trước Drew tổ chức buổi Cải tiến mà khơng tìm thấy vấn đề sửa Kết Drew quẳng hết sách mà đọc Agile bảo nhóm quay lại cách cũ để phát triển dự án Drew làm theo hướng dẫn số HƯỚNG DẪN 2: Nếu Agile viên đạn bạc, đổ lỗi cho Agile Trong Drew quản lý vi mơ nhóm cách cực đoan, có cách cực đoan ngược lại khơng hướng dẫn nhóm chút Nhớ rằng: dù nhóm Agile tự tổ chức đồng thời tự quản lý, họ không tự lãnh đạo Một nhóm Agile cần kiểu lãnh đạo đưa tầm nhìn động lực để đạt tầm nhìn Một lãnh đạo Agile giỏi, thường Product Owner, biết cách tạo động lực cho nhóm cách miêu tả sản phẩm đáng mơ ước vượt qua tưởng tượng nhóm Khi nhóm tự theo đuổi mục tiêu đồng thời liên tục Product Owner định hướng, nhóm Agile đạt suất siêu cao Đừng để nhóm có hội đó! Nếu quản lý vi mô kiểu bạn, làm theo hướng dẫn số HƯỚNG DẪN 3: Đánh đồng tự quản lý với tự lãnh đạo khơng dẫn nhóm điều Dù cấp cao công ty ủng hộ, việc áp dụng Agile thường nhóm Agile tự triển khai Đừng lo Bạn có nhiều hội để làm cho Agile thất bại, đặc biệt bạn quản lý Bạn bắt đầu cách ngầm phá hoại người tiên phong nhóm - người đọc tất sách Agile tận dụng hội để quảng bá cho Agile Bỏ qua tất quy tắc mà yêu cầu bạn tuân theo Gián đoạn Scrum Hằng ngày với thị Thay đổi thứ tự ưu tiên mục tiêu phân đoạn Những việc thực làm theo hướng dẫn số HƯỚNG DẪN 4: Phớt lờ quy tắc Agile Chúng không áp dụng cho việc quản lý Nếu bạn muốn đảm bảo Agile khơng bén rễ cơng ty, nói thẳng với thành viên nhóm Agile bạn nghĩ Agile trào lưu Vài người từ đầu hồi nghi rồi, khơng tốn nhiều cơng sức để thuyết phục họ phớt lờ kĩ thuật Agile Nhớ rằng, giống Barney Fife, bạn có quyền lực để diệt Agile từ trứng nước Chỉ cần làm theo hướng dẫn số HƯỚNG DẪN 5: Ngầm phá hoại niềm tin nhóm Agile CÁC VẤN ĐỀ VỀ NHĨM Khơng phải tất quản lý Đừng lo, dù quản lý tạo ảnh hưởng phá hoại nhóm Hãy xem trường hợp nhóm Agile NotQuite, giao phát triển phần mềm quản lý kho hàng Nhóm cho thấy sức mạnh tính kiên định việc làm đổ bể dự án phần mềm Trong phân đoạn đầu tiên, NotQuite cam kết hoàn thành hạng mục Product backlog; nhóm hồn thành Vì phân đoạn đầu tiên, hầu hết người cam kết nhiều, nên Product Owner không trích nhóm nhiều Điều khơng làm nhóm NotQuite lo lắng Đến phân đoạn thứ hai, nhóm lên kế hoạch hồn thành hạng mục; nhóm hồn thành Sự cải tiến nhẹ ru ngủ Product Owner vào cảm giác an toàn giả tạo NotQuite tiếp tục cam kết sức, chậm tiến độ phân đoạn thứ 3, 4, Product Owner sớm thấy khơng thể tin nhóm, điều ngầm phá hủy khả thành cơng Agile Đây trường hợp tuyệt vời làm theo hướng dẫn số HƯỚNG DẪN 6: Liên tục không chuyển giao điều bạn cam kết lập kế hoạch cho phân đoạn Khi chậm tiến độ, đừng mắc sai lầm làm phân đoạn, lần kiệt sức đến ngày cuối Một nhóm ln tha thứ dù không chuyển giao kế hoạch Lý sai lầm NotQuite thái độ ung dung với cam kết khơng đạt Thành viên nhóm tỏ rõ việc hồn thành cơng việc ngày cam kết hay chậm vài ngày việc bình thường Bạn bè với vài ngày có gì? Nhớ rằng, vài ngày nhiều lần gộp lại thành nhiều Nếu nhóm Agile liên tục khơng thực cam kết, Product Owner lập kế hoạch cam kết với bên ngồi Điều dẫn tới hướng dẫn số để làm Agile thất bại HƯỚNG DẪN 7: Thoải mái lùi công việc từ phân đoạn sang phân đoạn khác khiến cho Product Owner phải đốn xem chuyển giao Có lẽ cách tốt làm cho dự án Agile thất bại làm theo hướng dẫn số HƯỚNG DẪN 8: Đừng lập nhóm liên chức Hãy để tất kiểm thử viên vào nhóm, tất lập trình viên vào nhóm khác, v.v Merrilynn dùng hướng dẫn để hủy diệt dự án thử nghiệm Agile cơng ty Đó dự án phát triển chương trình có hai ứng dụng máy khách(client) tách riêng cho Windows Web Là giám đốc phát triển, Merrilynn có quyền chia nhóm tạo ba nhóm riêng biệt: nhóm Windows, nhóm Web, nhóm kiểm thử Cấu trúc nhóm trái ngược với mục tiêu Agile Nếu Merrilynn muốn thành công, cô lẽ phải tạo ba nhóm mà nhóm có người với đủ kĩ Windows, Web kiểm thử Bởi Merrilynn tách riêng nhóm, khiến cho nhóm khơng thể chuyển giao phần mềm hoàn chỉnh mà nhóm Agile chuyển giao cuối phân đoạn Giỏi đấy, Merrilynn Một lựa chọn khác cho Merrilynn đặt tồn 20 người vào nhóm Điều trái với lời khuyên chuẩn Agile nhóm có từ đến người Cơ giải thích với người thắc mắc định cách nhấn mạnh vào tính ứng dụng máy khách sản phẩm nhóm Nếu chọn cách tạo nhóm lớn thay nhóm cỡ hợp lý, Merrilynn khiến tốn nhiều thời gian dành cho giao tiếp nhóm Làm cho tiến độ bị chậm lại khiến người phàn nàn việc giao tiếp Agile gánh nặng khổng lồ Nếu phân tách nhóm khó để giải thích, bạn cản trở dự án dễ dàng hướng dẫn số HƯỚNG DẪN 9: Dự án lớn cần nhóm lớn Mặc kệ nghiên cứu nói suất nhóm lớn bị giảm thời gian cho giao tiếp tăng lên Bởi người cần biết thứ, mời tất 50 người tham gia phiên họp đứng hàng ngày CÁC VẤN ĐỀ VỀ PRODUCT OWNER Như bạn thấy, Product Owner dễ dàng làm cho Agile thất bại cách giao tiếp sai lệch, khơng quan tâm đến tiến độ nhóm, thiếu đào tạo Nếu bạn làm hướng dẫn nhóm quản lý, bạn theo làm theo hướng dẫn cho Product Owner Một Product Owner có nhiều lựa chọn thẩm quyền để đẩy dự án Agile đến bờ vực Hãy xem ví dụ Kathy, Product Owner nhóm làm video game Nhóm đạt tiến độ tuyệt vời qua phân đoạn(Sprint) lần có thêm niềm vui cho người chơi Kathy để thành viên nhóm nghĩ tất họ cần làm Cô không tham gia buổi Sơ kết, dùng thử trò chơi, đặt story đẩy trò chơi theo hướng mà cô tưởng tượng Nếu chưa đủ, Kathy khơng chia sẻ tầm nhìn với nhóm với khách hàng mà có trách nhiệm báo cáo (ví dụ bên marketing) Sau năm phát triển, trị chơi trình diễn cho nhóm điều hành làm họ choáng váng hướng phát triển trị chơi Đó khơng phải điều họ muốn đưa thị trường Liên kết rời rạc Kathy, nhóm quản lý cấp cao làm cho dự án chậm tiến độ tháng Làm tốt lắm, Kathy! Kathy minh họa cho vài hướng dẫn làm thất bại dự án Agile tay Product Owner HƯỚNG DẪN 10: Đừng giao tiếp tầm nhìn sản phẩm cho nhóm Agile hay bên liên quan khác HƯỚNG DẪN 11: Đừng quan tâm đến tiến độ phân đoạn đánh giá khách quan tiến độ chung HƯỚNG DẪN 12: Thay tài liệu kế hoạch kế hoạch “trong đầu bạn” mà bạn biết Một nguyên lý phát triển theo phân đoạn lặp thấy chức đóng góp giá trị tồn hệ thống Đây lý phân đoạn tạo phiên phát hành sản phẩm Điều tương phản hoàn toàn với dự án phát triển theo kế hoạch cố định, nguồn lực tính tốn để tạo sản phẩm kết thúc kế hoạch Khi Product Owner không thay đổi cách làm đó, nhóm Agile nhanh chóng thất bại Việc đào tạo Product Owner quan trọng đào tạo nhóm Nói chung, bạn muốn đảm bảo Agile thất bại nhanh chóng, tránh xa hồn tồn khỏi đào tạo Vai ác Product Owner thường cân ScrumMaster huấn luyện viên nhóm Trong dự án thành cơng, ln có căng thẳng định Product Owner ScrumMaster Một Product Owner muốn thêm nhiều chức Ngược lại, huấn luyện viên có trách nhiệm theo dõi sức khỏe nhóm Nếu nhóm bị ép mức bắt đầu uể oải mệt, huấn luyện viên đẩy lui mong muốn nhiều Product Owner Một cách tốt để làm Agile thất bại loại bỏ sức ép kéo-đẩy huấn luyện viên Product Owner theo hướng dẫn số 13 HƯỚNG DẪN 13: Để người làm vai trò ScrumMaster (Agile coach) Product Owner Thực tế, người làm thành viên nhóm phát triển Như bạn thấy, Product Owner dễ làm cho Agile thất bại cách giao tiếp lỗi, không để ý đến tiến độ nhóm, chưa đào tạo Nếu cần bạn gộp điều lại cách để người đồng thời làm vai trò vốn thiết kế để cân lẫn Làm xác theo hướng dẫn cách tuyệt vời để thất bại CÁC VẤN ĐỀ VỀ QUY TRÌNH Thay điều chỉnh linh hoạt lương, thưởng, chức vụ, thăng tiến theo Agile, thưởng cho cá nhân để ngầm phá hoại tinh thần làm việc nhóm chịu trách nhiệm chung Nếu cách không thành công, xử lý sai vấn đề qui trình làm thất bại hầu hết dự án Agile Jon ví dụ kinh hồng ác mộng qui trình, tạo phá hoại lớn mà khơng biết ngun nhân Jon trưởng nhóm lập trình nhóm Chicago phát triển phần mềm để chấp nhận hay từ chối khoản vay Ngoài việc làm trưởng nhóm, cịn làm ScrumMaster (hãy xem lại hướng dẫn 13, riêng điều gây thảm họa) Nhóm Jon áp dụng Agile nơn nóng muốn bỏ bớt phần khơng cần thiết Nhóm hủy bỏ họp đứng hàng ngày, lấy lý nhóm ngồi khu vực, người nghe hầu hết nói chuyện qua vách ngăn 1,8m Họ định kiểm thử đơn vị tự động không cần thiết Bởi họ làm chương trình mới, khơng có code cũ làm hỏng, người để ý code nên khả làm hỏng code Tuy nhiên, Jon đồng nghiệp áp dụng tái cấu trúc sở hữu tập thể mã nguồn Họ đặt qui tắc thay đổi code người khác lúc Họ sớm nhận việc tái cấu trúc sở hữu tập thể mã nguồn nguy hiểm khơng có lưới an tồn kiểm thử đơn vị tự động để đảm bảo bạn khơng làm hỏng điều cải tiến mã Jon nhóm vơ tình làm theo hai hướng dẫn làm cho Agile thất bại HƯỚNG DẪN 14: Tùy chỉnh qui trình Agile trước hồn tồn tn thủ qui trình HƯỚNG DẪN 15: Bỏ qua tùy chỉnh kĩ thuật Agile quan trọng trước hoàn toàn hiểu rõ chúng Một cách thay cho hướng dẫn áp dụng kĩ thuật mà không hiểu phải làm Là huấn luyện viên, gặp nhiều nhóm học/làm kĩ thuật người khác yêu cầu người tiếp tục làm kĩ thuật dù họ khơng cần Điều làm ta nhớ đến câu chuyện nàng dâu phải cắt hai đầu tất miếng thịt trước cho vào chảo mà phải làm Khi người chồng hỏi cô tỉa miếng thịt vậy, khơng có câu trả lời; làm cách mẹ làm Tị mị thói quen mẹ mình, vợ gọi điện hỏi bà lại dạy cô cắt phần đuôi miếng thịt Mẹ cô bảo bà cô dạy Cô vợ trẻ lại gọi bà hỏi bà lại cắt phần đuôi miếng thịt Bà nói với cơ: “Bởi chảo rán thịt bà nhỏ Miếng thịt không vừa” Câu chuyện tương tự với hướng dẫn làm Agile thất bại HƯỚNG DẪN 16: Mù quáng làm theo kĩ thuật Agile mà không hiểu rõ ngun lý phía Nếu bạn khơng thể thực hướng dẫn từ 14 đến 16 dự án Agile bạn thành công dù bạn cố gắng, bạn làm ngừng dự án thành cơng cách khơng thay đổi Gì cơ? Khơng thay đổi cả? Theo dõi ví dụ nhóm StatusQ StatusQ có nhiệm vụ phát triển hệ thống đặt chỗ tảng web, có khởi đầu tốt đẹp Các thành viên nhóm làm quen với Agile nghiên cứu kĩ chí cịn gửi vài người học để trở thành ScrumMaster có chứng Dự án nhanh đạt lợi ích từ phương pháp Trong tháng, StatusQ chạy trang web đơn giản trình diễn vài giao diện khiến cho khách hàng tự tin có hệ thống đặt chỗ mạnh mẽ tiện dụng tương lai StatusQ không tổ chức buổi Cải tiến kết thúc Sprint ScrumMaster không ép người thực Cải tiến khơng thấy cần phải làm Mọi thứ diễn tốt đẹp Bạn khuyến khích việc cách lớn tiếng phàn nàn ScrumMaster thành viên nhóm họ cố tổ chức buổi Cải tiến Bảo họ việc ngồi để bàn dự án chạy tốt việc lãng phí thời gian Bảo họ buổi Cải tiến cần thiết có vấn đề khơng ổn xảy Dần dần, cơng việc StatusQ bắt đầu chậm lại Tốc độ phát triển lượng mã lớn dần tạo vấn đề bảo trì Mã nguồn khơng theo kịp yêu cầu thay đổi từ khách hàng Mã trở nên ổn định dự án dường lùi Cuối ban quản lý công ty định dừng phát triển dự án kết thúc hợp đồng với nửa giá Nhóm StatusQ vơ tình minh họa cho hai hướng dẫn làm Agile thất bại HƯỚNG DẪN 17: Đừng cải tiến liên tục HƯỚNG DẪN 18: Đừng thay đổi kĩ thuật thực hành Các vấn đề qui trình cơng ty dường khơng liên quan đến dự án lại tạo ảnh hưởng xấu đến tinh thần động lực Hãy xem xét trường hợp Dave, nghệ sĩ tháo vát làm việc cho công ty phát triển game di động Anh hào hứng cơng ty áp dụng Agile anh thích Agile Nhóm Agile gồm lập trình viên, nghệ sĩ, nhà thiết kế số người với chuyên ngành khác Mọi người dựa vào làm việc để hoàn thành phân đoạn phát triển game Nếu người nghệ sĩ làm tốt nhóm tốt Dave thường dừng việc làm để giúp đồng đội hoàn thiện phần nghệ thuật game Tuy khiến cho việc bị ảnh hưởng, với Dave, mục tiêu nhóm ưu tiên hàng đầu Nhóm Dave hồn thành xuất sắc cơng việc làm tựa game đình đám bán hàng nghìn giúp cơng ty kiếm lợi nhuận lớn Đến cuối năm, Dave tham gia buổi đánh giá lực với trưởng ban nghệ thuật công ty Dave choáng váng biết tiền thưởng cuối năm Dave thơng báo nghệ sĩ cấp cao đánh giá Dave không đạt mục tiêu sản phẩm nghệ thuật Hóa ra, người nghệ sĩ cấp cao đếm số thẻ tác vụ mà Dave hoàn thành phân đoạn để đánh giá lực thay lượng cơng việc thực tế mà Dave hồn thành Thất vọng, Dave trở lại nhóm thề đảm bảo cơng việc ưu tiên nhu cầu nhóm Bạn dùng hướng dẫn 19 làm kế hoạch dự phòng để đối phó với người nhiệt huyết với Agile cơng ty HƯỚNG DẪN 19: Thay điều chỉnh linh hoạt lương, thưởng, chức vụ, thăng tiến theo Agile, thưởng cho cá nhân để ngầm phá hoại tinh thần làm việc nhóm chịu trách nhiệm chung Một nguyên lý chia sẻ tất qui trình Agile cơng việc ưu tiên dựa giá trị chức Những yếu tố khác rủi ro kiến tạo tri thức xem xét, lượng giá trị chuyển giao yếu tố định Một cách chắn để đảm bảo Agile thất bại phớt lờ nguyên lý làm theo hướng dẫn số 20 HƯỚNG DẪN 20: Thuyết phục thân bạn làm tất cơng việc u cầu, thứ tự cơng việc khơng quan trọng Tất nhiên có cách khác để thất bại 20 cách Khi bạn cố gắng ngầm phá hoại dự án Agile, có lẽ bạn khám phá vài cách riêng Tất nhiên bạn giữ riêng cho âm mưu phá hoại khơng thể bị tiết lộ trước hồn thành Chúng tơi tự tin chịu khó áp dụng hướng dẫn kết hợp với điều bạn biết, bạn từ từ làm dự án Agile tới sụp đổ đảm bảo Agile thất bại Nguồn: Mountain Goat Software Người dịch: Nguyễn Trung Tuyến