Làm thế nào để có được thiết kế tốt khi sử dụng các phương pháp nhanh?

Tôi đã sử dụng một phương pháp nhanh (SCRUM) khoảng ba năm nay và tôi thấy một số lợi thế nhất định của nó, đặc biệt là trong phản hồi ngắn hạn ở nhiều cấp độ (từ khách hàng có quyền truy cập sớm vào các tính năng được triển khai, từ người kiểm tra có thể kiểm tra các tính năng như ngay sau khi chúng được triển khai, từ các nhà phát triển khác có thể cung cấp phản hồi rất sớm về mã mới thông qua đánh giá, v.v.).

Mặt khác, tôi có hai vấn đề mở, vấn đề đầu tiên tôi sẽ cố gắng giải thích trong câu hỏi này.

Vấn đề: Khó có được một thiết kế tốt

Tôi cố gắng thực hiện tái cấu trúc ngay khi mã bị rối, tôi viết các bài kiểm tra đơn vị nhiều nhất có thể (điều này giúp ngăn ngừa các lỗi nói chung và khi tái cấu trúc nói riêng). Mặt khác, việc phát triển một số tính năng phức tạp theo từng bước nhỏ, với các cam kết hàng ngày và liên tục suy nghĩ lại về mã khi nó không có cấu trúc không cho phép tôi tạo ra thiết kế thực sự tốt.

Mô-đun duy nhất được thiết kế tốt mà tôi có thể sản xuất gần đây tôi có được bằng cách sử dụng một cách tiếp cận khác: Tôi đã phân tích vấn đề trong vài ngày (tôi thực sự đã gặp phải vấn đề trong vài tháng trước khi tôi bắt đầu làm việc nghiêm túc ), phác thảo một thiết kế khá chi tiết của tất cả các lớp liên quan và mối quan hệ của họ trong vài ngày nữa, sau đó tự nhốt mình trong văn phòng của tôi và viết ra toàn bộ mã bằng cách làm việc mà không bị gián đoạn trong khoảng ba tuần. Kết quả là điều tốt nhất tôi đã tạo ra trong một thời gian, với rất ít lỗi khá dễ tìm và sửa chữa, và với một thiết kế rất rõ ràng, không yêu cầu bất kỳ thay đổi liên quan nào kể từ đó.

Vì vậy, cho đến nay tôi thấy hiệu quả hơn nhiều để có được một bức tranh tổng thể về những gì tôi muốn làm trước đó hơn là bắt đầu viết mã theo từng bước nhỏ với hy vọng rằng bức tranh lớn xuất hiện một cách kỳ diệu trong quá trình này. Với nỗ lực tốt nhất của tôi, phương pháp phát triển gia tăng nhỏ luôn dẫn tôi đến thiết kế tồi tệ hơn.

Câu hỏi : Có ai có kinh nghiệm tương tự không? Tôi đang áp dụng SCRUM sai cách hay tôi nên chú ý điều gì nếu tôi muốn phát triển theo từng bước nhỏ và vẫn kết thúc với một phần mềm được thiết kế tốt? Hoặc tôi nên lên lịch một câu chuyện người dùng thiết kế trước khi bắt đầu mã hóa thực tế? Đây có được coi là một thực tiễn tốt, ít nhất là đối với các tính năng phức tạp hơn mức trung bình?

EDIT - LƯU Ý

Tôi nhận thức được thực tế rằng thiết kế tốt không phải là thứ gì đó tuyệt đối và không có giá trị riêng mà nó phụ thuộc vào bối cảnh, và người ta nên nhắm đến một thiết kế đủ tốt cho vấn đề trong tay.

Ví dụ, tôi không quan tâm (quá nhiều) về thiết kế tốt nếu tôi phải triển khai một thành phần đơn giản mà (1) phải sẵn sàng càng sớm càng tốt, (2) sẽ chỉ được sử dụng một lần, (3) không được sử dụng bởi các bộ phận khác của hệ thống (YAGNI).

Tôi quan tâm đến thiết kế tốt khi một thành phần (1) sẽ được sử dụng nhiều lần và trong một số phiên bản khác nhau của sản phẩm, (2) cần được duy trì và kéo dài theo thời gian, (3) có rất nhiều thành phần khác tùy thuộc vào nó .

Mặt khác, việc phát triển một số tính năng phức tạp theo từng bước nhỏ, với các cam kết hàng ngày và liên tục suy nghĩ lại về mã khi nó không có cấu trúc không cho phép tôi tạo ra thiết kế thực sự tốt.

Vậy thì đừng làm vậy.

Không phải tất cả mọi thứ phù hợp với hộp nhanh nhẹn tốt đẹp. Thông thường, một sản phẩm sẽ có một vài thứ phức tạp không thể được trang bị cho các cá nhân và không thể được hoàn thành theo bất kỳ cách thức lành mạnh nào trong giai đoạn nước rút. Buộc họ vào hộp đó sẽ chỉ gây rắc rối. Nhưng những điều này nên được ít và xa giữa. Nếu bạn thấy rằng nhiều thành phần của bạn giống như thế này, chủ sở hữu sản phẩm của bạn cần phải làm việc để phá vỡ mọi thứ tốt hơn (với nhóm của bạn). Tôi vẫn làm tốt như những gì bạn đã làm: lấy câu chuyện, thiết kế nó, sau đó đập nó ra càng sớm càng tốt với mong muốn sẽ mất vài tuần.

Trong trường hợp tổng quát hơn, có 3 điều mà tôi đã thấy được thực hiện để có được thiết kế tốt trong Agile:

• Thực tế là thiết kế - Rất nhiều nơi tôi đã thấy bắt đầu chạy nước rút của họ và chỉ bắt đầu cao bồi ra mã. Bạn sẽ nhận được thiết kế xấu theo cách này. Agile không thay đổi quy trình phát triển của kế hoạch - mã - thử nghiệm - phát hành, nó chỉ rút ngắn nó thành các phần nhỏ hơn. Khi bắt đầu chạy nước rút, hãy ngồi xuống khi cần thiết và thực sự thiết kế giải pháp của bạn.

• Có một kiến ​​trúc sư / người lãnh đạo - Một khi dự án của bạn đủ lớn, bạn sẽ kết thúc với nhiều nhóm scrum làm việc trên các phần khác nhau của ứng dụng. Sẽ rất hữu ích khi có ai đó (hoặc nhiều người tùy thuộc vào kích thước của ứng dụng) có công việc chính là biết tất cả các nhóm đang làm gì từ quan điểm thiết kế. Họ có thể trả lời các câu hỏi và hướng dẫn các đội hướng tới một thiết kế vòm quá hài hòa hơn. Có mỗi nhóm scrum có một người dẫn đầu biết hầu hết những gì các đội khác đang làm tôi cũng đã thấy và rất hiệu quả.

• Hãy là một người thực dụng - Tôi đã trình bày cái này ở trên. Agile là một công cụ, và giống như bất kỳ công cụ nào; nó không áp dụng cho tất cả các vấn đề. Nếu nó không có ý nghĩa để áp dụng cho một số thành phần, thì đừng áp dụng nó ở đó. Mục tiêu của bạn là gửi phần mềm tốt; đừng quên điều đó

Nó là rất có thể để thực hiện trong gia số nhỏ và kết thúc với mã duy trì có cấu trúc tốt. Về lý thuyết, nó rất đơn giản: nếu bạn đảm bảo rằng mã được cấu trúc tốt sau mỗi thay đổi, nó sẽ luôn được cấu trúc tốt. Mã của bạn đang trở nên có cấu trúc kém bởi vì bạn đang tiếp tục thêm mã khi bạn nên tái cấu trúc.

Cho dù bạn dành bao nhiêu thời gian cho thiết kế, cuối cùng các yêu cầu sẽ thay đổi theo một cách không lường trước được và bạn sẽ phải viết mã không phù hợp với thiết kế ban đầu. Sau đó, bạn sẽ phải thực hiện một sự thay đổi gia tăng. Nếu bạn có một bộ kiểm thử đơn vị tốt và có kỹ năng tái cấu trúc, thì bạn sẽ có thể giữ mã được cấu trúc tốt khi bạn đáp ứng các yêu cầu mới.

"Được thiết kế tốt" là chủ quan

Gì "cũng được thiết kế" có nghĩa đối với bạn? cho Chủ sản phẩm? cho khách hàng?

Được "cũng được thiết kế " một mục tiêu của chủ sở hữu sản phẩm? mục tiêu của khách hàng? hay chỉ là bạn?

Là những gì bạn cho là "không được thiết kế tốt" vẫn đáp ứng mong đợi của Chủ sở hữu sản phẩm và khiến khách hàng hài lòng? Sau đó, đó là "thiết kế tốt" .

Đủ tốt và YAGNI

Không có gì trong hầu hết các phương pháp Agile nói về "được thiết kế tốt", bởi vì bất kỳ hệ thống nào mà Chủ sở hữu sản phẩm chấp nhận các câu chuyện là hoàn chỉnh và khách hàng tin rằng nó đáp ứng yêu cầu của họ là "được thiết kế tốt" .

Dự kiến các nhà phát triển là các chuyên gia và sẽ sử dụng thực tế các thực tiễn tốt nhất, các thiết kế và thành ngữ phù hợp để thực hiện các tính năng và câu chuyện.

Nếu bạn không bao giờ thực hiện đúng cách đó là vấn đề của nhà phát triển, nếu Chủ sở hữu sản phẩm yêu cầu mọi thứ trong thời gian ngắn hơn có thể được thực hiện, thì đó là đặc quyền của họ để làm điều này và bạn có trách nhiệm giáo dục họ về hậu quả dưới dạng câu chuyện nợ kỹ thuật .

Bánh quy

_{Phương pháp Agile có thể được viết ra, không phải là Phương pháp Agile. "- Jarrod Roberson}

SCRUM được coi là một khung các công cụ để quản lý toàn bộ vòng đời của một sản phẩm phần mềm. Nó không phải là một tập hợp cứng nhắc của mọi thứ, chỉ là một nơi tốt để bắt đầu và hy vọng cải thiện.

Hầu hết các cửa hàng tôi đã làm việc có những gì được gọi là Sprint ZERO, Sprints cho các thành viên cao cấp của nhóm để phác thảo một kiến ​​trúc tổng thể hoặc chủ đề của sản phẩm.

Những câu chuyện lớn hơn 20 thường được chia nhỏ cho đến khi chúng thực sự là một vài Câu chuyện 3 - 5 điểm. Một trong những câu chuyện này là, "Là một nhóm chúng tôi cần gặp để thảo luận về cách chúng tôi sẽ thiết kế tính năng này, để chúng tôi sẽ có ít nợ kỹ thuật nhất có thể trong thời gian quy định."

Nói chung là

Nói chung, một hệ thống "được thiết kế tốt" , đủ tốt và tuân theo YAGNI.

Agile và đặc biệt là SCRUM khi triển khai Agile liên quan nhiều hơn đến cách sản xuất sản phẩm một cách minh bạch nhất có thể cho Chủ sở hữu / Nhà tài trợ sản phẩm.

Nó không phải là về bất cứ điều gì thiết kế kỹ thuật / kiến ​​trúc khôn ngoan. Đó là một triết lý về cách tiếp cận phân phối phần mềm đáp ứng nhu cầu và mong đợi của khách hàng. Nếu không có những gì bạn gọi là các phần "được thiết kế tốt" , thì đó không phải là một thất bại, vì nó không phải là một phần cơ bản của triết lý.

Chúng tôi đã làm việc với scrum trong vài tháng và tôi muốn chia sẻ kinh nghiệm của mình về vấn đề của bạn.

Vài tháng trước tôi đã được trao một phần lớn để thực hiện. Tôi đã có tất cả các thông số kỹ thuật sẵn sàng, vì vậy tôi phải thực hiện các tính năng mới cho phù hợp. Nhiệm vụ là mất khoảng 5-6 tuần (theo ước tính của tôi). Tôi đã dành tuần đầu tiên chỉ làm việc về thiết kế. Nhiệm vụ hơi phức tạp: có một đối tượng chính, như tôi đã kết luận từ thông số kỹ thuật, có 15 trạng thái khác nhau và UI phải có các hành vi khác nhau cho mỗi trạng thái.

Tôi đã thiết kế toàn bộ quy trình công việc, và cấu trúc DB và các lớp sau đó.

Tôi không thấy bất kỳ cách tiếp cận nào khác trong trường hợp của tôi. Nếu tôi lao vào mã hóa ngay lập tức, tôi sẽ có một mớ hỗn độn khó chịu cuối cùng - gần như không thể duy trì và cực kỳ khó thực hiện bất kỳ thay đổi nào nữa. Nhưng những thay đổi đã đến trong 2 tuần tới, vì vậy tôi phải làm lại mã. Điều này bây giờ thật dễ dàng, với thiết kế suy nghĩ ban đầu. Điều này tiết kiệm thời gian, tiền bạc và thần kinh của chúng ta.

Sau trải nghiệm này, tôi hoàn toàn chắc chắn rằng nó đáng để tạo ra một thiết kế có thể chấp nhận được ngay từ đầu, hơn là hy vọng rằng với một phép màu nào đó bạn sẽ có nó ở cuối.

Tầm nhìn là 20-20. Nếu bạn có thông tin tại xử lý khi bắt đầu dự án để tìm ra toàn bộ và sau đó viết mã trong một vài tuần, tôi khuyên bạn nên làm điều đó.

Bạn không cung cấp đủ tín dụng cho tất cả những hiểu biết bạn đã đạt được, các phương pháp đã thử và thất bại / phải thay đổi và khả năng của khách hàng / người dùng tăng lên để cung cấp đủ yêu cầu tín dụng.

Tại sao bất cứ ai có lịch sử các dự án thác nước thành công, sẽ chuyển sang một phương pháp nhanh nhẹn?

Bạn luôn cần bức tranh lớn hơn về mục tiêu cuối cùng nên là gì và những tính năng nào được dự định thực hiện và khi nào, trước khi bạn bắt đầu một dự án. Làm việc trên các câu chuyện như các nhiệm vụ nguyên tử là yêu cầu rắc rối. Bạn cần ghi nhớ các yêu cầu trong tương lai càng nhiều càng tốt.