Agile hoạt động như thế nào khi thay thế một hệ thống làm việc?

Trong một thế giới Agile lý tưởng, bạn nhanh chóng xây dựng một tập hợp con nhỏ nhưng hữu ích của hệ thống đầu cuối mong muốn và cung cấp cho người dùng. Họ rất phấn khích, vì nó hữu ích, họ bắt đầu sử dụng nó và đưa ra phản hồi. Sau đó, bạn tìm ra những gì để thêm vào nó, xây dựng nó và lặp lại cho đến khi bạn hết thời gian.

Gần đây tôi đã có một vài dự án liên quan đến việc thay thế một số loại hệ thống làm việc. Mô hình trên hoàn toàn không hoạt động: cho đến khi bạn xây dựng một hệ thống bao gồm hầu như tất cả các chức năng của hệ thống hiện tại, người dùng hoàn toàn không quan tâm. Họ sẽ không sử dụng nó.

Làm thế nào để bạn áp dụng Agile khi "tập hợp con hữu ích nhỏ nhất" là "tất cả của nó"?

Giải pháp nhanh có thể không phải là thay thế tất cả trong một lần, mà là pha dần dần thay thế.

Giới thiệu hệ thống mới dần dần, từng chút một, giữ cho các bộ phận của hệ thống cũ hoạt động. Hệ thống cũ không tắt tất cả trong một lần, nó sẽ biến mất. Các bộ phận mới cung cấp chức năng mới hoặc các lợi ích khác, vì vậy người dùng rất vui mừng khi sử dụng chúng. Điều này cũng ít rủi ro hơn, vì bạn luôn có một hệ thống làm việc 100%.

• Đọc thêm từ Martin Fowler .
• Các chiến lược trong Michael Feather hoạt động hiệu quả với mã kế thừa có thể hữu ích

Thay vì viết lại hệ thống hiện có (như bạn đã đề cập sẽ mất khá nhiều nỗ lực trước khi hệ thống mới phù hợp với chức năng hiện có), hãy xem xét phương pháp tiếp cận cây nho lạ . Về cơ bản, bạn triển khai chức năng mới bằng cách sử dụng phương pháp mới của bạn trên ứng dụng hiện có. Cuối cùng, khi bạn giải quyết các thiếu sót của hệ thống cũ để giải quyết chức năng mới, mã mới sẽ thay thế hoàn toàn cái cũ.

Điều này đòi hỏi độ chính xác và nỗ lực cao hơn so với "khởi động lại" ứng dụng cũ. Nhưng bạn có một thời gian ngắn hơn để ROI. Ngoài ra, trải qua quá trình, bạn có thể đặt móc vào vị trí để cho phép hệ thống "mới" dễ dàng bị bóp nghẹt hơn bởi hệ thống "mới" tiếp theo.

Phát hành gia tăng nhỏ vào thế giới có thể hoạt động cho các dự án greenfield nhưng ngay cả khi đó số lượng nhỏ các tính năng có thể không quá hữu ích.

Scrum ủng hộ rằng sau mỗi lần chạy nước rút, sản phẩm đó là "Có thể chuyển đổi được". Nó không phải được vận chuyển mà phải có chất lượng của một sản phẩm có thể chuyển được.

Nếu bạn muốn cung cấp cho người dùng phiên bản gia tăng của ứng dụng thì bạn có thể xác nhận nó là Alpha rồi Beta rồi phát hành phiên bản Ứng viên trong khi vẫn sử dụng ứng dụng Sản xuất thực sự.

Bạn có thể thấy rằng các tính năng mới được thêm vào và các tính năng cũ sẽ bị loại bỏ nếu bạn kết hợp phản hồi từ người dùng.

Tôi đã làm việc trên một dòng lớn thay thế ứng dụng kinh doanh cho một mạng truyền hình cáp quốc gia lớn. Việc phát triển hệ thống mới được thực hiện với SCRUM, đó là dự án phát triển 18-24 tháng để thực hiện lại gần như tất cả các hệ thống phụ chính; đã gần 10 tuổi.

Có một giai đoạn lập kế hoạch giống như 6 tháng trước khi sự phát triển bắt đầu, nhưng nó cũng được tiếp cận như SCRUM. Đây là nơi chủ sở hữu sản phẩm đã viết các cửa hàng và sử thi cấp cao sau khi phân tích hệ thống hiện có và phỏng vấn khách hàng.

Hệ thống hiện tại cực kỳ ổn định khi chuyển sang chế độ bảo trì quan trọng; chỉ hiển thị các sự cố chặn đã được khắc phục, mọi thứ chỉ được ghi lại cho mục đích lịch sử và để đảm bảo các vấn đề tương tự không xuất hiện trong hệ thống mới.

Hệ thống mới phát triển như được mô tả trong một quy trình Agile, phần lớn nó cực kỳ trơn tru. Khi hệ thống thay thế đạt được tính năng một phần, nó không đi vào sản xuất mà chuyển sang thử nghiệm sản xuất song song. Một tập hợp con gồm các công nhân không quan trọng bắt đầu sử dụng cả hai hệ thống, để xác nhận rằng hệ thống mới hoạt động như hệ thống cũ; Tất nhiên với các lỗi cũ đã được sửa.

Khi hệ thống mới đạt được gần như 100% các tính năng mới, nó đã được triển khai cho các hoạt động sản xuất song song chung, kéo dài một vài tháng.

Một khi nó được khách hàng coi là đáp ứng nhu cầu của họ, hệ thống cũ đã được sao lưu, tắt và ngồi. Tôi cho rằng họ đã tái sử dụng phần cứng hệ thống cũ bởi vì họ không bao giờ cần phải quay lại hệ thống cũ sau khi bị cắt.

Tôi vẫn nghĩ nhanh nhẹn thêm rất nhiều giá trị trong kịch bản này.

Chỉ là bạn có một mục tiêu cuối cùng được xác định là 'thay thế hệ thống hiện tại.'

Các kỹ thuật và quy trình nhanh nhẹn vẫn có thể giúp bạn đến đó hiệu quả hơn.

Ví dụ:

Bạn vẫn có thể cung cấp trên hệ thống lặp đi lặp lại và trong các lần chạy nước rút nhỏ.

Bạn vẫn có thể sử dụng các kỹ thuật nhanh để ưu tiên công việc sau khi giao tiếp với những người chủ chốt.

Bạn vẫn có thể sử dụng nhanh để lập kế hoạch dựa trên vận tốc quan sát được.

Bạn vẫn có thể sử dụng các kỹ thuật và triết lý nhanh nhẹn như truyền bá kiến ​​thức, TDD, mã hóa sạch để nâng cao chất lượng và thiết kế nội bộ của dự án.

Nếu bạn có những người thực sự 'không quan tâm' đến dự án và không tham gia vào dự án cho đến khi họ có một sự thay thế hoàn hảo, bạn sẽ gặp vấn đề lớn hơn bất kể bạn đang sử dụng thác nước, nhanh nhẹn hay thực sự là bất kỳ quy trình nào.

Nó hoạt động như nhau, nhưng cách tiếp cận này sẽ khó bán hơn cho người dùng hiện tại. Họ có thể không muốn hệ thống mới và họ không muốn bị gián đoạn với thử nghiệm định kỳ. Họ muốn chờ càng lâu càng tốt và cuối cùng chỉ cần kiểm tra nó. Hầu hết người dùng cảm thấy theo cách này ở một mức độ nhất định, nhưng tùy thuộc vào những người chịu trách nhiệm giáo dục họ. Trong suy nghĩ của họ, bạn đang làm việc với một ứng dụng hiện có, vì vậy bạn nên biết nó giả sử phải làm gì, tại sao lại làm phiền họ?

Làm cho họ hiểu rằng bạn không muốn làm theo cách này bởi vì bạn nghĩ nó sẽ rất vui và bạn cảm thấy cô đơn khi sử dụng quy trình thác nước. Nó sẽ làm cho một ứng dụng tốt hơn trong thời gian dài.

Một điểm bán hàng quan trọng có thể là thực hiện một thay đổi trong quá trình xây dựng ứng dụng mới mà họ luôn muốn, nhưng không bao giờ có thể có trong hệ thống cũ.

Nếu tôi có một chiếc xe cũ rỉ sét mà tôi cần phải lái để đi làm, và tôi đến đại lý để mua một chiếc xe mới. Mô hình mà tôi muốn đã hết hàng nên họ phải đặt hàng từ nhà máy và sẽ mất một lúc trước khi nó xuất hiện.

Các đại lý sau đó không có thiện chí quyết định cung cấp cho bạn khối động cơ xe cho đến khi chiếc xe bạn đặt hàng đã vào. Bạn phải làm gì với động cơ xe? Chắc chắn tôi có thể nối một số bộ phận để kiểm tra và làm cho nó hoạt động, nhưng nó thực sự không giúp tôi làm việc vào ngày mai khi chiếc xe cũ bị rỉ sét.

Cấp có một xa khóc khác nhau giữa việc xây dựng một chiếc xe hơi và xây dựng phần mềm tùy chỉnh, nhưng chúng ta hãy bỏ qua điều đó vì lợi ích của đối số. Điểm chính của câu chuyện là không bị bối rối khi khách hàng thấy không sử dụng được các thay đổi gia tăng khi họ đã có phần mềm đủ tốt để hoàn thành công việc ngay bây giờ. Nó đã đáp ứng nhu cầu của họ trong thời gian này.

Điều đó không có nghĩa là Agile không phải là một phần quan trọng của quy trình ở đây vì nó cho phép phản hồi liên tục cho khách hàng về trạng thái của dự án. Họ có thể đảm bảo rằng tiến trình đang được thực hiện trước các mốc quan trọng và việc giao hàng. Họ có thể xác định các vấn đề tiềm ẩn và các vấn đề sớm hơn trước khi nó trở thành một lỗi quá tốn kém để sửa chữa.

Có thể là khách hàng xe hơi bạn chỉ muốn nhìn vào và đánh giá động cơ để chắc chắn rằng bạn thực sự sẽ có được những gì bạn dự đoán. Rất tiếc, tôi thực sự muốn một động cơ 6 xi lanh thay vì động cơ 4 xi lanh! Không phải tôi đã nói với bạn điều đó sớm hơn sao? Không có vấn đề, hãy đặt một thay đổi vào thứ tự nhà máy.

Bán ý tưởng cho khách hàng rằng họ nên sử dụng các bản phát hành phần mềm mới không phải là một sự thay thế mà chỉ để đánh giá nó và đảm bảo rằng họ hài lòng với từng bước trên đường đi.