Tài liệu thiết kế như một phần của Agile

Tại nơi làm việc của tôi, chúng tôi phải đối mặt với một thách thức trong việc "nhanh nhẹn" quá thường xuyên có nghĩa là "yêu cầu mơ hồ, tiêu chí chấp nhận xấu, chúc may mắn!" Chúng tôi đang cố gắng giải quyết điều đó, như một nỗ lực cải tiến chung.

Vì vậy, như một phần của điều đó, tôi đề xuất rằng chúng tôi tạo tài liệu thiết kế, trên và vượt mức câu chuyện của người dùng, phản ánh chính xác kết quả điều tra sơ bộ về tác dụng của một tính năng nhất định trong hệ thống và bao gồm các câu trả lời cho các câu hỏi mà chúng tôi có hỏi kinh doanh.

Có một tiêu chuẩn hiệu quả cho việc này?

Chúng tôi hiện đang phải đối mặt với tình huống một tính năng mới có thể ảnh hưởng đến nhiều khu vực trong hệ thống "quả bóng lớn" của chúng tôi và các ước tính đang bắt đầu tăng lên do khoản nợ kỹ thuật này. Hy vọng các quy trình thiết kế chu đáo hơn có thể giúp đỡ.

"yêu cầu mơ hồ, tiêu chí chấp nhận xấu, chúc may mắn!"

yup, đây là loại yêu cầu tương tự mà bạn nhận được ngay cả khi bạn cố gắng đóng chúng xuống! (ví dụ, một tài liệu yêu cầu 10.000 mà khách hàng chính phủ mất 4 năm để tạo ra vẫn còn đầy mâu thuẫn, mơ hồ và thậm chí là những tuyên bố mâu thuẫn trong nội bộ. bạn có bao giờ nghĩ rằng bạn sẽ có thể nhận được bất cứ điều gì không mơ hồ?)

Vì vậy, ... cách nhanh nhẹn đã được phát minh để hiểu rằng điều này sẽ xảy ra và làm việc với nó thay vì cố gắng chống lại nó.

Bạn bắt đầu bằng cách hỏi "bạn muốn gì" và khách hàng trả lời với "một cái gì đó giống như thế này". Bạn làm một số công việc và sau đó quay lại với khách hàng và nói "đây có giống như những gì bạn muốn không?", Và khách hàng thường nói "có nhưng ..." khi bạn hỏi "bạn muốn gì".

Cuối cùng, bạn sẽ có được chính xác những gì khách hàng muốn, ngay cả khi họ không biết đó là gì! (địa ngục, họ không bao giờ biết những gì họ muốn, không chính xác).

Trong nhóm của chúng tôi, kể từ khi nhanh nhẹn, chúng tôi cũng đã cố gắng thu hẹp và hiểu chỉ cần bao nhiêu tài liệu thực sự cần thiết. Tôi có thể chia sẻ với bạn những gì chúng tôi đã học được cho đến nay.

Trước bất cứ điều gì khác, hãy chắc chắn đọc bài viết này về Tài liệu Agile / Lean . Đọc rất tốt

Thứ hai, tôi đặc biệt khuyên bạn nên xem xét lại việc sản xuất tài liệu thiết kế sau khi làm việc sơ bộ về câu chuyện. Chúng tôi đã thử điều đó trước đây và nó đã được chứng minh là một sự lãng phí. Ở giữa bản phát hành cuối cùng, chúng tôi đã quyết định cập nhật các tài liệu thiết kế CHỈ SAU KHI mã cho câu chuyện được gửi. Và bây giờ tôi đang nghĩ rằng điều đó là quá sớm.

Bạn cần tự hỏi tại sao bạn muốn làm tài liệu thiết kế trước khi mã hóa. Đối với chúng tôi đây là những lý do:

1. Chúng tôi là một đội cần phải hiểu câu chuyện sẽ ảnh hưởng đến thiết kế như thế nào.
2. Có tài liệu thiết kế đã được chứng minh là hữu ích khi các thành viên mới (hoặc tạm thời) tham gia nhóm hoặc khi quay lại mã mà không ai làm việc trong hơn một năm. Vì vậy, chúng rất hữu ích cho bộ nhớ tổ chức để giúp hiểu cách thức hoạt động của mã.
3. Tài liệu thiết kế rất hữu ích cho các kỹ sư bảo trì, những người có thể cần khắc phục sự cố mã sau khi phát hành.

Để đáp ứng (1) bạn không cần phải tạo một tài liệu thiết kế thực tế. Nhóm của bạn vẫn nên có một giai đoạn thiết kế trước khi mã hóa, nhưng giai đoạn đó có thể đơn giản như một phiên 15 phút trước bảng trắng hoặc khăn ăn. Bạn không cần phải tạo một tài liệu thực tế sẽ mất hàng giờ (nếu không phải vài ngày) để viết chỉ để thảo luận về các thay đổi thiết kế.

(2) hoặc (3) không cần thiết trong quá trình phát triển câu chuyện hiện tại và nhiều khả năng chúng sẽ không cần thiết cho một số lần lặp lại tiếp theo.

Ngoài ra, hãy nhớ rằng mỗi khi một thành viên trong nhóm viết / cập nhật tài liệu thiết kế, đó là thời gian mà mã không được viết. Khi bạn viết tài liệu trước mã thực tế, gần như 100% khả năng chúng sẽ được yêu cầu cập nhật vì một khi bạn bắt đầu thiết kế mã hóa luôn luôn bị thay đổi. Và ngay cả khi bạn viết tài liệu thiết kế sau mã, như nhóm của chúng tôi đã học, tái cấu trúc từ các câu chuyện tiếp theo vẫn làm thay đổi thiết kế.

Vì vậy, những gì tôi muốn giới thiệu:

1. Ban đầu tạo ra các thiết kế / mô hình tạm thời đủ để nhóm của bạn có thể có một cuộc trò chuyện thông minh trước khi mã hóa. Đừng mong giữ những thứ này và đừng lãng phí thời gian vào việc chính thức hóa chúng.
2. Chỉ tạo tài liệu thiết kế chính thức nếu ai đó sẽ cần nó (tức là nhóm của bạn có nhu cầu thực sự về bộ nhớ tổ chức)
3. Chỉ sản xuất tài liệu thiết kế về mã đã được ổn định. Không có điểm nào cố gắng ghi lại một mô-đun luôn được thay đổi trong mỗi lần lặp.
4. Sản xuất tài liệu thiết kế mô tả đầy đủ một mô-đun (hoặc một phần của sản phẩm). Trước đây, chúng ta thường viết các tài liệu thiết kế ghi lại các thay đổi phải thực hiện. Những tài liệu đó hoàn toàn vô giá trị ngay khi phát hành xong.
5. Giữ tài liệu ở mức rất cao. Nếu bạn viết 20 trang bao gồm kiến ​​trúc và thiết kế cấp cao, tài liệu đó sẽ thực sự được người khác đọc và b) sẽ giúp mọi người làm quen với bố cục chung của mã của bạn. Để biết chi tiết mọi người có thể đi thẳng vào mã. Nếu bạn viết 700 trang đặc tả chi tiết, chúng hầu như sẽ không khớp với thực tế, quá nhiều cho bất kỳ ai đọc và cuối cùng bạn sẽ phải duy trì và cập nhật 700 trang thay vì 20 bất cứ khi nào có thay đổi trong tương lai.

"Thần chú" Agile không phải là không có tài liệu hoàn toàn.

Câu thần chú Agile là thích " Phần mềm làm việc hơn tài liệu toàn diện ". Nhưng lưu ý bit ở dưới cùng của bản tuyên ngôn.

Đó là, trong khi có giá trị trong các mục ở bên phải , chúng tôi đánh giá các mục ở bên trái nhiều hơn. "

Chú Bob có một chính sách tốt cho tài liệu

Sản xuất không có tài liệu trừ khi nó cần ngay lập tức và quan trọng .

Bạn nói đúng rằng một số người sử dụng Agile như một cái cớ để không sản xuất tài liệu, nhưng đó là Agile tồi. Đó là bỏ qua các bit mà tôi đã nhấn mạnh trong các trích dẫn ở trên.

Tất cả những gì đã nói, khi bạn nói 'chúng tôi hiện đang phải đối mặt với một tình huống mà một tính năng mới có thể tác động đến nhiều khu vực trong hệ thống "quả bóng lớn" của chúng tôi, nếu bạn sẽ trở thành Agile, bạn cần phải làm gì đó về điều này.

Khi bạn có tài liệu của mình, hãy sử dụng nó để mô đun hóa mã của bạn. Bằng cách đó, bạn loại bỏ nhu cầu dài hạn để duy trì tài liệu (điều này sẽ không xảy ra) bằng cách loại bỏ nhu cầu dài hạn đối với tài liệu.

I E. Làm cho nhu cầu ngay lập tức và đáng kể.

Điều nhanh nhẹn là các nỗ lực tài liệu thực sự phải được điều khiển bởi nhóm scrum. Nếu các nhà phát triển không cảm thấy tài liệu bên ngoài là đủ cho nhu cầu của họ, câu chuyện của người dùng sẽ bị chặn cho đến khi họ làm điều đó. Nếu doanh nghiệp cảm thấy các nhà phát triển không sản xuất tài liệu đầy đủ, chủ sở hữu sản phẩm khăng khăng biến nó thành một phần của tiêu chí chấp nhận. Vì điều này, tôi thực sự đã tìm thấy tài liệu của chúng tôi tập trung và hiệu quả hơn kể từ khi chuyển sang scrum.

Chúng tôi sử dụng VersionOne để theo dõi các câu chuyện của người dùng, nhưng tôi chắc rằng các phương pháp của chúng tôi áp dụng cho các hệ thống khác. Nó cho phép bạn đính kèm tập tin vào câu chuyện của người dùng. Chúng tôi đã tìm thấy rằng đó là một nơi cực kỳ hữu ích để đặt tài liệu thiết kế.

Đối với một ví dụ hoạt động thực sự tốt cho chúng tôi, chúng tôi có nhu cầu thử nghiệm thiết kế bảng mạch mới càng nhanh càng tốt sau khi nguyên mẫu được chế tạo. Chúng tôi đã tạo hai câu chuyện của người dùng cho mọi thứ cần thử nghiệm: một để thiết kế thử nghiệm và một để thực hiện thử nghiệm. Một tiêu chí chấp nhận cho câu chuyện thiết kế là quy trình thử nghiệm đã được ghi lại đầy đủ trong câu chuyện thực hiện.

Khi chúng tôi đến phần thử nghiệm, nó diễn ra suôn sẻ hơn tôi từng thấy. Chúng tôi chỉ mở câu chuyện người dùng và làm theo quy trình từng bước. Các tài liệu chính xác là những gì chúng ta cần để hoàn thành câu chuyện, không hơn không kém.

Chúng tôi có một câu chuyện khác trong hồ sơ tồn đọng của chúng tôi chỉ để cải thiện tài liệu cho một con chip mà chúng tôi sử dụng, để giúp các đội khác dễ dàng lấy nó cho các sản phẩm của họ.

Tóm lại, nếu bạn cảm thấy tài liệu của mình bị ảnh hưởng, giải pháp cũng dễ như tạo một câu chuyện người dùng riêng cho nó và / hoặc biến nó thành một phần của tiêu chí chấp nhận.

Khi bạn nói về các yêu cầu kém, điều đầu tiên tôi nghĩ đến là đảm bảo bạn có các tiêu chí kiểm tra. Nếu có thể hãy tạo một số trường hợp kiểm tra tự động có thể sử dụng lại cho các phần hiện có của hệ thống. Một khi mọi người trở nên thoải mái với điều đó, sau đó chuyển sang viết các trường hợp thử nghiệm trước khi mã được viết. Các trường hợp kiểm tra tốt có thể làm rất nhiều để ghi lại các hành vi của một hệ thống.

Đối với những tài liệu thiết kế cụ thể sẽ sử dụng, như những gì khác đã nói, nó phụ thuộc rất nhiều vào nhu cầu của nhóm và nhiệm vụ tiếp theo họ sẽ thực hiện là gì. Khi có thể hãy cố gắng sử dụng các công cụ có thể tạo tài liệu (từ mã) mà bạn sẽ sử dụng hoặc tạo mã từ tài liệu. Bảo trì tài liệu có thể trở nên khá tốn kém, vì vậy hãy chọn một cách khôn ngoan khi bạn kiên trì một tài liệu thiết kế.

Cá nhân tôi đã thành công tốt đẹp với các sơ đồ lớp được tạo ra từ các trường hợp kiểm thử mã và fitnesse. Nhóm in ra một vài sơ đồ lớp, thực hiện một phiên đánh dấu với chủ sở hữu sản phẩm và sau đó lập một ước tính từ đó. Theo như fitnesse, tôi may mắn được làm việc với một vài chủ sở hữu sản phẩm, những người rất giỏi trong việc thể hiện những gì họ muốn trong bảng tính, sau đó được chuyển đổi thành bảng cho fitnesse.