アジャイルプロセス：文書化する方法と内容

少し前、私が働いている会社は開発プロジェクトを第三者に外部委託していた。彼らはソリューションの開発にアジャイル手法を採用しました。しかし、ドキュメントを求められたとき、彼らはそれがwikiに組み込まれたり、彼らのスプリントの一部として組み込まれたりして、それが必要であるとだけ言ったでしょう。

彼らは、プロジェクトチームの1人を除いて全員がプロジェクトの完了時に出発しました。プロジェクトのwikiサイトは、年間サブスクリプションが満期になると閉鎖されました。

彼らが去ったとき、彼らは彼らと一緒に開発されたものについての知識と理解のほとんどを取りました。

だから私は2つの主な質問があります。

1. これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？
2. 開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？

これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？

私の理論では、アジャイルが非常に速く、特にスクラムが急速に普及するのはそのためです。（会社全体ではなく）自分自身を保護するためにアジャイルを望んでいるチームが多すぎます。問題は、多くの場合、方法論が経営陣によって彼らに対して使用されていることです（彼らも自分自身を保護したいためです！）。

これは、アジャイルがまったく機能しないことを意味しますか？もちろん、これは、アジャイルがいくつかの一般的な問題を解決するのに役立つことを意味しますが、それでも他のすべてを担当しています。そして多くの場合、アジャイルはその会社のそのチームには適していません。

開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？

要するに：

チームは必要なドキュメントの量を定義する必要があります

彼らはドメインを知っており、彼らは専門家であり、さらに重要なことに彼らは物事を構築しています！

これが、アジャイルマニフェストの包括的なドキュメントに対する実用的なソフトウェアの意味です。

TDDテスト、受け入れテスト、またはその他の単体テストのセットを残しましたか？彼らは、アプリケーションがどのように機能し、どのように機能することが期待されるかを文書化するだけでなく、開発されたものを使用する方法のサンプル実装を提供することもできます。

私は決してアジャイルの専門家ではありませんが、ここに私の答えの試みがあります：

1. 特定のドキュメントを要求するストーリー/要件はありましたか？そうでない場合、ある程度は要求されたものを取得するため、これは問題の一部です。言い訳ですが、ここで「普通」とはどういう意味かと思います。何かを正常にするのはアジャイルの原則に従うものの過半数ですか、それとも予想されるプロセス全体の一部ですか？これらは私が見ることができる2つのビューです。編集：ドキュメントに関しては、チームの大多数が同じことをすることはないと思いますが、それは私の推測です。

2. 興味深いかもしれないいくつかのリンクは、これで私ができる最高のことです：

   • アジャイル/リーンドキュメントのベストプラクティス
   • アジャイルおよび技術ドキュメント

アジャイルにはマニフェストにいくつかの特定のポイントがあります。ここで、これとメモを一緒に指摘します。

包括的なドキュメントに対応する実用的なソフトウェア

つまり、右側の項目には価値がありますが、左側の項目にはさらに価値があります。

彼らはただひどいです。アジャイルがドキュメントをまったく意味しないと私は信じていません。少なくともアプリケーションの説明を追跡する必要があります。彼らのウィキのエクスポートを取得することは素晴らしいことでしたか、誰かがサービス料を受け取ることを許可されていました。

いくつかの試みほど詳細ではありません。理論は、タイムクランチのときに仕様がコードと一致しないことです。そのため、コードを記述し、それを詳細に定義しようとしない十分なドキュメントがあります（コードをいくつかの疑似言語化されたテキスト/図コードで記述してから、実際のコードで記述します）。

あなたの問題はアジャイルとは何の関係もありません。彼らはあなたが求めた文書を作成しているはずです。プロジェクトの管理は不十分でした。

機能、ユーザーストーリー、テストケースの説明は、少なくともどこかにある必要があります。ITはプロジェクトのReadMeファイルにある場合もあれば、ソースコードのコメントにある場合もあれば、設計ドキュメントにある場合もあります。上記のすべてかもしれません...またはMIAかもしれません！

私の経験では、常に多くの人がドキュメントを要求しています（私はその1人でした）が、実際には、誰もドキュメントを作成する時間や意欲はありません。時々努力がありますが、作成されたドキュメントは通常、非常に早く古くなり、システムの実際の機能と同期しなくなります。これは、たとえあなたがドキュメンテーションを持っているとしても、誰もそれをチェックすることを本当に気にしなくて、彼らが単にその正確さを信頼しないという状況につながります。

実際の正確性と信頼性の高い情報を得るには、コードとテストを読み取ることができることがほとんどです。自分のシステムの動作を（再）発見したい顧客は、いつでもプログラマーにインタビューしてクエリを発行できます。プログラマーは、システムについて（ある程度の調査を行って）事実を提示できます。

適切なドキュメントを作成することは簡単ではなく、かなりのコストがかかる可能性があります。次に、オーディエンスについて疑問に思うかもしれません。誰のドキュメントであり、何を提供するつもりですか。