Viết lại phần mềm bằng các phương pháp Agile

Giả sử bạn phải viết lại toàn bộ ứng dụng bằng các phương pháp Agile, bạn sẽ làm thế nào?

Tôi đoán bạn có thể viết một loạt các câu chuyện người dùng dựa trên hành vi của hệ thống hiện tại của bạn. Và sau đó thực hiện chúng trong các lần lặp nhỏ. Nhưng điều này không có nghĩa là chúng ta có những yêu cầu LÊN TỪ ??

Ngoài ra, khi nào bạn sẽ bắt đầu phát hành? Agile nói rằng chúng ta nên phát hành sớm và thường xuyên, nhưng sẽ không có ý nghĩa gì khi phát hành trước khi hoàn thành việc viết lại.

Phá vỡ nó thành sử thi cấp cao. Lấy từng khu vực chức năng của ứng dụng, từng bước một.

Chia một sử thi thành một nhóm các câu chuyện (các đoạn có thể sử dụng - bất cứ điều gì cải thiện ứng dụng) và quản lý những câu chuyện đó nếu bạn không có một ứng dụng hiện có, với một ngoại lệ: Nếu có thể, hãy làm cho nó sao cho bạn có thể triển khai một phần chức năng như một phần hoặc bên cạnh ứng dụng gốc.

Khi Agilists nói "phát hành sớm và thường xuyên", điều đó không nhất thiết có nghĩa là sản xuất. Nếu bạn sẽ thay thế một ứng dụng hiện có, bạn nên sử dụng khu vực tổ chức để phát hành thường xuyên và đảm bảo người dùng của bạn đang kiểm tra hệ thống ở đó. Điều này vẫn sẽ cung cấp cho họ chỗ để ưu tiên cho công việc tiếp theo và để đảm bảo rằng không có gì bạn phát hành cho sản xuất làm mất giá trị sản phẩm.

Khi bạn đã phát hành một thành phần để sản xuất, hãy chuyển sang phần tiếp theo.

chúng tôi vừa trải qua một trải nghiệm như vậy (tôi là chủ sở hữu sản phẩm scrum). Chúng tôi mất hai năm để đi đến một cái gì đó đáng tin cậy. Nhưng vẫn nhanh nhẹn mang lại cho chúng ta nhiều lợi ích.

Thứ nhất: Bản chất viết lại hoàn toàn không nhanh nhẹn. Thay vào đó, bạn nên xem xét tái cấu trúc từng mảnh sản phẩm hiện có. Điều đó đã được thảo luận trong một câu hỏi khác. Vì vậy, hãy giả sử nó phải được viết lại.

Sau đó, thực sự, bạn bắt đầu với một bản ghi lại bao gồm tất cả các trường hợp sử dụng có liên quan của sản phẩm hiện có. Nhưng xin đừng tiếp cận nó như viết thông số kỹ thuật. Đó sẽ là quá nhiều chi tiết. Nó nên được hoàn thành (nếu không bạn không thể lập kế hoạch phát hành). Và nó không nên quá phức tạp (nếu không bạn đang viết thông số kỹ thuật trả trước). Đây là cách chúng tôi tiếp cận:

• phân loại người dùng của sản phẩm cũ. Xác định người dùng chỉ cần một phần nhỏ của sản phẩm cũ mà vẫn nhận được một cái gì đó hữu ích từ nó. Họ xác định sử thi đầu tiên của bạn.

• Sau đó thêm sử thi cho phép một danh mục người dùng khác chuyển sang sản phẩm mới. V.v. cho đến khi bạn có một bản ghi lại bao gồm tất cả người dùng.

• rất có thể, những sử thi này sẽ cần phải chia tách thêm. Nếu có thể, hãy cố gắng tách để mỗi phần vẫn có một số giá trị. Nếu điều đó không khả thi, thì ít nhất hãy đảm bảo rằng mỗi phần có thể được chứng minh.

• khi bạn có 20-50 sử thi, hãy để nhóm ước tính chúng.

• chia phần lớn các sử thi hàng đầu thành Câu chuyện người dùng mà nhóm tin rằng có thể khả thi trong giai đoạn nước rút. Đừng làm điều đó cho tất cả các sử thi, chỉ những người trên đầu trang. Bạn sẽ có nhiều thời gian để chia phần còn lại.

Khi nào phát hành ra bên ngoài! Đó là một quyết định kinh doanh. Ít nhất phương pháp này cung cấp cho bạn cơ hội để phát hành sớm hơn cho các danh mục người dùng nhất định. Điều đó có thể hữu ích nếu ban quản lý lo lắng về dự án dường như không bao giờ kết thúc này.

Phát hành ngay nếu bạn có thể

Câu hỏi của bạn về khi nào bạn bắt đầu phát hành mã là một câu hỏi hay. Tôi nghĩ rằng hai điều khoản áp dụng. Thứ nhất, bạn có "chất lượng đủ tốt" và thứ hai là bạn đáp ứng các yêu cầu cho một MVP (sản phẩm khả thi tối thiểu).

Rome (và Agile) không được xây dựng trong một ngày

Có lẽ bạn đã sẵn sàng với một đội ngũ chìa khóa trao tay nhanh nhẹn để tiếp quản vào ngày đầu tiên. Đối với hầu hết các tổ chức, có công việc và chi phí đào tạo, trang bị lại, và hình thành thông thường, gây bão, định mức, thực hiện chu trình xây dựng một đội. Hãy thẳng thắn về những rủi ro và chi phí, hãy cẩn thận để đặt kỳ vọng thực tế, và đánh bại và chuẩn bị để ủng hộ cách tiếp cận của bạn.

Hãy là một Bootstrapper tái sử dụng

Giống như sức mạnh tổng hợp, tái sử dụng mã là và luôn luôn là giải pháp tương lai cho các vấn đề kinh tế của chúng ta. Cảm giác của tôi là các nhà phát triển thường nói rằng họ tin vào việc tái sử dụng, nhưng chỉ là loại tái sử dụng bắt đầu sau khi họ xây dựng một khung mới, chứ không phải là loại mà họ xây dựng dựa trên những gì người khác đã làm. Làm thế nào điều đó có thể làm việc cho đến khi ai đó sẵn sàng chọn để xây dựng trên nền tảng của người khác? Tốt nhất, nó có nghĩa là viết lại cứ sau vài năm khi lãnh đạo nhóm thay đổi.

Tại sao phát hành sớm và thường xuyên?

Phát hành sớm và thường là một câu thần chú vì nhiều lý do. Nó mang lại sức sống cho các cuộc thảo luận của chúng tôi về những gì sản phẩm sẽ trở thành, nó thực sự ở nơi chúng tôi đang ở và nó cho chúng tôi một cơ sở cho những thay đổi lặp đi lặp lại / tăng dần. Tốc độ phát hành gần như là một bất biến đối với nhanh nhẹn, với sự khác biệt là người nhận được bản phát hành (người thay thế khách hàng hoặc người dùng cuối). Trước khi nhanh nhẹn, bảo trì được ước tính chiếm 60% chi phí của hệ thống phần mềm. Đây là một nguồn gây dựng nhiều cho các nhà quản lý và những người khác, một số người cảm thấy việc phát hành sản phẩm là nơi phần mềm sẽ chết. Đối với họ, mọi thứ sau khi phát hành là làm lại và trả tiền để sửa một sản phẩm mà họ đã trả tiền một lần rồi.

Phát hành trước là không tự nhiên

Kent Beck viết rằng tiền phát hành là một trạng thái không tự nhiên cho các sản phẩm phần mềm. Đó chắc chắn là một thời gian bất tiện vì đó là thời gian bạn không có khách hàng và bạn đang trả tiền cho sản phẩm hơn là sản phẩm trả tiền cho bạn.

Đừng chỉ trích đội trước

Mặc dù nó có thể thiết lập các nhà phát triển đảm nhận việc viết lại như là những vị anh hùng và sự cứu rỗi của dự án, tôi nghĩ rằng có một chi phí để chỉ trích những thành tựu của đội trước đó.

• Đầu tiên, nếu bạn để mọi người tự quyết định về đội trước, bạn có nhiều thời gian và năng lượng hơn cho nhiệm vụ thực sự của mình.
• Sẽ rất khó xử nếu bạn cần làm việc với các thành viên của nhóm trước, cả nhà phát triển cũng như các bên liên quan như quản lý sản phẩm, quản lý dự án hoặc khách hàng.
• Nếu bạn có thể làm cho nó hoạt động, bạn có thể thấy mình nhận được (hoặc tệ hơn là lấy) tín dụng cho những gì nhóm trước đã làm.
• Trung bình, đội trước có lẽ là trung bình. Trung bình, bạn có thể là trung bình. Bạn có nhiều công việc hơn nhóm trước vì bạn có một phương pháp mới để đưa vào bên cạnh một dự án.
• Nếu đội bóng cũ là khủng khiếp, trừ khi bạn quá khủng khiếp, cuối cùng bạn sẽ nhận được tín dụng vì tốt hơn là khủng khiếp. Nếu chúng tốt hơn kinh khủng, và bạn không tốt hơn đáng kể, nói rằng chúng thật kinh khủng có thể đưa ra những so sánh khó chịu.
• Nếu nhóm cũ tốt hơn bạn nghĩ và bạn gặp rắc rối vì tổ chức bị hỏng hoặc vấn đề không được xác định rõ ràng hoặc rất khó khăn, mọi thứ sẽ tốt hơn cho bạn nếu bạn không tăng đáng kể kỳ vọng.
• Nếu họ mong đợi những gì họ nhận được, nhưng bạn làm tốt hơn, đó là một chiến thắng cho bạn.
• Để kiềm chế những lời chỉ trích là cả cách cư xử tốt, và cho thấy rằng bạn có đẳng cấp.

Được khuyến khích bởi các bình luận của @Chuck và các tài liệu tham khảo về Netscape về cơ bản nói rằng không viết lại và các câu trả lời hợp lệ phản hồi rằng anh ấy OP không hỏi liệu anh ấy có nên không. - Một chu trình phát triển phần mềm thực sự nhanh nhẹn ngăn chặn việc viết lại. Viết lại hầu như luôn phá vỡ nhiều nguyên tắc đằng sau Agile. Sử dụng phần mềm hiện tại làm cơ sở cho các nguyên tắc Agile này (từ Tuyên ngôn Agile ) không thể được đáp ứng bằng cách viết lại.

• Giao hàng sớm và liên tục các phần mềm có giá trị . - khách hàng sẽ không nhận được giá trị sớm khi được đo dựa trên những gì họ đã có
• Cung cấp phần mềm làm việc thường xuyên - vài tuần đến vài tháng - dự án lớn như thế nào, bạn có thể thành thật nói rằng khách hàng sẽ nhận được bất cứ điều gì hữu ích hơn cho họ bất cứ lúc nào sớm.
• Phần mềm làm việc là thước đo chính của tiến trình - hoạt động so với đường cơ sở sẽ không xảy ra vội vàng
• Các quy trình nhanh nhẹn thúc đẩy phát triển bền vững. - Do khách hàng có đường cơ sở làm việc, áp lực sẽ tăng lên để cung cấp chức năng được cải thiện. Điều này khó có thể được thực hiện ở một tốc độ bền vững
• Đơn giản - nghệ thuật tối đa hóa số lượng công việc không được thực hiện - là điều cần thiết. Điều này nói lên tất cả thực sự ...

"Giả sử bạn phải viết lại toàn bộ ứng dụng bằng các phương pháp Agile, bạn sẽ làm thế nào?"

Câu hỏi dựa trên tiền đề sai - Việc viết lại có thể được coi là Agile.

Xem xét liệu bạn có thể phát hành ứng dụng viết lại một lần tại một thời điểm hay không và có ứng dụng này được sản xuất song song với ứng dụng cũ hay không.

Đối với các ứng dụng web nói riêng, có thể khá dễ dàng để di chuyển một phần của ứng dụng sang nền tảng mới và yêu cầu tuyến cân bằng tải của bạn đến hệ thống thích hợp. Sau đó viết lên những câu chuyện sẽ cho phép bạn đưa trang đầu tiên của bạn vào sản xuất và phân phối chúng theo cách nhanh nhẹn.

Các ứng dụng máy tính để bàn có thể phức tạp hơn, nhưng nó thường sẽ có thể.

Bạn đang tìm kiếm các đường nối - những nơi mà hệ thống cũ có thể đảm nhận trách nhiệm của mình bởi hệ thống mới mà không cần phải viết lại đầy đủ.

Có lẽ có một số logic kinh doanh độc lập có thể được chuyển sang một dịch vụ web hoặc khung mới và ứng dụng cũ có thể được sửa đổi sử dụng thay vì mã cũ của nó. Chỉ cần tiếp tục khắc các khối tại các đường nối cho đến khi những gì còn lại có thể kiểm soát được tất cả trong một vết cắn.

Nếu bạn không thể tìm thấy bất kỳ đường nối nào, thì bạn thực sự có thể cần tìm cách tiếp cận vụ nổ lớn được đề xuất trong một số câu trả lời khác. Nhưng hãy chuẩn bị cho một cuộc diễu hành dài trước khi bạn đến đích, đặc biệt nếu bạn dự kiến ​​sẽ tiếp tục phát triển hệ thống cũ song song ...

Agile nói rằng chúng ta nên phát hành sớm và thường xuyên, nhưng sẽ không có ý nghĩa gì khi phát hành trước khi hoàn thành việc viết lại.

Trên thực tế, IMHO đây là điểm mấu chốt - bạn càng sớm nhận được các phần của ứng dụng viết lại trong sản xuất (và lý tưởng thay thế chức năng của hệ thống cũ), khả năng lớn là dự án của bạn sẽ thành công. Nếu bạn nghĩ rằng điều này không có nhiều ý nghĩa, hãy suy nghĩ kỹ hơn về nó - hầu như luôn có khả năng để phát hành các phần.

Điều đó có thể có nghĩa là ai đó phải thay đổi một cái gì đó trong ứng dụng cũ, ví dụ, thêm một số giao diện mới để tương tác với ứng dụng viết lại trong thời gian viết lại chưa hoàn tất. Nhưng theo kinh nghiệm của tôi, công việc bổ sung như vậy luôn trả tiền cho chính nó.

Một khi các phần đầu tiên của ứng dụng mới được đưa vào sản xuất, cách tiếp cận nhanh, lặp sẽ trở nên rõ ràng. Yêu cầu sẽ thay đổi, câu chuyện người dùng của bạn sẽ thay đổi hoặc nhận được các ưu tiên mới và hy vọng bạn sẽ thay thế ngày càng nhiều chức năng của hệ thống cũ trong các bước nhỏ.