Adaptive-software-development-practices
適応型ソフトウェア開発-実践
適応型ソフトウェア開発のプラクティスは、継続的な変化を規範として受け入れるライフサイクルを備えた継続的な適応の信念によって推進されています。
アダプティブソフトウェア開発ライフサイクルは以下に特化しています-
- 継続的な学習
- 向きを変える
- 再評価
- 不確実な未来を見つめる
- 開発者、管理者、および顧客間の強力なコラボレーション
適応SDLC
適応型ソフトウェア開発では、RADとソフトウェアエンジニアリングのベストプラクティスを組み合わせています。
- プロジェクトの開始。
- 適応サイクル計画。
- コンカレントコンポーネントエンジニアリング。
- 品質レビュー。
- 最終QAおよびリリース。
適応型ソフトウェア開発のプラクティスは、次のように説明できます-
上記のように、適応ソフトウェア開発のプラクティスは、次の3つのフェーズに分散しています-
- ** +推測-開始と計画
- プロジェクトの開始
- プロジェクト全体のタイムボックスを確立する
- 反復回数を決定し、それぞれにタイムボックスを割り当てます
- 反復ごとにテーマまたは目標を作成する
- 各反復に機能を割り当てる
- コラボレーション-同時機能開発
- 分散チームのコラボレーション
- 小規模プロジェクト向けのコラボレーション
- 大規模プロジェクトのコラボレーション
- 学習-品質レビュー
- 顧客の視点からの結果品質
- 技術的な観点からの結果の品質
- デリバリーチームとチームメンバーが活用しているプラクティスの機能
- プロジェクトのステータス
推測-開始と計画
適応ソフトウェア開発では、投機フェーズには2つのアクティビティがあります-
- 開始
- 計画中
スペキュレートには、開始および計画段階で繰り返し実行できる5つのプラクティスがあります。 彼らは-
- プロジェクトの開始
- プロジェクト全体のタイムボックスを確立する
- 反復回数を決定し、それぞれにタイムボックスを割り当てます
- 反復ごとにテーマまたは目標を作成する
- 各反復に機能を割り当てる
プロジェクトの開始
プロジェクトの開始には-
- プロジェクトのミッションと目的を設定する
- 制約を理解する
- プロジェクト組織の設立
- 要件の特定と概要
- 初期サイズとスコープの推定を行う
- 主要なプロジェクトリスクの特定
プロジェクト開始データは、速度を主要な側面と見なして、予備のJADセッションで収集する必要があります。 開始は、小規模から中規模のプロジェクトの場合は2〜5日間、大規模なプロジェクトの場合は2〜3週間の集中的な作業で完了できます。
JADセッション中に、要件を十分に詳細に収集して、機能を識別し、オブジェクト、データ、またはその他のアーキテクチャモデルの概要を確立します。
プロジェクト全体のタイムボックスの確立
範囲、機能セットの要件、見積もり、およびプロジェクト開始作業から生じるリソースの可用性に基づいて、プロジェクト全体のタイムボックスを確立する必要があります。
ご存じのように、投機は推定を放棄しませんが、推定が間違っている可能性があることを受け入れることを意味します。
反復とタイムボックス
プロジェクト全体の範囲と不確実性の程度に基づいて、反復回数と個々の反復の長さを決定します。
中小規模のアプリケーションの場合-
- 反復は通常4〜8週間です。
- 一部のプロジェクトは、2週間の反復で最適に機能します。
- プロジェクトによっては、8週間以上かかる場合があります。
自分に合った時間を選択してください。 反復の回数と各反復の長さを決定したら、各反復にスケジュールを割り当てます。
テーマまたは目的を開発する
チームメンバーは、反復ごとにテーマまたは目標を作成する必要があります。 これは、スクラムのスプリントゴールに似ています。 各イテレーションは、製品の機能を実証できる一連の機能を提供し、顧客が製品を見えるようにして、レビューとフィードバックを可能にする必要があります。
繰り返しの中で、ビルドは統合機能を有効にし、製品を開発チームに見えるようにするために、できれば毎日ベースで作業機能を提供する必要があります。 テストは、機能開発の継続的な不可欠な部分である必要があります。 プロジェクトの終了まで遅らせてはなりません。
機能を割り当てる
開発者と顧客は、各反復に機能を一緒に割り当てる必要があります。 この機能割り当ての最も重要な基準は、すべての反復で、かなりの機能を備えた目に見える一連の機能を顧客に提供する必要があるということです。
反復への機能の割り当て中-
- 開発チームは、機能の見積もり、リスク、および依存関係を考え出し、それらを顧客に提供する必要があります。
- お客様は、開発チームから提供された情報を使用して、機能の優先順位付けを決定する必要があります。
したがって、反復計画は機能ベースであり、開発者と顧客とのチームとして行われます。 このタイプの計画は、プロジェクトマネージャーによるタスクベースの計画よりも、プロジェクトをよりよく理解できることが経験からわかっています。 さらに、機能ベースの計画は、各プロジェクトの一意性を反映しています。
コラボレーション─同時機能開発
共同作業段階では、開発に重点が置かれます。 コラボレーションフェーズには2つのアクティビティがあります-
- 開発チームは共同で作業ソフトウェアを提供します。
- プロジェクトマネージャーは、コラボレーションと同時開発活動を促進します。
コラボレーションは、開発チーム、顧客、マネージャーを含む共有作成の行為です。 共有の創造は、信頼と尊敬によって促進されます。
チームは協力すべきです-
- 技術的な問題
- ビジネス要件
- 迅速な意思決定
以下は、適応ソフトウェア開発の共同作業段階に関連するプラクティスです。
- 分散チームのコラボレーション
- 小規模プロジェクト向けのコラボレーション
- 大規模プロジェクトのコラボレーション
分散チームのコラボレーション
分散チームが関与するプロジェクトでは、以下を考慮する必要があります-
- さまざまな提携パートナー
- 幅広い知識
- 人々が相互作用する方法
- 相互依存関係を管理する方法
小規模プロジェクト向けのコラボレーション
小規模なプロジェクトでは、チームメンバーが物理的に近接して作業している場合、非公式の廊下でのチャットやホワイトボードの落書きとのコラボレーションを奨励する必要があります。
大規模プロジェクトのコラボレーション
大規模なプロジェクトでは、追加のプラクティス、コラボレーションツール、およびプロジェクトマネージャーの対話が必要であり、コンテキストベースで配置する必要があります。
学ぶ-品質レビュー
適応型ソフトウェア開発は、「実験と学習」の概念を奨励しています。
誤りと実験から学ぶには、チームメンバーが部分的に完成したコードとアーティファクトを早期に共有して、
- 間違いを見つける
- それらから学ぶ
- 大きな問題になる前に小さな問題を見つけることで手戻りを削減
各開発イテレーションの終わりに、学ぶことの4つの一般的なカテゴリがあります-
- 顧客の視点からの結果品質
- 技術的な観点からの結果の品質
- デリバリーチームとプラクティスチームの機能
- プロジェクトのステータス
顧客の視点からの結果品質
アダプティブソフトウェア開発プロジェクトでは、顧客からフィードバックを得ることが最優先事項です。 このための推奨プラクティスは、顧客フォーカスグループです。 これらのセッションは、アプリケーションの動作モデルを調査し、顧客の変更要求を記録するように設計されています。
顧客フォーカスグループセッションは、jadセッションと同様の簡易セッションですが、要件を生成したりプロジェクト計画を定義したりするのではなく、アプリケーション自体を確認するように設計されています。 顧客は、反復から生じる動作中のソフトウェアに関するフィードバックを提供します。
技術的な観点からの結果品質
アダプティブソフトウェア開発プロジェクトでは、技術的な成果物の定期的なレビューが重要になります。 コードレビューは継続的に行う必要があります。 技術アーキテクチャなどのその他の技術成果物のレビューは、毎週または反復の最後に実施できます。
アダプティブソフトウェア開発プロジェクトでは、チームは自身のパフォーマンスを定期的に監視する必要があります。 回顧は、チームがチームとして一緒に自分自身と彼らの仕事について学ぶことを奨励します。
反復終了の回顧は、次のような定期的なチームパフォーマンスの自己レビューを促進します-
- 何が機能していないかを判断します。
- チームがさらに行う必要があること。
- チームが必要とすることは少なくなります。
プロジェクトの状況
プロジェクトステータスレビューは、さらなる作業の計画に役立ちます。 適応型ソフトウェア開発プロジェクトでは、プロジェクトステータスの決定は機能ベースのアプローチであり、各反復の終わりは機能が完了した機能によってマークされ、ソフトウェアが機能します。
プロジェクトステータスのレビューには、
- プロジェクトはどこにありますか？
- プロジェクトと計画はどこにありますか？
- プロジェクトはどこにあるべきですか？
アダプティブソフトウェア開発プロジェクトの計画は投機的であるため、上記の質問2よりも質問3が重要です。 つまり、プロジェクトチームと顧客は、「これまでに学んだことは何で、どこに行く必要があるかという観点を変えますか？」と自問する必要があります。
