Quy trình Agile: làm thế nào và những gì cần được ghi lại?

Cách đây một thời gian, công ty tôi làm việc đã thuê ngoài một dự án phát triển cho bên thứ ba. Họ sử dụng các thực hành nhanh nhẹn trong việc phát triển giải pháp. Tuy nhiên, khi được hỏi về tài liệu, họ sẽ chỉ nói rằng nó được yêu cầu vì nó được kết hợp trong wiki hoặc là một phần trong các lần chạy nước rút của họ.

Họ đã rời đi khi hoàn thành dự án, với tất cả trừ một trong nhóm dự án. Trang wiki dự án hiện đã bị đóng cửa sau khi đăng ký hàng năm đến hạn.

Khi họ rời đi, họ đã lấy hầu hết kiến ​​thức và sự hiểu biết về những gì đã được phát triển cùng với họ.

Vì vậy, tôi có 2 câu hỏi chính;

1. Đây có phải là bình thường cho nhanh nhẹn hoặc chỉ là một cái cớ cho việc không muốn viết nó?
2. Các tiêu chuẩn công nghiệp cho tài liệu trong các dự án nhanh để ghi lại các yêu cầu phát triển, thiết kế, các quyết định chính và bối cảnh là gì?

Đây có phải là bình thường cho nhanh nhẹn hoặc chỉ là một cái cớ cho việc không muốn viết nó?

Lý thuyết của tôi là tại sao agile lan truyền rất nhanh, đặc biệt là scrum . Tôi đã thấy quá nhiều đội muốn nhanh nhẹn để tự bảo vệ mình (thay vì toàn bộ công ty). Vấn đề là trong nhiều trường hợp, phương pháp này được quản lý sử dụng để chống lại họ (vì họ cũng muốn tự bảo vệ mình!).

Điều này có nghĩa là nhanh nhẹn không hoạt động? Tất nhiên là không, điều này chỉ có nghĩa là nhanh nhẹn giúp bạn giải quyết một vài vấn đề phổ biến, nhưng bạn vẫn chịu trách nhiệm cho tất cả những người khác. Và trong nhiều trường hợp, agile chỉ không phù hợp với nhóm đó trong công ty đó.

Các tiêu chuẩn công nghiệp cho tài liệu trong các dự án nhanh để ghi lại các yêu cầu phát triển, thiết kế, các quyết định chính và bối cảnh là gì?

Trở nên ngắn:

Nhóm nên xác định số lượng tài liệu họ cần

Họ biết tên miền, họ là chuyên gia và quan trọng hơn là họ xây dựng mọi thứ!

Đó là những gì phần mềm làm việc trên tài liệu toàn diện trong Tuyên ngôn Agile có nghĩa.

Có phải họ đã để lại cho bạn một bộ Bài kiểm tra TDD, Bài kiểm tra chấp nhận hoặc Bài kiểm tra đơn vị khác không? Họ làm tốt công việc ghi lại cách thức một ứng dụng hoạt động và dự kiến ​​sẽ hoạt động, cũng như cung cấp một triển khai mẫu về cách sử dụng những gì đã được phát triển.

Mặc dù tôi không phải là chuyên gia Agile, nhưng đây là nỗ lực của tôi để trả lời:

1. Có một câu chuyện / yêu cầu yêu cầu tài liệu cụ thể? Nếu không, thì đây là một phần của vấn đề khi bạn nhận được những gì được yêu cầu ở một mức độ nào đó. Đó là một cái cớ và tôi có thể tự hỏi ý của bạn là "bình thường" ở đây. Có phải chỉ phần lớn những người tuân theo các nguyên tắc Agile làm cho một cái gì đó bình thường hoặc nó là một phần của quá trình tổng thể nên được mong đợi? Đó là hai quan điểm tôi có thể thấy cho nó. EDIT: Tôi nghi ngờ có bất cứ điều gì mà phần lớn các đội làm điều đó giống nhau khi nói đến tài liệu, nhưng đó là một phỏng đoán về phía tôi.

2. Một vài liên kết có thể được quan tâm, là về điều tốt nhất tôi có thể làm về điều này:

   • Thực tiễn tốt nhất cho tài liệu Agile / Lean
   • Tài liệu kỹ thuật và nhanh nhẹn

Agile có một số điểm cụ thể trong bản tuyên ngôn , trong đó tôi chỉ ra điểm này cùng với ghi chú:

Phần mềm làm việc trên tài liệu toàn diệ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.

Họ thật kinh khủng. Tôi không tin nhanh nhẹn có nghĩa là không có tài liệu nào cả. Họ ít nhất nên theo dõi các mô tả ứng dụng. Việc xuất khẩu wiki của họ sẽ rất tuyệt hoặc cho phép người khác nhận phí dịch vụ.

Nó có thể không chi tiết như một số nỗ lực. Lý thuyết là, khi trong một thời gian khủng hoảng, thông số kỹ thuật không còn phù hợp với mã nào nữa. Vì vậy, bạn có đủ tài liệu để viết mã và không cố gắng xác định chi tiết (Sắp xếp giống như viết mã trong một số mã giả-văn bản / mã-sơ đồ-mã và sau đó trong mã thực tế.).

Vấn đề của bạn không liên quan gì đến Agile. Họ nên đã tạo ra các tài liệu mà bạn yêu cầu. Dự án được quản lý kém.

Cần có một số mô tả về các tính năng, câu chuyện của người dùng và các trường hợp thử nghiệm ở đâu đó , tối thiểu. CNTT có thể nằm trong các tệp ReadMe trong các dự án, nó có thể là trong các nhận xét về mã nguồn, nó có thể nằm trong các tài liệu thiết kế; nó có thể là tất cả những điều trên ... hoặc có thể là MIA!

Theo kinh nghiệm của tôi, luôn có rất nhiều người yêu cầu tài liệu (tôi đã từng là một trong số họ) nhưng trong thực tế, không ai có thời gian hay mong muốn tạo ra chúng. Đôi khi có những nỗ lực, nhưng tài liệu được tạo ra thường bị lỗi thời rất nhanh và không đồng bộ với chức năng thực sự của hệ thống. Điều này dẫn đến một tình huống mà ngay cả khi bạn có tài liệu, không ai thực sự bận tâm kiểm tra nó vì đơn giản là họ không tin vào độ chính xác của nó.

Để có độ chính xác và thông tin đáng tin cậy, có khá nhiều khả năng đọc mã và kiểm tra. Một khách hàng muốn (tái) khám phá những gì hệ thống của anh ta luôn có thể phỏng vấn và truy vấn một lập trình viên sau đó có thể trình bày (với một số điều tra) sự thật về hệ thống.

Tạo tài liệu tốt là không đáng kể và có thể khá tốn kém. Thứ hai, người ta có thể tự hỏi về khán giả, tài liệu cho ai và nó dự định cung cấp những gì?