アジャイルプロセス：文書化の方法と内容
少し前に、私が働いている会社は開発プロジェクトを第三者に外部委託していた。彼らはソリューションの開発にアジャイル手法を採用しました。しかし、ドキュメントを求められたとき、彼らはそれがwikiに組み込まれたり、スプリントの一部として組み込まれたりして、それが必要であるとだけ言ったでしょう。
彼らは、プロジェクトチームの1人を除いて全員がプロジェクトの完了時に出発しました。プロジェクトのwikiサイトは、年間サブスクリプションが満期になると閉鎖されました。
彼らが去ったとき、彼らは彼らと一緒に開発されたものについての知識と理解のほとんどを取りました。
だから私は2つの主な質問があります。
- これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？
- 開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？
これはアジャイルにとっては正常ですか、それとも書きたくないという言い訳ですか？
私の理論は、アジャイルが非常に速く、特に スクラム が広がった理由です。 （会社全体ではなく）アジャイルで身を守りたいチームが多すぎます。問題は、多くの場合、方法論が経営陣によってそれらに対して使用されていることです（彼らも自分自身を保護したいためです）。
これは、アジャイルがまったく機能しないことを意味しますか？もちろん、これはアジャイルがいくつかの一般的な問題を解決するのに役立つことを意味するだけではありませんが、それでも他のすべてを担当しています。そして多くの場合、アジャイルはその会社のそのチームには適していません。
開発要件、設計、主要な決定、およびコンテキストを記録するためのアジャイルプロジェクトの文書化に関する業界の基準は何ですか？
要するに：
チームは必要なドキュメントの量を定義する必要があります
彼らはドメインを知っており、彼らは専門家であり、さらに重要なことに彼らは物事を構築しています！
Agile Manifesto のWorking software over広範囲なドキュメンテーションはそれを意味します。
私は決してアジャイルの専門家ではありませんが、私の答えは次のとおりです。
特定のドキュメントを要求するストーリー/要件はありましたか？そうでない場合、ある程度は要求されたものを取得するため、これは問題の一部です。言い訳ですが、ここで「普通」とはどういう意味かと思います。何かを正常にするのはアジャイルの原則に従うものの過半数ですか、それとも予想されるプロセス全体の一部ですか？これらは私が見ることができる2つのビューです。編集：ドキュメントの場合と同じように、チームの大多数が行うことは何でもないと思いますが、それは私の推測です。
興味深いかもしれないいくつかのリンクは、これで私ができる最高のことです：
アジャイルには マニフェスト にいくつかの特定のポイントがあります。
包括的なドキュメントを介して動作するソフトウェア
つまり、右側の項目には価値がありますが、左側の項目にはさらに価値があります。
TDDテスト、受け入れテスト、またはその他の単体テストのセットを残しましたか？彼らは、アプリケーションがどのように機能し、どのように機能することが期待されるかを文書化するだけでなく、開発されたものを使用する方法のサンプル実装を提供することもできます。
彼らはただひどいです。アジャイルはドキュメントがないという意味ではないと思います。少なくともアプリケーションの説明を追跡する必要があります。彼らのウィキのエクスポートを取得することは素晴らしいことでしたか、誰かがサービス料を受け取ることを許可しました。
いくつかの試みほど詳細ではありません。理論は、タイムクランチのときに仕様がコードと一致しなくなったというものです。そのため、コードを記述し、それを詳細に定義しようとしない十分なドキュメントがあります（コードをいくつかの疑似言語化されたテキスト/図コードで記述してから、実際のコードで記述します）。
あなたの問題はアジャイルとは何の関係もありません。彼らはあなたが要求した文書を作成するべきでした。プロジェクトの管理は不十分でした。
私の経験では、常にドキュメントを要求する人がたくさんいます（私はそのうちの1人でした）が、実際には、誰もそれを作成する時間や意欲はありません。時々努力がありますが、作成されたドキュメントは通常、非常に早く古くなり、システムの実際の機能と同期しなくなります。これは、たとえあなたがドキュメンテーションを持っているとしても、誰もそれをチェックすることを本当に気にしなくて、彼らが単にその正確さを信用しないという状況につながります。
実際の正確さと信頼できる情報を得るには、コードとテストを読み取ることができるかどうかにかかっています。システムの機能を（再）発見したい顧客は、いつでもプログラマーにインタビューし、プログラマーに問い合わせることができます。プログラマーはその後、システムについての事実を（ある程度調査して）提示できます。
適切なドキュメントを作成することは簡単ではなく、かなりのコストがかかる可能性があります。次に、オーディエンスについて疑問に思うかもしれません。誰のためのドキュメントで、何を提供するつもりですか。
機能、ユーザーストーリー、およびテストケースの説明どこかが最低限必要です。 ITはプロジェクトのReadMeファイルにある場合もあれば、ソースコードのコメントにある場合もあれば、設計ドキュメントにある場合もあります。上記のすべてかもしれません...それともMIAかもしれません！