プロジェクトによって異なりますが、小規模なプロジェクトで単独で作業している場合は、開発の一環として技術調査と調査を行うのが最適です。そして、アジャイルの一部ではありませんが、もちろんアジャイル方法論を使用して、これに何らかの制御を追加することができます。ただし、これによりプロセスの予測や時間ボックスの予測が非常に困難になります。完全にあなたのものである小さなプロジェクトで一人で作業している場合は、うまくいくかもしれませんが、もっと速く、要件を学習しながら展開していきます。途中で適切な原則を使用し、一貫性があれば、それほどリファクタリングする必要はありません。
職場では、カンバン、スクラム、およびより伝統的なウォーターフォールアプローチを使用しています。プロジェクトによっては、明確に定義された事前要件のある複雑な開発はアジャイルに最適ではないことがわかりますが、多くの人は反対します。
アジャイルプロジェクト(最も単純なものを除く)で作業を開始する前に、ドキュメントを作成します。モックアップ(UIに焦点を当てている場合)、一連の要件、および機能仕様があります。
開発では、機能仕様から技術仕様を作成するよう求められます。このプロセス中に、技術を特定し、必要な先行研究を行います。このプロセスは、要件/機能仕様のギャップを確認する機会を与え、そのような決定を行うための経験とシステム知識を持つ人々に前もって大きなテクノロジー決定を与えるので、私にとって非常に重要に思えます。
ただし、重要なことは、機能仕様は箇条書きのリストである可能性があり、技術仕様は通常モデルであり、いくつかの箇条書きとテクノロジーステアリングがあり、場合によっては3ページまたは4ページしかない場合があります。
アジャイルプロジェクトを実行しているときでも、ドキュメントを作成します。
- すべてのドキュメントにはコストがかかります。
- 高レベルの要件の移動と不適切な定義に対する開発にはコストがかかります。
- 上記の適切なバランスは、プロジェクト、文化、人々によって異なります。
- 文書化ジャストインタイムで、文書が古くなります。
- かろうじて十分/十分に文書化します。
- これらのドキュメントの保守や更新は行っておらず、それらに多大な労力を費やしていません。彼らは小さい。私たちはそれらを捨てることを期待しています。
- テクノロジーの決定、漠然とした要件、アーキテクチャなどの大きな未知の要素を事前に解決します。
- 始める前に私たちは何を開発しているか知っています。
- 私たちは、開発者がドキュメントに関する情報に基づいた決定を下し、問題について話し合うことを信頼しています。
- ドキュメントを介したコミュニケーションを大切にしています。関係者全員が頻繁にコミュニケーションを取ることを期待しています。
- システム(概要)は、開発中ではなく、開発前にではなく、開発後に文書化します。
アジャイルプロセスに小さな滝があるのがわかります。
一人で作業する場合は、事前のモデル(図!)を作成し、技術を操作して選択します。次に、高レベルの要件に関するこの概念がある場合は、先に進み、俊敏な反復的な方法で開発しますが、適切な原則とあなたが行くにつれて一貫性を保ち、あなたはあなたが行くにつれてより少ない、より多くのリファクタリングを行う必要があります。
しかし、一般的に、実際のコストがかかる(趣味ではない)場合は、コードを書く前に何を開発しているのかを知ってください。十分な情報に基づいて、開発中に考え方を変えてください。そして、あなたのプロジェクトは大きく方向を変えるかもしれませんが、良い、明確に定義された基盤から始めます。