Hãy xem xét một cách tiếp cận nhanh. Ý tôi là, nếu bạn có tài nguyên thời gian và kỹ năng viết tuyệt vời để viết ra mọi quyết định thiết kế mà các bạn đưa ra cùng với lý lẽ của họ, chỉ cần ghi chép lại mọi thứ. Nói một cách thực tế, tôi cho rằng bạn không ở vị trí như vậy. Một cách tiếp cận nhanh có thể giúp với một thách thức chính đối với tài liệu về các lý do: bạn thường không biết những lý do nào là quan trọng cho đến sau này.
Hãy tiếp cận vấn đề từ quan điểm toàn diện. Các bạn có lý do cho quyết định của bạn. Họ bị mắc kẹt trong squishyware ngay bây giờ, bộ não của đội. Mặc dù số lượng tài liệu tín dụng nhận được, việc lưu trữ hợp lý trong sqishyware không phải là quá tệ. Chúng ta thực sự rất giỏi trong việc ghi nhớ những điều quan trọng. Đó là lý do tại sao mọi tập đoàn lớn đều có "kiến thức bộ lạc", ngay cả khi những tập đoàn đó tìm cách ghi lại tất cả những kiến thức của bộ lạc đó.
Bây giờ bạn có một vấn đề. Bạn đang thấy rằng sqiushyware không giữ được các lý do đủ tốt. Tốt cho bạn để nhận ra có một vấn đề, và xác định rằng nó cần phải được giải quyết! Đó không phải lúc nào cũng là một bước dễ dàng! Vì vậy, chúng tôi khá chắc chắn rằng giải pháp là giảm tải một số lý do đó vào tài liệu. Tuy nhiên, điều đó là không đủ. Chúng tôi không bao giờ có thể quên nửa sau của câu đố, đó là tải lại lý do vào squishyware khi bạn cần đưa ra quyết định. Tôi đã thấy rất nhiều đội làm tài liệu cho mọi thứ như điên, nhưng nội dung thực sự không được tổ chức để giúp đưa ra quyết định tốt, vì vậy cuối cùng họ quên mất những lý do mặc dù họ đã viết ra .
Vì vậy, bạn có một quá trình hai bước. Bạn cần lấy lý do ra khỏi squishyware và vào tài liệu. Sau đó, bạn cần đảm bảo rằng tài liệu được tổ chức đủ tốt để đưa hợp lý trở lại vào squishyware khi bạn cần nó! Bây giờ tôi nghĩ rằng chúng ta có đủ một tuyên bố vấn đề để nhận ra những thách thức sẽ như thế nào. Khi bạn đang ghi chép tài liệu, bạn thường không biết ai sẽ xem xét nó sau này, hoặc những gì họ đang tìm kiếm. Tương tự như vậy, khi bạn nhìn lại tài liệu, bạn thường không biết bạn đang tìm kiếm điều gì (tốt nhất bạn có thể biết khi nào).
Vì vậy, một công ty lớn có thể cố gắng xử lý việc này trong hai khối lớn. Đầu tiên họ có thể phát triển các yêu cầu dựa trên những gì mọi người cần khi họ nghiên cứu tài liệu. Sau đó, họ sử dụng những yêu cầu đó để xây dựng một quy trình phát triển tài liệu nói trên. Và, nếu tôi dám nói như vậy, thì mọi người đều phàn nàn vì hầu như không ai biết chính xác tài liệu sẽ trông như thế nào vào ngày đầu tiên. Tài liệu này luôn không đầy đủ và các nhà phát triển luôn phàn nàn rằng quy trình này quá nặng nề.
Thời gian để đi nhanh nhẹn.
Lời khuyên của tôi sẽ là bắt đầu một nỗ lực nhanh nhẹn để cải thiện quy trình tài liệu của bạn: toàn bộ chín thước từ squishyware đến tài liệu và trở lại squishyware. Nhận ra rằng bạn sẽ mất một số thông tin vì quy trình của bạn không hoàn hảo, nhưng điều đó không sao vì bạn vẫn đang cố gắng tìm ra quy trình! Bạn sẽ bỏ lỡ nhiều hơn nếu bạn cố gắng tạo một kích thước phù hợp với tất cả các giải pháp.
Một vài thông tin cụ thể mà tôi muốn xem: * Khám phá tài liệu không chính thức. Tài liệu chính thức là tuyệt vời, nhưng tốn thời gian của nó. Một trong những mục đích của tài liệu là phát hành thông tin từ squishyware của nhà phát triển và đưa nó lên giấy. Tài liệu không chính thức giữ cho chi phí làm việc ở mức tối thiểu.
- Chấp nhận các định dạng tài liệu không đáng tin cậy. Không có gì sẽ đúng ngay lần đầu tiên. Tốt hơn là lấy dữ liệu và tìm ra cách làm cho nó đáng tin cậy sau này. Ví dụ: bạn có thể ghi lại các lý do của mình trong một khối <rationale> </ rationale> hoặc một cái gì đó tương tự, điều này sẽ giúp bạn dễ dàng thu thập dữ liệu đó sau này. Lưu trữ các lý do trong một câu chuyện người dùng, bây giờ, là tốt!
- Không bao giờ quên giá trị của tổ chức. Tìm hiểu làm thế nào bạn, với tư cách là một nhóm, muốn tìm kiếm các lý do trong tài liệu và cố gắng ghi lại điều đó. Mỗi đội sẽ có một quy trình khác nhau. Ở một trong những đội của tôi, chúng tôi không bao giờ có thể tìm thấy chiếc vé có lý do trên đó ngay lập tức. Những gì chúng ta có thể làm là tìm thấy một dòng mã mà quan trọng, làm một
svn blameđể tìm hiểu khi nó thay đổi và lý do tại sao, sau đó đi xem vé. Khi chúng tôi đã ở đó, chúng tôi thường đặt tất cả các lý do chúng tôi cần ngay trên vé. Điều đó chỉ làm việc cho chúng tôi, tìm ra những gì làm việc cho bạn.
- Tài liệu hữu cơ có thể phát triển theo thời gian. Rất hiếm khi các nhà phát triển biết được những lý do nào là quan trọng nhất vào ngày họ cần để viết nó. Chúng ta thường tìm ra cái nào quan trọng sau này. Nếu bạn có một quy trình chải chuốt cho tài liệu cho phép các nhà phát triển quản lý khu vườn hợp lý nhỏ của riêng họ, thì những tài liệu quan trọng sẽ nổi lên trên bề mặt. Thậm chí quan trọng hơn, lý trí có thể thay đổi. Bạn có thể nhận ra rằng hai thay đổi khác nhau, với hai lý do khác nhau, thực sự được mô tả tốt nhất bởi một lý do duy nhất phù hợp với cả hai. Bây giờ có ít nội dung hơn giữa bạn và các quyết định!