アジャイルドキュメンテーション:スピードと知識保持のバランス
公開: 2022-03-11それらの生成に関連するさまざまなドキュメント、アーティファクト、およびプロセスは、ウォーターフォールモデルの主要なシンボルの一部です。 リーンから借りて、アジャイルは多くのドキュメントを「無駄」と見なし、開発ライフサイクルを合理化するために根絶する必要があります。
多くのプロジェクトマネージャーにとって、ウォーターフォールフェーズがどのようにスプリントに変換されるかを理解するのはそれほど難しいことではありません。同じ作業が実行されます。 別の方法で構成されているだけです。 ただし、ほとんどのドキュメントを削除すると、まったく異なる作業方法が強調されるため、飲み込むのが難しくなります。 それには、制御の手綱を緩め、未知のものを受け入れ、配信チームがその場で決定を下せるようにする必要があります。
ドキュメントへの従来のアプローチは挑戦されています
ウォーターフォール手法では、プロジェクト要件の文書化とソリューションの詳細化に多くの時間が費やされます。 このプロセスは、要件が完全に明確であり、キャプチャおよびベースライン化されたものから何も変わらないと確信している場合に機能します。 しかし、過去数十年のほとんどの企業の経験は、これがほとんど真実ではないことを示しています。 今日の世界では、変化のペースは非常に動的であるため、文書化フェーズを完了するまでに、クライアントのニーズは大幅に変化します。
アジャイルの焦点は、物事を成し遂げ、利害関係者に付加価値を与えることにあります。 これは、モデルが周辺機器や、クライアントに直接かつ即座に付加価値をもたらさないアクティビティでの作業を思いとどまらせるように構築されています。
ウォーターフォールとアジャイルのドキュメント
各企業には異なるレベルのドキュメントがあり、プロジェクトレベルでも異なる場合があります。 しかし、ウォーターフォールおよびアジャイルプロジェクトでの典型的な文書化手順は次のようになります。
滝 | アジャイル |
ほとんどの場合、文書化は必須です。 ドキュメントが完成しない限り、作業は進行しません。 | 作業を開始するのに十分なだけ理解できる基本的なドキュメントのみをお勧めします。 |
ドキュメントは長いレビュープロセスを経ており、複数の関係者による承認が必要です。 | 正式なレビューと承認のプロセスはなく、プロジェクトマネージャーが主要な意思決定者です。 |
標準化されたテンプレートに従う必要があります。 | ドキュメント用の正式なテンプレートはありません。 代わりに、ベストプラクティスが使用されます。 |
プロジェクト憲章、ビジョンステートメント、ビジネス要件ドキュメント、機能要件と非機能要件、高レベル設計(HLD)および低レベル設計(LLD)ドキュメントなど、さまざまなタイプのドキュメントがさまざまなフェーズで必要になります。 | 今後のスプリントで機能を提供するために必要なドキュメントのみが必要です。 |
すべてのドキュメントが絡み合っているため、ドキュメントの変更は困難です。 | ドキュメントの変更ははるかに簡単です。 |
多数のドキュメントを管理するためのシステムまたはプロセスが必要です。 | ドキュメントは最小限であるため、管理が簡単です。 |
ドキュメンテーションの事例
Waterfallは、ドキュメントへのより厳密なアプローチを促進しますが、これは過度に思えるかもしれません。 しかし、これを「無駄」として却下する前に、強力な文書化手順を持つことのいくつかの利点があります。
戦略的思考の機会
計画に失敗した人は、失敗することを計画します。 ドキュメントを使用すると、プロジェクトマネージャーは座って物事を考え、最良の解決策を考え出す必要があります。 人々は、包括的なドキュメントよりも機能するソフトウェアのアジャイルの価値を、ドキュメントが不要であることを意味すると誤解することがあります。 その後、彼らは市場に急いで行きます。インターコムの製品担当副社長であるポール・アダムスは、壁に物を投げて、何がくっつくのかを見ていると説明しています。 ソリューションの設計、計画の作成、アクションの検討-これらのアクティビティは、頭に浮かぶすべての機能のアイデアを開発するのではなく、時間を節約することで価値を生み出します。
UXと機能の一貫性
企業が数人の創設者から数百人または数千人の従業員に成長するにつれて、多くの異なるチームが同じまたは関連する製品に取り組み始めます。 チームAは、自分たちが取り組んでいることはチームBが取り組んでいることとは関係がないと考えるかもしれませんが、エンドユーザーにとってはすべて同じ製品です。 クロスファンクショナルチームが独自のことを行う代わりに、ユーザーエクスペリエンスと機能レベルに関する明確なドキュメントにより、ユーザーフローのバラバラを回避できます。
ドキュメントはユーザーガイドに変換できます
ウォーターフォールでは、ソリューションとその使用方法の詳細に多くの時間が費やされています。 忠実度の高いデザインの写真は、フロントエンド開発者向けに作成されています。 これらのアセットはすべて、最初から作成するよりも、内部または外部のユーザーガイドに変換するために必要な作業が少なくて済みます。
アジャイルがドキュメントの必要性をどのように削減するか
文書化を義務付ける言い訳として繰り返し出てくる要因は、従業員の離職率です。 マネージャーは、人々が去り、新しいものが彼らに取って代わるために参加するとき、制度的知識を失うことを恐れます。 彼らはどのように実装されているのか、そしてそれがどのように機能するのかを知るのでしょうか? 彼らが追いつくのにどれくらい時間がかかりますか? 現在のチームには、新しいチームメンバーを手に入れるための帯域幅がありますか?
優れたドキュメントによって、ほとんど独立して作業する新入社員が迅速にスピードアップできるようになることが期待されています。 ただし、アジャイルは本質的に、コラボレーション手法を通じてドキュメントの必要性を減らし、同時にオンボーディングの時間を短縮します。 アジャイルがドキュメントの必要性を減らすいくつかの方法があります。
製品チームとアジャイルチームメンバー間の定期的なやり取り
アジャイルマニフェストは、「プロセスとツールを介した個人と相互作用」を促進します。 プロジェクト中に要件が変更される傾向があり、新しいアイデアが生まれるため、アジャイルは、継続的な更新が必要な記述されたアーティファクトに依存するのではなく、ソースから直接要件を明確にすることを保証します。

グルーミングと計画はタスクを区画化します
バックロググルーミングとスプリント計画は、機能を特定の実装可能な部分に分解します。これらの部分は、簡単に理解でき、独立して作業できます。 これにより、プロジェクト全体の全体像をまだ完全には理解していないにもかかわらず、新入社員が早い段階で生産性を発揮できる機会が生まれます。
ユーザーストーリーは効率的なドキュメントを提供します
ユーザーストーリーのシンプルな形式により、プロジェクトマネージャーは、すべてのチームメンバー間で共通の理解を生み出すための最低限の要件を把握できます。 ユーザーストーリーがスプリントにならなくても、このドキュメントアーティファクトを作成する無駄は非常に少ないです。 ユーザーストーリーがスプリントに移行すると、それらを具体化して、ワイヤーフレーム、デザイン、受け入れ基準などの他の必要な情報で補足することができます。このプロセスにより、非常に効率的なドキュメント配信が可能になり、非常に使い捨てで、最も適切な開発段階で作成されます。
コードドキュメントの必要性の削減
ペアプログラミングやコードレビューなどの手法は、チーム全体、特に新しいチームメンバーに技術的な知識を広める絶え間ない機会を生み出します。 絶え間ないフィードバックは、どこかのドキュメントですぐに古くなるのではなく、新しい状況に適応する柔軟性も備えた共通の理解につながります。
アジャイルセレモニー
毎日のスタンドアップ、スプリントレビュー、および回顧は、電子メールやドキュメントに頼るのではなく、問題を解決し、対面で意思決定を行うための十分な機会を生み出します。 すべての式典の時間枠が限られているため、使用される可能性が低い場合でも、すべてを文書化することに時間を費やすのではなく、最も重要な情報のみが優先されます。
上記のすべては、直接的または間接的にドキュメントを削減し、ドキュメントの不足によって実際に何も失われないようにしながら、プロジェクトの目標の達成を優先します。
ドキュメントへのハイブリッドアプローチ
一部の企業は、アジャイル設定であっても、まだいくつかのドキュメントを持っていることを好みます。 アジャイルは規範的ではありません。プロジェクトごとに異なり、対処する必要のある一連の固有の状況があるためです。
以下は、アジャイルをより時間のかかるドキュメントの方法と組み合わせる方法の例です。
UMLとアジャイルの組み合わせ
非常に構造化され、システムを視覚化するためのエンティティが定義されている統一モデリング言語(UML)などの標準モデリング言語の使用を検討してください。 これにより、コンテンツを非常にシンプルに保ち、必要なものに焦点を当て、書き言葉の使用を最小限に抑えることができます。 StarUMLやDraw.ioなどのツールは、とりわけ便利なオプションです。
コードドキュメンテーションジェネレータ
もう1つのアプローチは、クラスの詳細、メソッドの詳細、パラメーターの使用法、依存関係などの一部として、より構造化された詳細なコメントを導入することにより、コードをより読みやすくすることです。 ソースコードから有用なドキュメントを生成するプロセスを自動化する多くのツールがあり、それらはドキュメントジェネレータと呼ばれます。 それらは、一般的なものからプログラミング言語固有のものまでさまざまです。
詳細なデザインとUXドキュメント
ワイヤーフレーム、モックアップ、ユーザーフロー図、シーケンス図などを使用して要件を定義すると、プロジェクトフローを簡素化するだけでなく、何を開発する必要があるかを技術チームに明確に示すことができます。 設計ドキュメントは、さまざまなレベルのより厳格なドキュメントを作成するための優れた方法です。 これらのタスクのために選択できるさまざまなワイヤーフレーミングおよびUXツールがあります。
プロジェクト管理ツールはドキュメントを自動化します
より強力なプロジェクト管理と、JIRA、Confluence、Asana、Basecampなどの関連ツールは、すべてのプロジェクト関連情報を1か所に保持する方法を提供します。 タスクは、リンク、タグ付け、ネスト、およびさまざまなチームメンバーへの割り当てが可能であり、チームメンバーはコメントを残して問題を報告できます。 これらのすべてのアクションは、これらのツールを適応させる柔軟性に加えて、ほとんどまたはまったく労力をかけずに大量のドキュメントを作成できます。
さらに、歴史的に、ドキュメントのニーズの一部は、レポート要件に由来します。 利害関係者は、チームのパフォーマンスまたはその他の関連するメトリックへのアクセスを望んでいます。 プロジェクト管理ツールを使用すると、プロジェクトの進行状況を反映し、ツール内の関連ドキュメントにリンクするカスタムダッシュボードとビューを簡単に自動化できます。
ドキュメント管理はバランスをとる行為です
アジャイルマニフェストの作成者は、「包括的なドキュメントよりも機能するソフトウェア」を重視していると書いています。 ただし、「右側のアイテムには価値がありますが、左側のアイテムには価値があります」という免責事項も追加されています。 一部のドキュメントは明らかに価値を提供するため、アジャイルはすべてのドキュメントを削除することを提案していません。 それは単に、プロジェクトの状況に応じて、開発の進行を大きく妨げることなく、必要な場合にのみソフトウェアの動作とドキュメントの追加を優先する必要があることを示唆しています。
プロジェクトマネージャーは、ドキュメンテーションに費やす時間を減らすことと、機能するソフトウェアの提供により多くの時間を費やすことと、長期的な成功のために何らかの形式のドキュメンテーションが必要な場所を実際に把握することとの間のバランスを取る必要があります。