Agile-data-science-methodology-concepts
アジャイルデータサイエンス-方法論の概念
この章では、「アジャイル」と呼ばれるソフトウェア開発ライフサイクルの概念に焦点を当てます。 アジャイルソフトウェア開発方法論は、1〜4週間の短い反復で増分セッションを介してソフトウェアを構築するのに役立ちます。そのため、開発はビジネス要件の変化に合わせて調整されます。
アジャイル手法を詳細に説明する12の原則があります-
顧客満足度
価値のあるソフトウェアを早期かつ継続的に配信することにより、要件に焦点を合わせているお客様に最も高い優先順位が与えられます。
新しい変化を歓迎する
ソフトウェア開発中の変更は許容されます。 アジャイルプロセスは、顧客の競争上の優位性に合わせて機能するように設計されています。
配達
動作中のソフトウェアの配信は、1〜4週間でクライアントに提供されます。
コラボレーション
ビジネスアナリスト、品質アナリスト、開発者は、プロジェクトのライフサイクル全体で協力する必要があります。
動機
プロジェクトは、やる気のある個人の一族で設計する必要があります。 個々のチームメンバーをサポートする環境を提供します。
個人的な会話
対面の会話は、開発チームに情報を送信する最も効率的かつ効果的な方法です。
進捗の測定
進捗状況の測定は、プロジェクトおよびソフトウェア開発の進捗状況を定義するのに役立つキーです。
一定のペースを維持する
アジャイルプロセスは、持続可能な開発に焦点を当てています。 ビジネス、開発者、およびユーザーは、プロジェクトを一定のペースで維持できる必要があります。
モニタリング
アジャイル機能を強化するために、技術的な卓越性と優れた設計に定期的に注意を払うことが必須です。
単純さ
アジャイルプロセスはすべてをシンプルに保ち、完了していない作業を測定するためにシンプルな用語を使用します。
自己組織化された用語
アジャイルチームは自己組織化され、最適なアーキテクチャで独立している必要があります。要件と設計は、自己組織化されたチームから生まれます。
仕事をレビューする
チームが作業の進捗状況を反映できるように、定期的に作業を確認することが重要です。 適時にモジュールを確認すると、パフォーマンスが向上します。
毎日のスタンドアップ
毎日のスタンドアップとは、チームメンバー間の毎日のステータスミーティングを指します。 ソフトウェア開発に関連する更新を提供します。 また、プロジェクト開発の障害に対処することも指します。
オフィスの場所に関係なく、アジャイルチームがどのように設立されても、毎日の立ち上げは必須の慣行です。
毎日のスタンドアップの機能のリストは次のとおりです-
- 毎日のスタンドアップミーティングの所要時間は約15分です。 それはより長い期間延長されるべきではありません。
- スタンドアップには、ステータスの更新に関する議論を含める必要があります。
- 通常、この会議の参加者は、すぐに会議を終了する意図を持って立ちます。
ユーザーストーリー
ストーリーは通常、要件であり、簡単な言語の少数の文で定式化され、反復内で完了する必要があります。 ユーザーストーリーには、次の特性を含める必要があります-
- すべての関連コードには、関連するチェックインが必要です。
- 指定された反復の単体テストケース。
- すべての受け入れテストケースを定義する必要があります。
- ストーリーを定義する際の製品所有者からの受け入れ。
スクラムとは何ですか？
スクラムは、アジャイル手法のサブセットと見なすことができます。 それは軽量プロセスであり、次の機能が含まれています-
- これはプロセスフレームワークであり、一貫した順序で従う必要がある一連のプラクティスが含まれています。 スクラムの最良の例は、反復またはスプリントに従うことです。
- これは「軽量」プロセスであり、プロセスを可能な限り小さくして、指定された期間の生産性を最大限に高めます。
スクラムプロセスは、従来のアジャイルアプローチの他の方法論と比較した際立ったプロセスで知られています。 それは次の3つのカテゴリに分かれています-
- 役割
- アーティファクト
- タイムボックス
役割は、プロセス全体に含まれるチームメンバーとその役割を定義します。 スクラムチームは、次の3つの役割で構成されています-
- スクラムマスター
- プロダクトオーナー
- Team
スクラムアーティファクトは、各メンバーが認識すべき重要な情報を提供します。 この情報には、製品の詳細、計画された活動、完了した活動が含まれます。 スクラムフレームワークで定義されているアーティファクトは次のとおりです-
- 製品バックログ
- スプリントバックログ
- バーンダウンチャート
- インクリメント
タイムボックスは、各反復で計画されるユーザーストーリーです。 これらのユーザーストーリーは、Scrumアーティファクトの一部を形成する製品機能の説明に役立ちます。 製品バックログは、ユーザーストーリーのリストです。 これらのユーザーストーリーは優先順位が付けられ、ユーザーミーティングに転送されて、どのストーリーを取り上げるかが決定されます。
スクラムマスターを選ぶ理由
スクラムマスターは、チームのすべてのメンバーと対話します。 スクラムマスターと他のチームやリソースとの相互作用を見てみましょう。
プロダクトオーナー
スクラムマスターは、次の方法で製品所有者と対話します-
- ユーザーストーリーの効果的な製品バックログを達成するためのテクニックを見つけ、それらを管理します。
- 明確で簡潔な製品バックログアイテムのニーズをチームが理解できるようにします。
- 特定の環境での製品計画。
- 製品の所有者が製品の価値を高める方法を知っていることを確認します。
- 必要に応じてスクラムイベントを促進します。
スクラムチーム
スクラムマスターは、いくつかの方法でチームとやり取りします-
- スクラムの採用における組織の指導。
- 特定の組織へのスクラム実装の計画。
- 従業員と利害関係者が製品開発の要件とフェーズを理解するのを支援します。
- 他のチームのスクラムマスターと協力して、指定されたチームのスクラムの適用の有効性を高めます。
組織
スクラムマスターは、いくつかの方法で組織と対話します。 いくつかは以下に記載されています-
- コーチングおよびスクラムチームは自己組織化と対話し、クロス機能の機能を備えています。
- スクラムがまだ完全に採用されていない、または受け入れられていない分野の組織およびチームを指導する。
スクラムの利点
スクラムは、顧客、チームメンバー、および利害関係者のコラボレーションを支援します。 これには、タイムボックス化されたアプローチと製品所有者からの継続的なフィードバックが含まれており、製品が動作状態にあることを確認します。 スクラムは、プロジェクトのさまざまな役割にメリットをもたらします。
顧客
スプリントまたは反復はより短い期間と見なされ、ユーザーストーリーは優先度に従って設計され、スプリント計画で取り上げられます。 すべてのスプリントの配達、顧客の要件が満たされることを保証します。 そうでない場合、要件は書き留められ、スプリントのために計画され、実行されます。
組織
スクラムおよびスクラムマスターの支援を受けた組織は、ユーザーストーリーの開発に必要な作業に集中できるため、作業の過負荷を軽減し、必要に応じてやり直しを回避できます。 これは、開発チームの効率向上と顧客満足度の維持にも役立ちます。 このアプローチは、市場の可能性を高めるのにも役立ちます。
プロダクトマネージャー
製品管理者の主な責任は、製品の品質を維持することです。 スクラムマスターの助けを借りて、作業を容易にし、迅速な応答を収集し、変更がある場合はそれを吸収することが容易になります。 また、製品マネージャーは、設計された製品がすべてのスプリントの顧客の要件に従って調整されていることを確認します。
開発チーム
タイムボックス化された性質とスプリントの継続時間の短縮により、開発チームは作業が適切に反映され、配信されることに熱心になります。 作業中の製品は、反復のたびに各レベルをインクリメントするか、「スプリント」と呼ぶことができます。 すべてのスプリント用に設計されたユーザーストーリーは、顧客の優先事項となり、反復の価値を高めます。
結論
スクラムは、チームワークでソフトウェアを開発できる効率的なフレームワークです。 アジャイルの原則に基づいて完全に設計されています。 スクラムマスターは、あらゆる可能な方法でスクラムのチームを支援し、協力するためにあります。 彼はあなたが設計された計画に固執し、計画に従ってすべての活動を実行するのを助けるパーソナルトレーナーのように振る舞います。 ScrumMasterの権限は、プロセスを超えて拡張されるべきではありません。 彼/彼女は、あらゆる状況を管理できる可能性があります。
