Tái cấu trúc trong phát triển Agile
Trong một dự án phát triển ứng dụng, toàn bộ phạm vi của dự án không được xem xét trong thiết kế ứng dụng. Vì vậy, việc thường xuyên cấu trúc lại các mã để thích ứng với những thay đổi đang tác động tiêu cực đến tiến trình phân phối dự án, điều này đã trở nên cần thiết trong quá trình chạy nước rút. Làm thế nào tốt nhất có thể kiểm soát điều này để giảm thiểu rủi ro vượt quá ngày giao dự án đã thỏa thuận, vì các bên liên quan không sẵn sàng thỏa hiệp?
Trả lời
TL; DR
Một phần của bất kỳ khuôn khổ quản lý dự án nào, nhưng đặc biệt là các khuôn khổ nhanh nhẹn như Scrum, là sự cần thiết của việc liên tục quản lý kỳ vọng của các bên liên quan. Mọi người muốn những gì họ muốn khi họ muốn, nhưng một phần lớn của quản lý dự án là giải thích cho mọi người những gì họ thực sự có thể có trong các ràng buộc khác nhau tác động đến dự án. Khi dự án phát triển, nên hiểu biết về những gì hiện khả thi trong các hạn chế hiện tại, đặc biệt là khi những gì khả thi khác với những gì được lên kế hoạch ban đầu.
Làm lại được mong đợi
Cấu trúc lại thay đổi việc triển khai mà không thay đổi hành vi bên ngoài. Trong tất cả các khả năng, bạn không thực sự tái cấu trúc; bạn đang trả nợ kỹ thuật hoặc thực hiện làm lại và tích hợp, về bản chất không phải là những thứ giống nhau.
Các khuôn khổ như Scrum coi nhiều loại công việc khác nhau (bao gồm tái cấu trúc và làm lại) như một sự đánh đổi có thể chấp nhận được đối với việc kiểm soát và thiết kế theo kinh nghiệm. Điều này được xử lý trong quá trình ước tính và (một cách chính xác) hiển thị như một lực cản về tốc độ khi nợ công nghệ, độ phức tạp hoặc tốc độ thay đổi tăng lên. Điều này được mong đợi và mong muốn trong một khuôn khổ lặp đi lặp lại, bởi vì mỗi vòng lặp kiểm tra và thích ứng cung cấp cơ hội để thay đổi phạm vi, mức độ ưu tiên hoặc cách tiếp cận.
Làm lại là chi phí của việc kiểm soát theo kinh nghiệm. Bạn thực sự không thể tránh nó trong các dự án phức tạp như phát triển phần mềm. Scrum chỉ làm cho nhóm và các bên liên quan nhìn thấy công việc làm lại như là chi phí để thực hiện những thay đổi cần thiết hoặc mong muốn.
Cố định-Mọi thứ không thể
"Tam giác sắt" cho rằng bạn có thể điều chỉnh dự án bằng cách kiểm soát ngân sách, phạm vi hoặc lịch trình, với chất lượng là chiều thứ tư tiềm ẩn bị ảnh hưởng bởi ba thanh trượt còn lại. Hình ảnh sau đây mô tả điều này.
Các khuôn khổ Agile như Scrum thường coi phạm vi, và đặc biệt là phạm vi dự án , là thanh trượt chính bằng cách hỏi:
Chúng ta có thể phù hợp với phạm vi bao nhiêu trong hộp thời gian của một Sprint hoặc phù hợp với kế hoạch phát hành nhanh của chúng ta ?
Hiện tại, dự án của bạn đang cố gắng sửa cả phạm vi và lịch trình. Điều đó chỉ để lại ngân sách dưới dạng thanh trượt có sẵn của bạn. Nếu bạn cũng cố gắng khóa điều đó lại, thì dự án của bạn sẽ thất bại, hoặc chất lượng sẽ bị ảnh hưởng, hoặc cả hai. Bạn chỉ đơn giản là không thể thực hiện một cách đáng tin cậy giá cố định, phạm vi cố định và lịch trình cố định trong bất kỳ khuôn khổ dự án nào trong khi vẫn duy trì chất lượng; Scrum chỉ đơn giản là làm cho nó rõ ràng hơn và làm cho sự đánh đổi trở nên rõ ràng hơn.
Điểm của Scrum không phải là làm cho tam giác sắt biến mất một cách kỳ diệu. Thay vào đó, nó buộc dự án (cũng như các bên liên quan và nhà tài trợ) phải chấp nhận những đánh đổi vốn có. Scrum cho phép các bên liên quan xác định xem điều gì đó "đủ tốt" để xuất xưởng vào cuối mỗi Sprint và Product Owner có cơ hội điều chỉnh phạm vi và mức độ ưu tiên trong quá trình Hoàn thiện Backlog và Lập kế hoạch Sprint. Các bên liên quan cần tận dụng những sự kiện này như một cách để đảm bảo chúng nhận được giá trị khả thi nhất trong kế hoạch phát hành; nó không bao giờ là một đảm bảo hoàn lại tiền rằng dự án sẽ hoàn thành 100% hoặc phù hợp với mục đích khi kết thúc một loạt Sprint cố định.
Giảm chi phí Sunk
Một khía cạnh khác của sự phát triển nhanh nhẹn là cơ hội “thất bại sớm”. Khi một dự án có khả năng thất bại vì bất kỳ lý do gì, các khuôn khổ nhanh nhẹn như Scrum mang lại cho Product Owner cơ hội tiết kiệm tiền bằng cách hủy Sprint và lên kế hoạch cho một Sprint mới dựa trên các kỳ vọng đã thay đổi hoặc cho phép các bên liên quan hủy phần còn lại của dự án nếu nó sẽ không phục vụ mục đích của họ. Sau này sẽ không làm cho dự án thành công, nhưng nó sẽ giảm chi phí chìm liên quan đến dự án.
Không ai có thể đảm bảo rằng một dự án sẽ thành công. Điều tốt nhất bạn có thể làm là kiểm soát nó và giết chết một dự án đã kết thúc càng sớm càng tốt khi thành công không còn là một lựa chọn.
Bạn có thể làm gì bây giờ
Đầu tiên, hãy thừa nhận rằng bạn đang trên con đường dẫn đến một cuộc hành quân tử thần. Nếu bạn không đối mặt với sự thật đó, bạn sẽ không làm gì khác.
Tiếp theo, tìm hiểu xem vấn đề là thiết kế, nợ công nghệ, kỳ vọng không hợp lý hay điều gì khác. Không quan trọng nguyên nhân gốc rễ hoặc các nguyên nhân là gì; bạn chỉ cần làm cho chúng hiển thị để nhóm và các bên liên quan có thể hợp tác giải quyết chúng.
Cuối cùng, thông báo tình trạng hiện tại một cách rõ ràng. Nếu bạn đang bắt kịp bản phát hành đầy đủ tính năng một vài chu kỳ sau ngày phân phối dự kiến ban đầu, hãy thảo luận xem liệu dự án có thể điều chỉnh đỉnh "thời gian" hay không. Nếu bạn không thể hoặc sẽ không điều chỉnh lịch trình, thì bạn vẫn có thể đáp ứng thời hạn cố định bằng cách tăng chi phí hoặc giảm phạm vi. Liệu các bên liên quan có giao dịch giao hàng đúng hạn để cắt bớt một số chức năng tốn thời gian không? Bạn sẽ không biết trừ khi bạn hỏi.
Nếu dự án không thể hoặc không thực hiện bất kỳ điều nào ở trên, thì hãy chuẩn bị cho sự thất bại. Chỉnh sửa sơ yếu lý lịch và hy vọng rằng bạn đã học được những bài học quý giá mà bạn có thể sử dụng cho dự án tiếp theo hoặc công việc tiếp theo của mình. Trên hết, hy vọng rằng bạn đã học cách giao tiếp sớm và thường xuyên về các giả định, thách thức, yêu cầu khuôn khổ và sự đánh đổi, đồng thời hiểu rõ tầm quan trọng của việc liên tục quản lý kỳ vọng của các bên liên quan.
Bạn có đang tạo ra sản phẩm gia tăng có thể triển khai trong mỗi sprint không? Nếu đúng như vậy thì ngày giao hàng đã thỏa thuận đã được đáp ứng và đó là cách tốt nhất để giảm thiểu rủi ro và tạo cho khách hàng niềm tin vào những gì bạn đang làm. Các bên liên quan (thông qua chủ sở hữu sản phẩm) phải quyết định những thứ họ muốn và khi nào, vì vậy điều quan trọng nhất là họ tiếp tục thấy bạn mang lại giá trị và bạn nhận được phản hồi của họ về những cải tiến, thay đổi và sửa chữa cần thiết cho sản phẩm. Nhận phản hồi của họ là chìa khóa ở đây. Khách hàng có thể dễ hiểu lo lắng nếu dòng thời gian kéo dài mà không có phạm vi chức năng mới nhưng ngay khi bạn bắt đầu bao gồm những cải tiến mới nhất mà họ coi là ưu tiên, họ sẽ có nhiều khả năng đánh giá cao nhu cầu về tính linh hoạt.