Làm thế nào để bạn đối phó với thiết kế trong Scrum?

Làm thế nào để bạn đối phó với thiết kế trong Scrum? Bạn vẫn có tài liệu thiết kế được viết tốt cho mỗi lần lặp scrum? Bạn chỉ cần làm các ghi chú thiết kế có sơ đồ UML? Hay bạn chỉ có mã nhận xét tốt?

Mỗi lần lặp có thể liên quan đến việc thay đổi thiết kế, vì vậy tôi chỉ muốn biết làm thế nào mọi người nắm bắt được điều này để các nhà phát triển mới có một công việc dễ dàng để hiểu tên miền và lên tàu càng nhanh càng tốt.

chỉ vì nó là scrum không có nghĩa là mọi thứ thay đổi mỗi lần chạy nước rút!

Scrum là về làm những gì cần thiết (nhưng không còn nữa) . Bạn vẫn cần phải làm thiết kế và bạn vẫn cần phải làm tài liệu. Nó chỉ là số tiền không cố định cũng như làm thế nào để làm điều đó.

Một phần của kế hoạch mỗi lần chạy nước rút là quyết định những gì cần phải làm. Nếu một cái gì đó trong backlog cần được thiết kế bởi vì nó tác động đến những thứ khác thì bạn cần thêm một nhiệm vụ cụ thể cho các quy trình thiết kế và thực hiện điều đó trước khi thực hiện nhiệm vụ.

Tôi có rất nhiều điều để nói về chủ đề này. Tôi đã thấy nhiều trường hợp các công ty / nhóm / người nói rằng họ đang sử dụng phương pháp Agile cho phần mềm nhưng thực tế, họ muốn gặt hái những phần thưởng mà phương pháp Agile hứa hẹn mà không tuân thủ các nguyên tắc.

Để lặp lại nhanh chóng để làm việc, bạn nên thực hiện phát triển theo hướng kiểm tra (tôi đã dừng nói rằng bạn phải làm TDD một cách miễn cưỡng). Trong TDD, các thử nghiệm của bạn thể hiện thiết kế và mục đích của mã (khi họ nói "mã là tài liệu", điều họ nên nói là "các thử nghiệm là tài liệu"). Bằng cách viết các bài kiểm tra đơn vị thể hiện sự hiểu biết của bạn về tính năng trong tay, bạn đang nói rõ ràng những gì bạn tin rằng mã cần phải làm. Sau đó, bạn viết mã mà làm điều đó. Sau đó, bạn tái cấu trúc mã đó để tuân thủ các nguyên tắc kiến ​​trúc tốt "Red-Green-Refactor".

Chạy thử nghiệm đơn vị của bạn với mỗi lần đăng ký (hoặc thậm chí trước mỗi lần đăng ký) xác minh rằng mã mới bạn đã viết không phá vỡ chức năng dự kiến ​​trong một số lĩnh vực khác của ứng dụng. Điều này cung cấp một mạng lưới an toàn cho phép bạn thay đổi mã với sự từ bỏ tàn nhẫn. Khi sự hiểu biết của bạn về các yêu cầu trong tầm tay tăng lên, bạn có thể sửa đổi bài kiểm tra để phản ánh kiến ​​thức mới đó. Thiết kế thực sự nằm trong các bài kiểm tra Đơn vị. Mọi thứ khác (bao gồm cả mã không được bảo hiểm) là một lời nói dối.

Đây là một số khuyến nghị đọc

• Mã sạch
• Nguyên tắc, mô hình và thực tiễn phát triển phần mềm Agile
• Lập trình viên thực dụng

Đây là những nơi tốt để bắt đầu tìm hiểu làm thế nào để thực sự tiếp cận phát triển nhanh.

Scrum là một phương pháp quản lý dự án, không phải là phương pháp phát triển phần mềm. Scrum thường được sử dụng cùng với phương pháp Agile. Trong đó có câu trả lời của bạn.

Không có nhiều thiết kế phía trước như yêu cầu thường xuyên thay đổi. Vì vậy, thiết kế xuống cấp độ thường là một sự lãng phí thời gian. Tuy nhiên, nó có thể là giá trị phác thảo các quyết định kiến ​​trúc cấp cao hơn.

Vấn đề với việc làm các tài liệu thiết kế nhiệm vụ nặng nề là chúng đã lỗi thời gần như ngay khi chúng được tạo ra. Vì vậy, những gì hoạt động tốt nhất thường là tài liệu cấp cao không có khả năng thay đổi hoàn toàn trong một khoảng thời gian ngắn.

Scrum là một mô hình lặp và tăng dần dựa trên các giá trị nhanh . Điều đó có nghĩa là bạn không có một giai đoạn thiết kế riêng biệt. Ý tưởng là bạn nên liên tục xử lý thiết kế, giống như bạn liên tục xử lý phân tích, thực hiện, thử nghiệm và tích hợp trong suốt dự án.

Bạn cần một chút lập kế hoạch cho việc này để làm việc. Tham gia cuộc họp lập kế hoạch nước rút , nơi nhóm ước tính các nhiệm vụ cho lần chạy nước rút phía trước. Hầu hết mọi người không nhận ra đây không chỉ là một cuộc họp ước tính, mà còn là một nỗ lực thiết kế. Ví dụ: một tác vụ có thể là "Thêm mã cho mẫu xe mới". Bạn chưa thể ước tính điều này, bạn cần biết thêm một chút. Vì vậy, nhóm thảo luận về thiết kế và đưa ra một giải pháp rộng rãi ("Xe con?") Và thêm vào đó như một lời nhắc nhở cho nhiệm vụ. Bạn hiếm khi cần nhiều hình thức hơn thế. Bây giờ bạn có một ý tưởng làm thế nào để giải quyết vấn đề. Bạn chưa có tất cả các chi tiết và điều đó là tốt, bạn biết đủ về thiết kế để có thể ước tính thoải mái. Không cần phải tạo bất kỳ sơ đồ nào cả (tại thời điểm này).

Đối với tài liệu vật lý thực tế , tôi khuyên bạn nên tạo sơ đồ tổng quan hệ thống trên tường để mọi người cùng xem. Tổng quan chỉ cần có các lớp và mô-đun quan trọng nhất đi kèm và hiếm khi phải cập nhật. Ngoài ra, tạo một vài sơ đồ trạng thái cho các lớp quan trọng nhất trong hệ thống là rất hữu ích. Rắc một vài sơ đồ trình tự chọn của các trường hợp sử dụng điển hình để giúp mọi người dễ dàng xem nhanh mọi thứ được kết nối như thế nào. Tôi giả sử bạn có thể tạo sơ đồ phân cấp lớp từ mã của mình, để vấn đề đó được giải quyết dễ dàng.

Lưu ý rằng tất cả các sơ đồ được tạo ra sau khi thực hiện thực tế. Điều này phù hợp với "phần mềm làm việc trên tài liệu toàn diện" và thiết kế chỉ trong thời gian.

Và vâng, mã có thể đọc được chắc chắn là tài liệu.

Kiến trúc tổng thể của dự án và thiết kế cấp cao sẽ được thực hiện bên ngoài các nhóm scrum khi chủ sở hữu dự án đang tạo ra các câu chuyện.

Cần có đủ một thiết kế tổng thể được viết ra dưới bất kỳ hình thức nào để giúp thấy mối quan hệ giữa các câu chuyện và kỳ vọng của khách hàng.

Một số thiết kế cần thiết cho mỗi câu chuyện sẽ được thực hiện trong kế hoạch và đàm phán với chủ sở hữu sản phẩm trong quá trình lập kế hoạch.

Phần lớn nỗ lực thiết kế cho một câu chuyện sẽ được thực hiện trong giai đoạn nước rút.

Nếu câu chuyện không được xác định đủ để ước tính, thì một hộp thời gian có thể được đặt sang một bên trong lần chạy nước rút hiện tại để thực hiện đủ công việc thiết kế để có thể tạo ra một câu chuyện phù hợp cho lần chạy nước rút sau.

Hiểu biết của tôi là bạn làm một thiết kế cấp cao hơn với các yêu cầu phía trước mà bạn thu thập được khi bắt đầu dự án. Bạn tài liệu thiết kế này tốt.

Sau đó, khi bạn thực sự thực hiện yêu cầu, bạn thay đổi thiết kế cấp thấp hơn khi bạn cần, nhưng bạn tránh thay đổi thiết kế cấp cao hơn.

Chà, đó là cách nó được giải thích với tôi năm phút trước ...

Ngày nay có một sự phân chia trong cộng đồng Eclipse giữa các công cụ UML truyền thống tập trung vào MDD, trong đó mô hình điều khiển mã / phát triển và Omondo xem xét rằng các lần lặp sẽ thúc đẩy quá trình phát triển và chắc chắn không chỉ mô hình.

Tôi đồng ý với họ vì MDD là tào lao trong khi UML thực sự là một cách tuyệt vời vì tiêu chuẩn hóa để giao tiếp với các thành viên khác trong nhóm.