SDLCの*ドキュメント*に代わるものはありますか？
誰ももう何も印刷しないので、実際のプロジェクトドキュメント（つまり、フォーマットされたテキストのモノリシックな部分）の概念は、改善できるように思われます。ドキュメントの問題は、Wordバージョンの非互換性、テンプレートの無限のいじり、人々がそれらを読むことを嫌うという事実などです...
コンテンツの管理に役立つウェブサイトのように、何らかの構造を課しながら、個々のビットへのリンクなどを許可する代替手段があるかどうか疑問に思っています。しかし、サイトは必要なときに「ドキュメント」を吐き出すことができなければならないと思います（ファイリング、質問するスポンサーの表示など）
たとえば、「プロジェクト計画書」の代わりに、関係者とのリソースだけで作業し、次に他の関係者とスケジューリングを行い、他の関係者とパッケージを作成できるプロジェクト計画サイトを想像しています。
SRSドキュメントの代わりに、要件の管理、優先順位、フェーズの割り当てなどを可能にするサイトもありますが、必要に応じて最終的に実際のSRSドキュメントを生成できます。
考え？ここでのコンテキストは小規模で機敏なチームですが、進捗状況を示すためにドキュメントを作成する必要がある場合があります。私たちは確かに、Rationalや最近大企業で使用されているもののようなものを保証するのに十分な大きさではありません。
ターゲットは小さなアジャイルチームなので...
生きているドキュメントを促進するフォーマットを好む。印刷されたドキュメントがなくなることはありません。秘訣は、印刷する必要があるものとそうでないものを特定することです。適切なアーティファクトを形式化するためにエネルギーを費やします。
これを支援するいくつかのツールがあります。最高の2つは、WikiとSharePointです。 MediaWikiは、利害関係者と一緒に使用したり、スナップショットをアーカイブしたりできる特定のページから作成されたPDFをエクスポートすることもできます。また、MediaWikiから直接エクスポートされたハイパーリンクレポートを使用することを好むクライアントもいます。レポートへのエントリポイントを提供するindex.htmlタイトルページを作成する必要がありました。
また、軽量の「オーラルヒストリー」の実践を利用することもできます。これらのタイプのプラクティスのいくつかの例には、次のものが含まれます...
- ホワイトボード-非公式に最適 情報ラジエーター オンザフライで構築
- ポストイット
- 大きな紙
- また、 Refreshed System Metaphor や Architecture Haik などのの本質をキャプチャするように促すプラクティスにも注意してください。必要とされていること。
これらの各例では、写真を撮ったり、ビデオを作成してWikiにアップロードしたり、SharePointで保持したりできます。
私は一般的に、Word文書はソフトウェア開発において一般的に悪いことだと思います。それらはかさばり、不器用で、バージョン管理がうまくいかず、検索するのが面倒です。
一般に、バージョンが適切なドキュメント形式を優先するようにしてください。 Word、Excel、PNGなどのバイナリの重い形式は、バージョン管理のサポートが不十分です。つまり、変更の追跡は困難で面倒です。
多くのドキュメントはWikiに保存する方が適切です。限られたフォーマットは、人々に単純なフォーマットを強いる傾向があります。ヘッダー、リスト、セクション。複雑なことは何もありません。結局のところ、よく隠されたテンプレートファイルを更新する代わりに、フォーマットを1か所で一括変更できます。衒学的な文書のフォーマットを扱うことほど、人々の時間を無駄にすることはありません。
画像でさえ、一部のWikiはBalsamiqモックアップをサポートしています。 PNGが必要な場合でも、PNGを使用したWikiはWordファイルよりもはるかに優れた選択肢です。
プロジェクトの計画については、アジャイル手法をサポートするツールを調査する必要があります。私はJiraをうまく使用しましたが、ニーズに合ったツールを見つけるために周りを見回す価値があります。厳格な設計ドキュメントは一般的に悪い考えです。通常、MS Projectのような特別なツールが必要であり、変更を更新して共有することは困難です。上記のように、バージョンも不十分です。
スクラムツールを使用すると、関連する要件のリストを定義し、エピック/ユーザーストーリーアイテムから詳細を提供するウィキにリンクできます。したがって、ウィキはチケットの内容をバージョン管理できます。ほとんどのスクラムツールはガントチャートを生成しませんが、バーンダウンチャートを生成します。ガントチャートは、現実を定義するという点で記述的であり、バーンダウンチャートは、実際に進捗状況を測定し、将来について予測できるという点で記述的です。言うまでもなく、バーンダウンチャートの方がはるかに便利です。
まず第一に、人々はまだ常にものを印刷します-それは本当にあなたの特定の企業文化に依存します。
とは言うものの、ウィキを試してみてください。そうすれば、人々はドキュメントの履歴を持ちながら、コラボレーション、更新、心のコンテンツへのリンクを行うことができます。 Atlassianは、バグ/プロジェクト追跡ツールであるJiraと非常にうまく統合されたConfluenceと呼ばれる素晴らしい製品を作成しています。または、無数の無料のものを試すこともできます。
ドキュメントの代わりに、このように使用されるwikiを見たことがあります。他にもたくさんありますが、彼らはConfluenceを使用していたと思います。はい、印刷用のドキュメントをその場で作成できると思います。
考慮すべきもう1つのことは、Word文書以外にどのような「文書」があるかということです。スプレッドシートとVisioファイルには実際にはWikiの類似物がないため（少なくとも私が知る限りでは）、同様のファイルを多用する場合は、それらをWikiページに添付して参照する必要があります。 。大したことではありませんが、ドキュメントの読み取り方法が変わる可能性があるため、注意が必要です。
問題はデータベースの問題であり、Wordプロセス、スプレッドシート、またはWikiで解決するべきではありません。
作成者IT は、この問題を処理するように設計された優れたドキュメント管理ツールです。問題は独自のフォーマットであるため、それにコミットする必要があります。しかし、あなたがコミットしている場合、それはあなたが求めたすべてとはるかに多くのことをします。何か違うものを提供するかもしれませんが、それは企業の値札が付いていると思います。