私が最初に考えたのは、ScrumTrek Certified Agile Professional認定コースの説明で「アジャイルは単なるスクラム以上のものです」と読んだときの理由です。 このトレーニングを完了した後、私はもっと真剣な態度でこの声明に戻りました。 それで、私はトレーニングから何を学びましたか？ 記録、配布資料、および認定ICAgile Professionalですか？ しかし、アジャイルとは何か理解するのはどうでしょうか？ アジャイルアプローチのコンセプトは何ですか？ アジャイルマインドセットとは何ですか？
この記事では、トレーニングの印象を共有します。 これは、トレーニングで得られた知識の利点を主観的に評価するというよりも、トレーニングの内容を言い直すことではありません。 このトレーニングが必要かどうかを判断するのに役立つことを願っています。
アジャイルの歴史
私はトレーナーがソフトウェア開発業界全体の進歩的な成長として提示したアジャイルの話をよく覚えています。
Code-and-Fixにより、業界は、開発者の資格に関する計画、ドキュメント、または特別な要件なしに、比較的安価にコードを記述できます。
1970年代にウォーターフォールモデルに置き換えられ、リスクを減らし、ソフトウェア開発の透明性を高め、開発者の資格要件を低く維持しながら、ソフトウェアメンテナンスの高コストの問題も解消しました。 モデルはあらゆる場所で使用され始め、その問題がすぐに明らかになりました。 ウォーターフォールは、すべてが事前にわかっている場合にのみ機能します。どの製品を開発する必要があるか、どの実装テクノロジーを使用する必要があるか、そして途中で変更は発生しません。
状況を修正する最初の試みは、1990年代の反復アプローチの出現に関連していました。 一方で、これは、機械の時間が客観的な制限でなくなったときにコンピューターを安くすることによって容易になり、複数の実験で製品の機能を向上させることができます。 一方、新しいITテクノロジーはますます競争を激化させているため、ビジネスはそれらをビジネスに迅速に適用する必要があります。 誰よりも先に新技術を導入し、顧客と市場の両方を獲得しました。 この瞬間から、柔軟な開発プロセスの積極的な開発が始まります。これは、ビジネスに機能を迅速に提供することを目的としています。 実際、「高速」のコードと修正方法へのロールバックがありますが、それはリスクを計画して排除することによって補完されます。
ところで、今日まで、ほとんどの企業の開発者はスクラムをまったく使用していないようです。 以下の図を見てください、どういうわけかあなたのために働きますか？
それともスクラムと同じですか？
1992年にCrystalが登場しました。これは、エンドユーザーへの頻繁な作業コードの配信に初めて焦点を当てています。 その後、1994年にDSM（Dynamic Systems Development Method）が導入され、ビジネスニーズに焦点を当て、ソフトウェア品質のレベルが低下することを宣言しました（リファクタリングという用語は同じ年に登場しました）。 最後に、1996年にスクラムフレームワークが導入され、アジャイル開発を管理するための事実上の標準になりました。 同じ年に、ペアプログラミングが初めて適用され始めました。 1999年にXPが登場し、ユーザーストーリー、リリース計画、継続的インテグレーションの概念がもたらされました。 これらすべてのプライベートイニシアチブの結果は2001年に開発されたソフトウェア開発のアジャイルマニフェストであり 、ビジネスに機能を迅速に提供できるように10周年までにテストされた価値と原則をenっています。
アジャイルのさらなる開発は、ソフトウェア開発プロセス中に発生する可能性のあるすべての損失（ダウンタイム）を排除し、機能の提供速度をさらに向上させる試みに関連しています。 2003年、リーンソフトウェア開発は、トヨタのリーン製造コンセプトをソフトウェア開発業界に適応させたものとして登場しました。 2006年には、ビジネスへの価値（機能）の供給ストリームの損失をなくすための既製のアルゴリズムを提供するKanban Software Developmentの登場により、この動きは継続しています。 また、2011年には、SAAS（サービスとしてのソフトウェア）の爆発的な成長に対応して、開発と保守を組み合わせてジャンクションでの損失をなくすDevOpsコンセプトが登場します。
全体として、生産（開発）は狭いリンクでなくなり、ビジネスニーズをできるだけ早く満たすことを学びました。 ただし、アジャイルの開発は継続しています。 まず、大企業でのアジャイルスケーリングの分野（SAFe）。 第二に、失敗した膨大な数の投資プロジェクトは、製品開発の分野で問題を提起します。最も需要の高い製品を可能な限り安く開発する方法ですか？ 2009年、この制限への対応はLean Startupでした。
次に何が起こると思いますか？ 近い将来、教育システムの変更は避けられないようです。なぜなら、プロセスはそれ自体ではなく、人々によって実行されるからです。
アジャイルの価値と原則
参加者と一緒に、トレーナーはソフトウェア開発のアジャイルマニフェストの各価値と各原則を順番に深く調べます。 トレーニングの前に、価値と原則を完全に理解していると心から信じていました。 これは完全に真実ではないことが判明しました。
たとえば、アジャイルの2番目の価値：「実用的な製品は包括的なドキュメントよりも重要です。」 かつて、これはウォーターフォールモデルの拒否の宣言であり、進捗状況の理解はプロジェクトのドキュメントに大きく依存していました。 しかし、アジャイルマニフェストのバージョン2では、「ビジネス上の価値は実際の製品よりも重要です」という表現が変更されました（ アジャイルマニフェスト2.1-「アジャイルマニフェスト」 ）。 これは、リーンスタートアップの出現に関連するアジャイルの価値の進化の例です：あまりにも多くの製品が誰にとっても役に立たないことが判明しました。
スクラムとかんばん
トレーニングの大部分は、スクラムフレームワークとかんばんのレビューで占められています。 トレーニングのこの部分を改定することは、このメモの目的の一部ではありません。 チームプレーを通してコーチがあなたの指先で感じるのを助けるすべての重要な瞬間に注意するだけです。 しかし、これはさらに詳しく説明する価値があります。
アジャイルゲーム
すべてのゲームは、学習しやすく、その過程で楽しかったです。 トレーニングの2日目のあるゲームで、参加者の1人が「そして、私たちは以前何をしましたか？」と叫びました。 ここにあります！」以下で、ゲームで学んだことについてお話しします。
ペニー/マルチタスクゲームはライブで（私たち自身で）、説得力のあるように（通常のストップウォッチで）仕事に少しずつ参加し、同時にいくつかのタスクを実行する必要がないことを示しています。 これにより、厳密にシーケンシャルな作業プロセス（ウォーターフォール）でのダウンタイムによる損失、進行中のワークの蓄積による損失（口いっぱいに長く噛む）およびコンテキスト切り替え（ウォーターフォールモデルでは、同時に複数のプロジェクトでの従業員の作業が最も可能性が高い） 。
プランニングポッカーは、評価チームによる非常に単純な手法であるため、ショートゲームのフレームワーク内でも、美徳を感じることができます。 たとえば、ゲームチームのすべてのメンバーは、最終的に、ほとんどの時間を特定の作品の人件費を評価するのではなく、最初から異なる方法で理解した作品について議論することに同意しました。 言い換えれば、主な利点は評価図にあるのではなく、同じ仕事を理解していることです。 一方、時間に限りがあるため、見積もりがすぐに収束した場合、紛争や議論を避けました。 シンプルなことですが、仕事を続けるのはどれほど難しいことでしょう！ そうじゃない？
Daily Standup Meetingの妨害行為のステージングにより、アジャイルの価値についての議論に戻りました。 たとえば、スクラムマスター（プロセスコーチ）は、開発チームのマネージャーになったり、それに応じて行動したりすることはできません。つまり、タスクを分散し、感情を含め、グループに反対することで、会議を目の前のチームメンバーの退屈な報告会議に変えます。
ボールポイントゲームは、チームダイナミクスの仕組みを示しました。 前と同じように、私たち自身は実験的なウサギであり（これは観察するだけでなくすべてを感じることを意味します）、デジタル結果は非常に説得力があります。 私たちは何を理解していますか？
- チームメンバーの数が増えると通信が複雑になるため、大規模なチームはよりゆっくりと進化します。
- 生産性の最大の向上は、「プッシュしよう！ ぼろきれ！」
- 完璧なソリューションを長期にわたって探すよりも、実験で改善のための提案を迅速に実行することが重要です。
おわりに
そしてどうやって？ 今、あなたはアジャイルとは何かを理解していますか？ そうでない場合は、トレーニングに参加することをお勧めします。 その場合、特にアジャイルを始めたばかりの場合は、チーム全体をトレーニングに参加させることをお勧めします。