ĐỂ 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 đề về Product Owner 8 Các vấn đề về quy trình 10 Hiện nay, các quy trình Agile đã được chấp nhận là những giải pháp

ĐỂ 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 đề về Product Owner 8

Các vấn đề về quy trình 10

Hiện nay, các quy trình Agile đã được chấp nhận là những giải pháp thay thế hiệu quả cho các quy trình phát triển phần mềm truyền thống Hầu hết những người áp dụng Agile đã thấy được những ích lợi của việc chuyển giao nhanh hơn, chất lượng cao hơn, sản phẩm đáp ứng tốt hơn nhu cầu người dùng, v.v

Không phải tất cả mọi người đều yêu thích Agile Nhiều người vẫn ái ngại với việc áp dụng Agile dù đó là quyết định từ các sếp hay quyết định tự phát của những người trẻ xông xáo muốn đổi mới Việc chuyển sang Agile thường xung đột với các mục đích cá nhân như giữ nguyên hiện trạng, không muốn rủi ro nghề nghiệp, không muốn làm việc quá mức cần thiết, hoặc duy trì quyền lực dưới hình thức báo cáo trực tiếp

Bài viết này gồm những lời khuyên dành cho những người như vậy, những người phải trở nên Agile nhưng không muốn Đừng lo Chúng

tôi sẽ không cố gắng dụ dỗ bạn dùng thử Agile, thuyết phục bạn về những lợi ích của Agile hay nói cho bạn cách để thành công Không, chúng tôi sẽ giúp bạn đảm bảo Agile bị thất bại Sau đó bạn có thể trở lại với vùng an toàn của mình

Dù có nhiều cách để phá hoại một dự án Agile, để thuận tiện chúng ta

sẽ nhóm chúng lại thành bốn danh mục: các vấn đề về quản lý, vấn đề

về nhóm, vấn đề về Product Owner và các vấn đề về quy trình Trong mỗi danh mục, chúng tôi sẽ đưa ra một ví dụ về người đã làm cho Agile thất bại, đưa ra danh sách các hướng dẫn chung cho thất bại mà

ví dụ đã thể hiện ra, và danh sách những kĩ thuật thay thế khác bạn

có thể thử để tái tạo lại thất bại đó Chúng tôi hi vọng cách này sẽ giúp bạn thất bại nhanh hơn và tránh được những thành công tiềm ẩn

CÁC VẤN ĐỀ QUẢN LÝ

Drew đã thấy các trào lưu quản lý đến và đi Trong suy nghĩ của Drew, Agile cũng vậy Là một người học nhanh, anh đã đọc vài cuốn sách và thậm chí còn học một lớp về Agile Anh không tin Agile, nhưng là người có tinh thần đồng đội, anh có nghĩa vụ phải thử Agile một lần

Drew chọn các thành viên cho nhóm và 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, và mỗi tháng làm ra được một phiên bản của sản phẩm (một công cụ cơ sở dữ liệu

để lưu trữ tác phẩm nghệ thuật)

Bởi vì Drew không tin Agile và khả năng của nhóm, anh ta tham gia tất cả các phiên Scrum Hằng ngày, hết sức để ý và chỉ ra điều gì nhóm làm đúng, điều gì làm sai Cuộc họp hàng ngày nhanh chóng trở thành một phiên bản mẫu mực để sửa lỗi về cách làm và ngôn từ Do đó,

không ai nói về các vấn đề - đặc biệt là trước mặt Drew Drew đã thành công làm theo hướng dẫn đầu tiên để làm Agile thất bại của chúng tôi

HƯỚNG DẪN 1: Đừng tin vào nhóm hay Agile Hãy quản lý vi mô tất cả thành viên nhóm và quy trình.

Không ngoài dự đoán của mọi người, nhóm không tạo ra được những kết quả

ấn tượng Nhóm không đạt được các mục tiêu phân đoạn và không năng suất hơn trước kia Drew tổ chức các buổi Cải tiến

mà không tìm thấy vấn đề nào anh ta có thể sửa được Kết quả là Drew quẳng hết sách mà anh ta đã đọc về Agile đi và bảo nhóm quay lại cách cũ để phát triển dự án Drew đang làm theo hướng dẫn số 2

HƯỚNG DẪN 2: Nếu Agile không phải là viên đạn bạc, hãy đổ lỗi

cho Agile

Trong khi Drew quản lý vi mô nhóm một cách cực đoan, có một cách cực đoan ngược lại là không hướng dẫn nhóm một chút nào Nhớ rằng: dù nhóm Agile tự tổ chức đồng thời cũng tự quản lý, họ không tự lãnh đạo Một nhóm Agile cần kiểu lãnh đạo đưa ra được tầm nhìn và động lực để đạt được tầm nhìn đó Một lãnh đạo Agile giỏi, thường là một Product Owner, sẽ biết cách tạo động lực cho nhóm bằng cách miêu tả về một sản phẩm cực kỳ đáng mơ ước vượt qua tưởng tượng của nhóm Khi nhóm tự mình theo đuổi mục tiêu đó đồng thời liên tục được Product Owner định hướng, nhóm Agile có

thể đạt được năng suất siêu cao Đừng để nhóm có được cơ hội đó! Nếu quản lý vi mô không phải kiểu của bạn, hãy làm theo hướng dẫn

số 3

HƯỚNG DẪN 3: Đánh đồng tự quản lý với tự lãnh đạo và không chỉ dẫn nhóm bất kỳ điều gì

Dù được các cấp cao nhất trong công ty ủng hộ, việc áp dụng Agile thường sẽ được nhóm Agile tự mình triển khai Đừng lo Bạn vẫn có nhiều cơ hội để làm cho Agile thất bại, đặc biệt nếu bạn là quản lý Bạn

có thể bắt đầu bằng cách ngầm phá hoại người tiên phong trong nhóm

- người đã đọc tất cả các cuốn sách về Agile và đang tận dụng các cơ hội để quảng bá cho Agile Bỏ qua tất cả các quy tắc mà anh ta yêu cầu bạn tuân theo Gián đoạn Scrum Hằng ngày với những chỉ thị mới Thay đổi thứ tự ưu tiên của các mục tiêu trong phân đoạn Những việc này được thực hiện khi làm theo hướng dẫn số 4

HƯỚNG DẪN 4: Phớt lờ các quy tắc của 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ễ trong công ty, hãy nói thẳng với các thành viên nhóm Agile rằng bạn nghĩ Agile chỉ là một trào lưu Vài người từ đầu đã hoài

nghi rồi, vì vậy không tốn nhiều công sức để thuyết phục họ phớt lờ các kĩ thuật Agile Nhớ rằng, giống như Barney Fife, bạn có quyền lực

để diệt Agile từ trong trứng nước Chỉ cần làm theo hướng dẫn số 5

HƯỚNG DẪN 5: Ngầm phá hoại niềm tin của nhóm về Agile

CÁC VẤN ĐỀ VỀ NHÓM

Không phải tất cả chúng ta đều là quản lý Đừng lo, dù không phải quản lý chúng ta vẫn có thể tạo ảnh hưởng phá hoại cả nhóm Hãy xem trường hợp của nhóm Agile NotQuite, được giao phát triển phần mềm quản lý kho hàng Nhóm cho thấy sức mạnh của tính kiên định trong việc làm đổ bể một dự án phần mềm Trong phân đoạn đầu tiên, NotQuite cam kết hoàn thành 6 hạng mục trong Product backlog; nhóm đã hoàn thành 4 Vì trong phân đoạn đầu tiên, hầu hết mọi người đều cam kết quá nhiều, nên Product Owner không chỉ trích nhóm nhiều lắm Điều này không làm nhóm NotQuite lo lắng

Đến phân đoạn thứ hai, nhóm vẫn lên kế hoạch hoàn thành 6 hạng mục; nhóm đã hoàn thành được 5 Sự cải tiến nhẹ này ru ngủ Product Owner vào cảm giác an toàn giả tạo NotQuite tiếp tục cam kết quá sức, chậm tiến độ trong các phân đoạn thứ 3, 4, 5 Product Owner sớm thấy rằng không thể tin được nhóm, điều này ngầm phá hủy bất kì khả năng thành công nào của Agile Đây quả là một trường hợp tuyệt vời làm theo hướng dẫn số 6

HƯỚNG DẪN 6: Liên tục không chuyển giao được điều bạn đã cam kết khi lập kế hoạch cho phân đoạn

Khi chậm tiến độ, đừng mắc sai lầm làm hết sức mình trong mọi phân đoạn, lần nào cũng kiệt sức khi đến ngày cuối cùng Một nhóm như vậy hầu như luôn được tha thứ dù không bao giờ chuyển giao được đúng kế hoạch Lý do chính trong sai lầm của NotQuite là thái độ ung dung với những cam kết không đạt được Thành viên nhóm tỏ rõ rằng việc hoàn thành công việc đúng ngày cam kết hay chậm vài ngày là việc bình thường Bạn bè với nhau thì vài ngày có là gì? Nhớ rằng, vài ngày nhiều lần gộp lại sẽ thành khá nhiều Nếu một nhóm Agile liên tục không thực hiện được cam kết, Product Owner không thể lập kế hoạch và không thể cam kết gì với bên ngoài Điều này dẫn tới hướng dẫn số 7 để 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 này sang phân đoạn khác khiến cho Product Owner luôn phải đoán xem

có thể chuyển giao cái gì

Có lẽ cách tốt nhất làm cho một dự án Agile thất bại là làm theo hướng dẫn số 8

HƯỚNG DẪN 8: Đừng lập nhóm liên chức năng Hãy để tất cả kiểm thử viên vào một nhóm, tất cả lập trình viên vào một nhóm khác, v.v

Merrilynn có thể dùng hướng dẫn này để hủy diệt dự án thử nghiệm Agile của công ty cô Đó là dự án phát triển một chương trình có hai ứng dụng máy khách(client) tách riêng cho Windows và Web Là giám đốc phát triển, Merrilynn có quyền chia nhóm và đã tạo ra ba nhóm

riêng biệt: một nhóm Windows, một nhóm Web, và một nhóm kiểm thử Cấu trúc nhóm này trái ngược với các mục tiêu của Agile Nếu Merrilynn muốn thành công, cô lẽ ra phải tạo ba nhóm mà mỗi nhóm đều có người với đủ các kĩ năng Windows, Web và kiểm thử Bởi vì Merrilynn tách riêng các nhóm, cô khiến cho mỗi nhóm không thể chuyển giao được phần mềm hoàn chỉnh mà một nhóm Agile có thể chuyển giao mỗi cuối phân đoạn Giỏi đấy, Merrilynn

Một lựa chọn khác cho Merrilynn là đặt toàn bộ 20 người vào một nhóm Điều này sẽ trái với lời khuyên chuẩn của Agile là một nhóm chỉ có từ 5 đến 9 người Cô có thể giải thích với người thắc mắc về quyết định này bằng cách nhấn mạnh vào tính duy nhất của 2 ứng dụng máy khách trong sản phẩm của nhóm mình Nếu cô chọn cách tạo một nhóm lớn thay vì 3 nhóm cỡ hợp lý, Merrilynn sẽ khiến tốn quá nhiều thời gian dành cho giao tiếp trong nhóm Làm cho tiến độ

bị chậm lại và khiến mọi người phàn nàn rằng việc giao tiếp trong Agile là một gánh nặng khổng lồ Nếu phân tách nhóm quá khó để giải thích, bạn có thể cản trở một dự án rất dễ dàng bằng hướng dẫn số 9

HƯỚNG DẪN 9: Dự án lớn cần nhóm lớn Mặc kệ những nghiên cứu nói rằng năng suất trong nhóm lớn bị giảm do thời gian cho giao tiếp tăng lên Bởi vì mọi người cần biết về mọi thứ, hãy mời tất cả 50 người tham gia phiên họp đứng hàng ngày

CÁC VẤN ĐỀ VỀ PRODUCT OWNER

Như bạn có thể thấy, Product Owner có thể

dễ dàng làm cho Agile thất bại bằng cách giao tiếp sai lệch, không quan tâm đến tiến độ nhóm, và thiếu đào tạo

Nếu bạn không thể làm theo những hướng dẫn về nhóm và quản lý, bạn có thể làm theo hướng dẫn cho Product Owner Một Product Owner có rất nhiều lựa chọn trong thẩm quyền của mình để đẩy một dự án Agile đến bờ vực

Hãy xem ví dụ về Kathy, Product Owner của một nhóm làm về video game Nhóm đang đạt được tiến độ tuyệt vời qua mỗi phân đoạn(Sprint) và mỗi lần đều có thêm những niềm vui cho người chơi Kathy để thành viên nhóm nghĩ rằng đó là tất cả những gì họ cần làm

Cô không bao giờ tham gia các buổi Sơ kết, hiếm khi dùng thử trò chơi,

và đặt ra những story đẩy trò chơi đi theo hướng mà cô tưởng tượng Nếu như vậy vẫn chưa đủ, Kathy không chia sẻ tầm nhìn của mình với nhóm hoặc với những khách hàng mà cô có trách nhiệm báo cáo (ví

dụ bên marketing)

Sau một năm phát triển, trò chơi được trình diễn cho một nhóm điều hành rồi làm họ choáng váng về hướng phát triển của trò chơi Đó không phải điều họ muốn đưa ra thị trường Liên kết rời rạc giữa Kathy, nhóm và quản lý cấp cao làm cho dự án chậm tiến độ 6 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 trong tay một Product Owner

HƯỚNG DẪN 10: Đừng giao tiếp tầm nhìn về sản phẩm cho nhóm Agile hay các bên liên quan khác

HƯỚNG DẪN 11: Đừng quan tâm đến tiến độ mỗi phân đoạn và đánh giá khách quan tiến độ chung

HƯỚNG DẪN 12: Thay thế tài liệu kế hoạch bằng một kế hoạch

“trong đầu bạn” mà chỉ mình bạn biết

Một trong những nguyên lý cơ bản của phát triển theo phân đoạn lặp là thấy được các chức năng đóng góp giá trị gì trong toàn bộ hệ thống Đây là lý do mỗi phân đoạn đều tạo ra một phiên bản có thể phát hành của sản phẩm Điều này tương phản hoàn toàn với các dự án phát triển theo kế hoạch cố định, trong đó các nguồn lực được tính toán để tạo ra được sản phẩm khi kết thúc kế hoạch Khi một Product Owner không thay đổi cách làm đó, nhóm Agile sẽ nhanh chóng thất bại Việc đào tạo Product Owner cũng quan trọng như đào tạo nhóm Nói chung, nếu bạn muốn đảm bảo Agile thất bại nhanh chóng, hãy tránh

xa hoàn toàn khỏi đào tạo

Vai ác của Product Owner thường được cân bằng bởi ScrumMaster hoặc huấn luyện viên của nhóm Trong những dự án thành công, luôn

có một sự căng thẳng nhất định giữa Product Owner và ScrumMaster Một Product Owner luôn muốn thêm nhiều chức năng hơn nữa Ngược lại, huấn luyện viên có trách nhiệm theo dõi sức khỏe của nhóm Nếu nhóm bị ép quá mức và bắt đầu uể oải vì mệt, huấn luyện viên sẽ đẩy lui mong muốn nhiều hơn nữa của Product Owner Một

cách tốt để làm Agile thất bại là loại bỏ sức ép kéo-đẩy giữa huấn luyện viên và Product Owner theo hướng dẫn số 13 dưới đây

HƯỚNG DẪN 13: Để một người làm vai trò của cả ScrumMaster (Agile coach) và Product Owner Thực tế, người này cũng làm

một thành viên trong nhóm phát triển

Như bạn thấy, Product Owner rất dễ làm cho Agile thất bại bằng cách giao tiếp lỗi, không để ý đến tiến độ nhóm, và chưa được đào tạo Nếu cần bạn có thể gộp những điều trên lại bằng cách để một người đồng thời làm những vai trò vốn được thiết kế để cân bằng lẫn nhau Làm chính xác theo những hướng dẫn trên là cách tuyệt vời để thất bại

CÁC VẤN ĐỀ VỀ QUY TRÌNH

Thay vì điều chỉnh linh hoạt lương, thưởng, chức vụ, thăng tiến theo Agile, hãy thưởng cho từng cá nhân để ngầm phá hoại tinh thần làm việc nhóm và chịu trách nhiệm chung

Nếu các cách trên không thành công, xử lý sai các vấn đề về qui trình

có thể làm thất bại hầu hết các dự án Agile Jon là một ví dụ kinh hoàng

về cơn ác mộng qui trình, và anh ta tạo ra những sự phá hoại lớn nhất

mà không biết mình chính là nguyên nhân Jon là trưởng nhóm lập trình của một nhóm ở Chicago đang phát triển phần mềm để chấp nhận hay từ chối các khoản vay Ngoài việc làm trưởng nhóm, anh ta

còn làm ScrumMaster (hãy xem lại hướng dẫn 13, riêng điều này cũng

có thể gây ra thảm họa)

Nhóm Jon mới áp dụng Agile và nôn nóng muốn bỏ bớt những phần không cần thiết Nhóm ngay lập tức hủy bỏ họp đứng hàng ngày, lấy

lý do rằng nhóm ngồi cùng một khu vực, mọi người có thể nghe được hầu hết các cuộc nói chuyện qua vách ngăn 1,8m

Họ cũng quyết định rằng các kiểm thử đơn vị tự động là không cần thiết Bởi vì họ làm một chương trình mới, không có code cũ để mà làm hỏng, và do mọi người đều để ý code mới nên cũng ít khả năng làm hỏng code mới Tuy nhiên, Jon và đồng nghiệp vẫn áp dụng tái cấu trúc và sở hữu tập thể mã nguồn

Họ đặt qui tắc là ai cũng có thể thay đổi code của người khác bất kì lúc nào Họ sớm nhận ra việc tái cấu trúc và sở hữu tập thể mã nguồn có thể rất nguy hiểm nếu không có lưới an toàn của các kiểm thử đơn vị

tự động để đảm bảo bạn không làm hỏng điều gì trong khi cải tiến mã Jon và nhóm đã vô tình làm theo hai hướng dẫn làm cho Agile thất bại dưới đây

HƯỚNG DẪN 14: Tùy chỉnh một qui trình Agile trước khi hoàn

toàn tuân thủ qui trình đó

HƯỚNG DẪN 15: Bỏ qua và tùy chỉnh những kĩ thuật Agile quan trọng trước khi hoàn toàn hiểu rõ chúng

Một cách thay thế cho những hướng dẫn trên là áp dụng các kĩ thuật

mà không hiểu tại sao phải làm vậy Là huấn luyện viên, chúng tôi đã gặp nhiều nhóm học/làm một kĩ thuật do người khác yêu cầu và những người tiếp tục làm kĩ thuật đó dù họ đã không cần nó nữa Điều

này làm ta nhớ đến câu chuyện nàng dâu mới phải cắt hai đầu tất cả các miếng thịt trước khi cho vào chảo mà không biết tại sao phải làm vậy

Khi người chồng hỏi tại sao cô tỉa miếng thịt như vậy, cô không có câu trả lời; cô làm vậy vì đó là cách mẹ cô làm Tò mò về thói quen của mẹ mình, cô vợ gọi điện và hỏi tại sao bà lại dạy cô cắt phần đuôi miếng thịt như vậy Mẹ cô bảo rằng do bà cô dạy như vậy Cô vợ trẻ lại gọi

bà và hỏi tại sao bà lại cắt phần đuôi của mọi miếng thịt Bà nói với cô: “Bởi vì chảo rán thịt của bà quá nhỏ Miếng thịt không vừa” Câu chuyện này tương tự với hướng dẫn tiếp theo làm Agile thất bại

HƯỚNG DẪN 16: Mù quáng làm theo các kĩ thuật Agile mà không hiểu rõ các nguyên lý phía dưới

Nếu bạn không thể thực hiện hướng dẫn từ 14 đến 16 và dự án Agile của bạn đang thành công dù bạn rất cố gắng, bạn có thể làm ngừng một dự án thành công bằng cách không thay đổi gì cả Gì cơ? Không thay đổi gì cả? Theo dõi ví dụ của nhóm StatusQ StatusQ có nhiệm vụ phát triển mới một hệ thống đặt chỗ trên nền tảng web, đã có một khởi đầu tốt đẹp Các thành viên nhóm đều mới làm quen với Agile nhưng đã nghiên cứu kĩ và thậm chí còn gửi vài người đi học để trở thành ScrumMaster có chứng chỉ

Dự án rất nhanh đạt được lợi ích từ phương pháp mới Trong một tháng, StatusQ đã chạy được một trang web đơn giản và trình diễn vài giao diện chính khiến cho khách hàng tự tin rằng sẽ có được hệ thống đặt chỗ mạnh mẽ và tiện dụng trong tương lai