スクラムの歴史
ソフトウェア開発の開発の原点は「ウォーターフォール」アプローチであり、ほとんどのチームで使用され、製品の実装を次の段階に分けました。
- プロジェクト要件の定義;
- 最初から最後まで操作を計画します。
- コードを書く;
- テスト。
つまり、顧客は来て、タスクについて説明し、チームは実装を計画し、確立された技術仕様に従って作業を開始しました。開発の終了後、製品がテストされ、何かが機能しない場合は、大量のコードを修正する必要があり、その結果、期限が延長されました。
これは、彼らが年々どのように働いたかであり、長い間イノベーターの1つのチームが成功したチームを観察しました：期限を守り、高品質の製品を作成することに成功したチーム。その結果、彼らは成功はプロセスの柔軟性にあることに気づきました。
長い観察の結果から導き出された結論に基づいて、「アジャイルソフトウェア開発のマニフェスト」が導き出されました。4つのポイントが含まれています。
- 人はツールよりも重要です。
- 製品の品質はドキュメントよりも重要です。
- お客様とのやり取りは、契約よりも重要です。
- 変更の準備は、計画よりも重要です。
これらの4つのポイントにより、ソフトウェア開発へのアプローチが根本的に変わり、アジャイルの基礎が形成されました。しばらくして、愛好家は柔軟なプロセスの12の基本原則を開発しました。これが今日、すべてのアジャイル手法の基礎となっています。
- 主なものは、優れたソフトウェアと満足のいく顧客です。
- いつでも変更の準備。
- 開発の結果として機能するソフトウェアをできるだけ頻繁に実現するため。
- チームミーティングは、情報を共有するのに最適です。
- 顧客と開発チームは協力する必要があります。
- 人々が自分の仕事をすることを信頼する。
- 動くソフトウェアがあります-進歩があります。
- 柔軟なプロセス-継続的な開発。
- 品質への配慮は柔軟性を促進します。
- プロセスが単純なので、不要な作業を回避できます。
- 自己組織化チームはよりうまく機能します。
- 効率の追求。
1990年代初頭、Jeff SutherlandとKen Schwaberは、独自のアジャイル開発方法論について話し始めました。長い間、彼らは軍隊、特殊部隊、さらにはラグビー選手さえも見ており、相互作用とチームワークのおかげで自分たちのタスクをなんとか成し遂げたという結論に達しました-これらの原則はスクラムの基礎を形成しました。
2001年に、彼らは方法論の原理を詳細に説明し、SCRUMを使用したアジャイルソフトウェア開発の本を出版しました。これまでのところ、このアプローチは開発者の間で最も人気のあるものの1つと考えられています。
スクラムの基本原則
この方法論には、クライアントに焦点を合わせ、最小限のリソースと時間のコストで期待される結果を得るのに役立ついくつかの基本原則があります。
スクラムの基本原則：
- (). () . .
- . . () .
- . - « » — . , . , .
- . Scrum-team — , .
スクラムチーム
ほとんどの場合、スクラムチームは5〜9人で構成されますが、3〜4人ではありません。スクラムのフレームワーク内では、各リンク間の相互作用が複雑であり、作業の効率に悪影響を与えるため、チームを大きくすることはできません。
構成
チームには3つの主要な役割があります。
- プロダクトオーナー。
- スクラムマスター。
- 開発者（配信チーム）。
すべての役割をより詳細に検討してみましょう。
プロダクトオーナー
所有者は開発の責任者です。この役割は、製品の顧客またはその正式な代表者によって実行されます。まれなケース-計画されたプロジェクトがその後実施される市場の代表。
所有者は、予想される経済的影響を反映した事業計画を策定する責任があります。また、その中で、開発計画を定義し、投資収益率を各項目について計算しています。所有者が従事しているフォーメーションであるもう1つの重要なドキュメントは、要件のリストであり、重要度で並べ替えられています。
簡単に言うと、製品オーナーはプロジェクトチームの意思決定センターです。それはプロジェクト内の唯一のものでなければなりません。そうでなければ、重要な決定の迅速な採用の原則に違反します。
所有者の責任のおおよそのリスト：
- ;
- ( );
- ;
- ;
- ;
- .
-
スクラムマスターは、自分の仕事でスクラム方法論を順守する責任があります。彼は、すべてのチームメンバーのイニシアチブと独立性、得られた結果に対する満足度、チームの雰囲気、および一般的な仕事の結果を制御します。
さらに、スクラムマスターは、外部から開発を監視する孤立した人物ではないことを理解することが重要です。彼はチームのメンバーであり、コントロールと共に、製品の技術的な実装に直接関与する必要があります。
スクラムマスターは、すべてのチームメンバーの相互の対話を担当し、高レベルのパフォーマンスを維持し、問題を排除し、計画された作業スケジュールを順守します。
スクラムマスターの責任のサンプルリスト：
- 信頼できる雰囲気を作る。
- 総会への参加、参加者のコミュニケーションの成功
- ;
- ;
- .
開発者は、製品の技術的な実装を担当する開発者です。原則として、チームあたり5〜9人の開発者がいます。最初のタスクは、各スプリントに対して現実的に達成可能、予測可能、興味深く、意味のある目標を設定することです。
2番目のタスクは、各スプリントの設定された目標を予定どおりに達成することです（期限）。目標の達成は拡張可能な概念であり、プロジェクトごとに個別に決定されます。たとえば、すべてのコードを書き込んだ後にタスクが完了したと見なされる場所と、テストの終了を追加する場所があります。一般に、誰もが自分のビジョンと経験に導かれています。
開発チームの主なスキルは、計画、実行された作業の客観的な評価、他のチームメンバーと対話する能力です。
開発チームのおおよそのリスト：
- 製品バックログ項目の評価。
- 製品開発と顧客への配送。
- 進捗状況の追跡（スクラムマスターと一緒に）;
- 結果を製品の所有者に提供します。
スクラムチームのしくみ
3つの原則が守られれば、スクラム方法論の成功は可能です。
- 継続的な自己改善。経験豊富な開発者は、製品を改善し、理想的な状態にすることは、各チームメンバーの自己改善なしには不可能であると言います。
- 自治。すべての従業員は、全体的な結果に責任を持ち、チームで作業できるようにするだけでなく、多くの職務を個別に実行する必要があります。
- クロス機能。さまざまなスキルを持つスペシャリストが含まれているため、どのチームも自給自足です。
スクラムチームのワークフロー
スクラム方法論を導くチームの作業は、従来、いくつかの段階に分かれています。
1.スプリントタスクのリストを計画します。すべてのスプリントは計画から始まります。すべてのチームメンバーが集まり、製品のバックログ全体を評価し、現在のイテレーションで完了する優先タスクを選択します。これは、現在のスプリントのタスク（バックログ）のリストが形成される方法です。
その後、バックログに基づいて、作業の範囲とサイクルの期間が交渉されます。また、結果は事前に決定されます。スプリントの結果として何を取得する必要があるかです。
2.定期的な会議を開催します。毎日または毎週、チームは短い会議を開催します（15〜30分以内）。それらには、製品の所有者、スクラムマスター、およびすべての開発者が含まれます。会議の目的は、全員から3つの質問に答えることです。
- ?
- ?
- ?
会議中のスクラムマスターは現在の問題を特定し、チームがそれらを解決するのを助けます。
3.スクラムボードの編成。定期的な会議が行われる会議室では、「やること」、「進行中」、「完了」の3つの部分に分かれた掲示板が吊り下げられています。
各パーツには、主な作業が書かれた色違いのステッカーが貼られています。彼らが進むにつれて、彼らはある部分から別の部分に移動します。これは、各チームメンバーが現在のスプリントの進行状況を追跡するのに役立ちます。
4.反復中の計画の変更。チームはオープンである必要があり、1人のスペシャリストが期限を守る時間がない場合は、製品の所有者にそれについて通知します。タスクの割り当てを変更し、労働時間を最適化し、期限内に保つのに役立ちます。
タスクが予定よりも早く完了した場合、作業が速すぎる場合も同様です。マネージャーは、自分の裁量で新しい目標でバックログを補完するため、製品の販売はより速く進みます。
5.まとめ。各スプリントの完了後、完成したソフトウェアがテストされます。潜在的な消費者もそれに参加します（フォーカスグループ）。所有者はフィードバックを収集し、将来の成功する仕事のための決定を行います。
スクラムアーティファクト
スクラムプロジェクトには3つの重要なドキュメントが含まれています。これらはアーティファクトとも呼ばれます。
- 製品マガジン（製品バックログ）。
- スプリントバックログ
- スプリントチャート（バーンダウンチャート）。
それぞれに特定の機能がありますが、これについては後で説明します。
製品マガジン
所有者は、最初に製品マガジンを準備します。ドキュメント（アーティファクト）には、重要度でソートされた要件が含まれています。開発者はプライマリバージョンを補足します。各要件を実装するコストを見積もります。
製品のバックログには、実装に必要な技術的な側面だけでなく、機能的な側面も含める必要があります。各要件には優先順位が割り当てられています（たとえば、1から5）。チームがそれらを評価してテストできるように、最も優先度の高いものが詳細に説明されています。
商品の所有者は、商品マガジンを準備するだけでなく、時間通りに提供する義務があります。そうでなければ、プロジェクトのタイムリーな実装は不可能です。
スプリントログ
ご存じのとおり、スクラム手法のフレームワーク内では、製品は小さな反復で実装されます。通常、1つのスプリントは1つの機能です。効果的な作業のために、実装にかかる時間が2〜3営業日になるように、小さなタスクに分割されます。
機能をタスクに分解することにより、反復の終わりまでに、ソフトウェアの特定の部分が正しく機能し、エンドユーザーにとって価値のあるものになるために必要なすべてを完了することができます。
スプリントバックログが完了すると、開発チームによって評価され、製品ログと比較されます。大幅な逸脱がある場合、チームは現在のスプリント内で最も優先度の高いタスクと、次の反復に転送できるそれほど重要でないタスクを決定します。
製品所有者のタスクは、バックログから小さな重要でないタスクを除外することです。その実装は、作業の最終結果に影響を与えません。
スプリントスケジュール
スプリントスケジュールは、現在の反復内で作業するようにスケジュールされたタスクのカレンダーです。スプリントが終了するまでの残りの作業量が表示されます。チームは定期的にスケジュールを評価し、必要に応じて変更に迅速に対応します。
製品所有者はカレンダーに特別な注意を払います。作業のスピードと期限の遵守を評価します。たとえば、作業量が時間の経過とともに減少しない場合、プロセスに多少の偏差があり、チームのアクションの緊急の修正が必要です。
スクラム方法論を適切に実装する方法
チームの効率を向上させるには、スクラム手法の正しい実装が必要です。間違いは何かを変えるだけでなく、生産性にも悪影響を及ぼします。
変更する場合は、段階的に実装を行います。
- チームを編成します。将来の製品の成功が左右される主なステップ。あなたの分野での実務経験を持つ資格のある専門家を選んでください。時間をかけて覚えてください。部門を超えたチームを集めることは簡単な作業ではありません。
- 製品の所有者を指定します。この役割を顧客またはその代理人に与えます。チーム内および顧客間のやり取りは彼に依存しているため、人がこの方向に経験を持っていることが重要です。
- -. , . , .
- . . , . . - , .
- . . . , .
- 結果を分析および評価します。各スプリントが終了した後、結果を分析して測定します。前の開発の結果に完全に満足した場合にのみ、開発の次の段階に進みます。
これらの6つのステップにより、チーム全体の効率が向上します。しかし、一見しただけでは単純に見えます。実際、新しいルールの下で作業を安定させるには、かなりの時間がかかります。
チームの誰かがイノベーションを気に入らないかもしれません。人々が何か新しいことに反対するのは自然なことです。あなたの仕事は、新しい方法論の利点を各チームメンバーに伝えることです。
要約する
スクラムは、アジャイルの原則に基づくアジャイル開発方法論です。その開発は前世紀の90年代に始まり、00年代初頭に広く人気を博し始めました。今日、スクラムは、活動がプロジェクトに密接に関連している多くのチームによって使用されています。
スクラムは6つのステップで会社に実装できますが、プロセスの編成には注意深く取り組む必要があります。方法論は従業員からの特別な知識を必要としません、ここでそれはむしろ労働時間を組織し、正しく構築することの問題です。
同時に、スクラムが魔法の薬ではないことを忘れないでください。期限内に絶え間なく内訳があり、チーム内の雰囲気が悪い場合、新しいテクノロジーを導入してもすべての問題が解決するわけではありません。したがって、最初にチーム内でコミュニケーションを確立し、効果的な作業を構築してから、スクラムを実装して生産性を向上させます。