アジャイル

アジャイルドキュメント：スピードと知識保持のバランス

それらの生成に関連するさまざまなドキュメント、アーティファクト、およびプロセスは、滝モデル。リーンから借りたアジャイルは、開発ライフサイクルを合理化するために根絶する必要のある多くのドキュメントを「無駄」と見なしています。

多くのプロジェクトマネージャーにとって、ウォーターフォールフェーズがどのようにスプリントに変わるかを理解するのはそれほど難しいことではありません。同じ作業が達成されます。別の方法で編成されているだけです。ただし、ほとんどのドキュメントを削除すると、まったく異なる作業方法が強調されるため、飲み込むのが難しくなります。それには、制御の手綱を緩め、未知のものを受け入れ、配信チームがその場で決定を下せるようにする必要があります。

新しい出会い系サイト2015無料

ドキュメントへの従来のアプローチは挑戦されています

ウォーターフォール手法では、プロジェクト要件の文書化とソリューションの詳細化に多くの時間が費やされます。このプロセスは、要件が完全に明確であり、キャプチャおよびベースライン化されたものから何も変わらないと確信している場合に機能します。しかし、過去数十年のほとんどの企業の経験は、これがほとんど真実ではないことを示しています。今日の世界では、変化のペースは非常に動的であるため、文書化フェーズが完了するまでにクライアントのニーズは大幅に変化します。

アジャイルの焦点は、物事を成し遂げ、利害関係者に付加価値を与えることにあります。これは、モデルが周辺機器や、クライアントに直接かつ即座に付加価値をもたらさないアクティビティでの作業を思いとどまらせるように構築されています。

ウォーターフォールとアジャイルのドキュメント

各企業には異なるレベルのドキュメントがあり、プロジェクトレベルでも異なる場合があります。しかし、ウォーターフォールおよびアジャイルプロジェクトでの典型的な文書化手順は次のようになります。

滝	アジャイル
ほとんどの場合、文書化は必須です。ドキュメントが完成しない限り、作業は進行しません。	作業を開始するのに十分なだけ理解できる基本的なドキュメントのみをお勧めします。
ドキュメントは長いレビュープロセスを経ており、複数の関係者による承認が必要です。	正式なレビューと承認のプロセスはなく、プロジェクトマネージャーが主要な意思決定者です。
標準化されたテンプレートに従う必要があります。	ドキュメント用の正式なテンプレートはありません。代わりに、ベストプラクティスが使用されます。
プロジェクト憲章、ビジョンステートメント、ビジネス要件ドキュメント、機能要件と非機能要件、高レベル設計（HLD）および低レベル設計（LLD）ドキュメントなど、さまざまなタイプのドキュメントがさまざまなフェーズで必要になります。	今後のスプリントで機能を提供するために必要なドキュメントのみが必要です。
すべてのドキュメントが絡み合っているため、ドキュメントの変更は困難です。	ドキュメントの変更ははるかに簡単です。
多数のドキュメントを管理するためのシステムまたはプロセスが必要です。	ドキュメントは最小限であるため、管理が簡単です。

ドキュメンテーションの事例

ウォーターフォールは、ドキュメントへのより厳密なアプローチを促進しますが、これは過度に思えるかもしれません。しかし、これを「無駄」として却下する前に、強力な文書化手順を持つことのいくつかの利点があります。

戦略的思考の機会

計画に失敗した人は、失敗することを計画します。ドキュメントを作成すると、プロジェクトマネージャーは座って物事を考え、最良の解決策を考え出す必要があります。人々は、包括的なドキュメントよりも作業ソフトウェアのアジャイルの価値を誤解して、ドキュメントが不要であることを意味することがあります。その後、彼らは急いで市場に参入し、インターコムの製品担当副社長であるポール・アダムズがとして説明します壁に物を投げて、何がくっつくのか見てみましょう。ソリューションの設計、計画の作成、アクションの検討-これらのアクティビティは、頭に浮かぶすべての機能のアイデアを開発するのではなく、時間を節約することで価値を生み出します。

UXと機能の一貫性

企業が数人の創設者から数百または数千人の従業員に成長するにつれて、多くの異なるチームが同じまたは関連する製品に取り組み始めます。チームAは、自分たちが取り組んでいることはチームBが取り組んでいることとは関係がないと考えるかもしれませんが、エンドユーザーにとってはすべて同じ製品です。部門の枠を超えたチームが独自のことを行う代わりに、ユーザーエクスペリエンスと機能レベルに関する明確なドキュメントにより、ユーザーフローのバラバラを回避できます。

ドキュメントはユーザーガイドに変換できます

ウォーターフォールでは、ソリューションとその使用方法の詳細に多くの時間が費やされています。忠実度の高いデザインの写真は、フロントエンド開発者向けに作成されています。これらのアセットはすべて、最初から作成するよりも、内部または外部のユーザーガイドに変換するために必要な作業が少なくて済みます。

アジャイルがドキュメントの必要性をどのように削減するか

文書化を義務付ける言い訳として繰り返し出てくる要因は、従業員の離職率です。マネージャーは、人々が去り、新しいものが彼らに取って代わるために参加するとき、制度的知識を失うことを恐れます。何が実装され、どのように機能するかをどのように知るのでしょうか。彼らが追いつくのにどれくらい時間がかかりますか？現在のチームには、新しいチームメンバーを手に入れるための帯域幅がありますか？

優れたドキュメントによって、ほとんど独立して作業する新入社員が迅速にスピードアップできるようになることが期待されています。ただし、アジャイルは本質的に、コラボレーション手法を通じてドキュメントの必要性を減らし、同時にオンボーディングの時間を短縮します。アジャイルがドキュメントの必要性を減らすいくつかの方法があります。

製品チームとアジャイルチームメンバー間の定期的なやり取り

ザ・アジャイルマニフェスト「プロセスとツールを介した個人と相互作用」を促進します。要件はプロジェクト中に変更される傾向があり、新しいアイデアが生まれるため、アジャイルは、定期的な更新が必要なアーティファクトに依存するのではなく、ソースから直接要件を明確にすることを保証します。

グルーミングと計画はタスクを区画化します

バックロググルーミングとスプリント計画は、機能を特定の実装可能な部分に分解します。これらの部分は、簡単に理解でき、独立して作業できます。これにより、プロジェクト全体の全体像をまだ完全には理解していないにもかかわらず、新入社員が早い段階で生産的になる機会が生まれます。

ユーザーストーリーは効率的なドキュメントを提供します

アジャイルドキュメントのユーザーストーリーテンプレート。

の単純な形式ユーザーストーリープロジェクトマネージャーは、すべてのチームメンバー間で共通の理解を生み出すための最低限の要件を把握できます。ユーザーストーリーがスプリントにならない場合でも、このドキュメントアーティファクトを作成する無駄は非常に少なくなります。ユーザーストーリーがスプリントに移行すると、それらを具体化して、ワイヤーフレーム、デザイン、受け入れ基準などの他の必要な情報で補足することができます。このプロセスにより、非常に効率的なドキュメント配信が可能になり、使い捨てで、最も適切な開発段階で作成されます。

コードドキュメントの必要性の削減

ペアプログラミングやコードレビューなどの手法は、チーム全体、特に新しいチームメンバーに技術的な知識を広める絶え間ない機会を生み出します。絶え間ないフィードバックは、どこかのドキュメントですぐに古くなるのではなく、新しい状況に適応する柔軟性も備えた共通の理解につながります。

アジャイルセレモニー

毎日のスタンドアップ、スプリントレビュー、回顧展は、メールやドキュメントに頼るのではなく、問題を解決し、対面で意思決定を行うための十分な機会を生み出します。すべての式典の時間枠が限られているため、使用される可能性が低い場合でも、すべてを文書化することに時間を費やすのではなく、最も重要な情報のみが優先されます。

上記のすべては、直接的または間接的にドキュメントを削減し、プロジェクトの目標の達成に優先順位を付け、ドキュメントの不足によって実際に何も失われないようにします。

ドキュメントへのハイブリッドアプローチ

一部の企業は、アジャイル環境であっても、ドキュメントを作成することを好みます。アジャイルは規範的ではありません。プロジェクトごとに異なり、対処する必要のある固有の状況が存在するためです。

以下は、アジャイルをより時間のかかる文書化方法と組み合わせる方法の例です。

UMLとアジャイルの組み合わせ

UML図の例

統一モデリング言語などの標準モデリング言語の使用を検討してください（ UML ）これは非常に構造化されており、システムを視覚化するためのエンティティが定義されています。これにより、コンテンツが非常にシンプルになり、必要なものに焦点が当てられ、書き言葉の使用が最小限に抑えられます。などのツール StarUML そして Draw.io 、とりわけ、便利なオプションです。

コードドキュメンテーションジェネレータ

もう1つのアプローチは、クラスの詳細、メソッドの詳細、パラメーターの使用法、依存関係などの一部として、より構造化された詳細なコメントを導入することにより、コードをより読みやすくすることです。ソースコードから有用なドキュメントを生成するプロセスを自動化する多くのツールがあり、それらは呼ばれますドキュメントジェネレータ。それらは、一般的なものからプログラミング言語固有のものまでさまざまです。

詳細設計とUXドキュメント

ワイヤーフレーム、モックアップ、ユーザーフロー図、シーケンス図などを使用して要件を定義すると、プロジェクトフローを簡素化するだけでなく、何を開発する必要があるかを技術チームに明確に示すことができます。設計ドキュメントは、さまざまなレベルのより厳格なドキュメントを作成するための優れた方法です。いろいろありますワイヤーフレーミングそして UX これらのタスクのために選択するツール。

プロジェクト管理ツールドキュメントの自動化

より強力なプロジェクト管理および関連ツールといった JIRA 、合流、アサナ、およびベースキャンププロジェクト関連のすべての情報を1か所に保持する方法を提供します。タスクは、リンク、タグ付け、ネスト、およびさまざまなチームメンバーへの割り当てが可能であり、チームメンバーはコメントを残して問題を報告できます。これらのすべてのアクションは、これらのツールを適応させる柔軟性に加えて、ほとんどまたはまったく労力をかけずに大量のドキュメントを作成できます。

さらに、歴史的に、ドキュメントのニーズの一部はレポート要件に由来します。利害関係者は、チームのパフォーマンスやその他の関連する指標へのアクセスを望んでいます。プロジェクト管理ツールを使用すると、プロジェクトの進行状況を反映し、ツール内の関連ドキュメントにリンクするカスタムダッシュボードとビューを簡単に自動化できます。

ドキュメント管理はバランスをとる行為です

アジャイルマニフェストの作成者は、「包括的なドキュメントよりも実用的なソフトウェア」を重視していると書いています。ただし、「右側のアイテムには価値がありますが、左側のアイテムには価値があります」という免責事項も追加されています。アジャイルは削除を提案しません すべて 一部のドキュメントは明らかに価値を提供するため、ドキュメント。それは単に、プロジェクトの状況に応じて、開発の進行を大きく妨げることなく、必要な場合にのみソフトウェアの動作とドキュメントの追加を優先する必要があることを示唆しています。

プロジェクトマネージャーは、ドキュメント化に費やす時間を減らすことと、動作するソフトウェアの提供により多くの時間を費やすことと、長期的な成功のために何らかの形式のドキュメントが必要な場所を実際に把握することとの間のバランスを取る必要があります。