彼らはアジャイルについて多くのことを話し、書きます。 誰かが勝利について語り、満足した顧客に写真を見せ、2週間以内に繰り返しを行うことを勧めます。他の人にとっては、アジャイルは痛み、苦悩、苦しみの同義語です。 そこで、アジャイルが10年以上興味がなかったプロジェクトの歴史を振り返ってみることにしました。このプロジェクトでは、スクラムと毎日の基準が突然争いの骨になり、新しい仕事を見つける理由と喫煙室で最も議論されたトピックになりました。
それはすべて、顧客側のリーダーシップが強い意思決定を行い、物事の確立された状態を変えることができる新しいリーダーを探すことに着手したという事実から始まりました。 私の前にどのような変更があったのかはっきりと言うことはできませんが、プロジェクトに参加した時点で次の写真がありました。
-人々は無限の変化にうんざりしています。
-アジャイルとスクラムという言葉は、刺激と痛みを伴うしかめっ面を引き起こしました。
-用語の無限の内訳;
-不満のあるお客様。
-欠陥を緊急に修正し、新しいサービスパックを突然準備する必要があるため、リリース中のパッチを含むさまざまな修正の定期的な配信。
-一般的な混乱と混乱。
そしてその瞬間、彼らは言う-こんにちは、これはアンナ、あなたの新しいプロジェクトマネージャーです。 多くの人が、初心者がすでに確立されたチームに来るのは難しいということに同意すると思います。 そして、そのようなチームでプロセスをセットアップし、人々を快適ゾーンから連れ出し、すべてを変更する必要がある場合にのみ困難になる可能性があります。 ちなみに、プロジェクトは十分に大きく（参加者80人以上）、ソフトウェアは10年以上にわたって開発され、血まみれの企業でした=）。
私の経営ハネムーンの終わりに、次の写真が現れました。
1.同時に、7つの開発チームと4つの手動テスターチーム、1つの自動チーム、および他のタスクやサブプロジェクトを実行する多くの個人またはグループが働きました。 開発チームは多かれ少なかれモジュールに分割され、テスターは誰が何をより良く知っているかの原則に従って歴史的に共有する可能性が最も高かった。
2.管理者が完全に終了する必要があり、期限までに終了できなかった4週間の反復がありました。 計画システムは、チーム内の各個人のパフォーマンスに基づいて、何らかの独自のシステムでした（別の記事のトピックにすることもできます）。
3.信じられないほどの数のスピーカーと勤勉な問題を抱えた多くのかんばんボード。 興味深い点は、同じチーム用にそのようなボードがいくつかある可能性があることです-現在の反復用、最後の未完成用、パッチ要求用、サービスパック用の別のボードなど。
4. Googleドックのドキュメントの一部、一部はローカルディスクにアップロードされ、一部はレターで保存されます。
5.各チームは、独自のスキームに従って、独自の「プロセス」で作業しました。
私は設定されていました（！）2つのタスク：スクラムのチームの作業を撤回し、予定された作業量が予定通りに完了したことを確認する。
チームで使用された計画のコンセプトを見ると（このアイデアは非常に実行可能であると言う価値があります）、どこに行くかはまったく明らかではありませんでした。 したがって、私が最初にしなければならなかったのは、Jiraに必須の時間追跡システムを導入することでした。 問題は、どのような種類の作業にどれだけ時間がかかっているかを理解する必要があるということでした。 3か月の終わりまでに、統計はより適切になりました。
このプロセスとともに、スクラムチームが形成され始めました。 この選択が顧客によって事前に決定されていない場合、どの方法論を選択するのかを確実に言うことはできません。また、方法論は適切な運用ほど重要ではないという概念を引き続き順守しますが、このプロセスは非常に困難であることが判明したと言えます。 チームによって現実的かつ先取りされた多くの問題、紛争、不満、解雇への脅威がありました...すべての中で最も難しいのは次のとおりです。
-同じテスターが異なる開発チームのモジュールを担当しました。
-モジュールは相互接続されており、あるチームの変更が別のチームの作業に影響を与える可能性があります。
-このプロセスに対する非常に予期せぬ障害は、1つのチームを1つの部屋に配置することに対する抵抗でした。
-リードチームによる抵抗の問題（ポジションを失うことへの恐怖、なぜこれがすべて必要なのかを誤解している）。
すべての人をすぐに再構築するのは非現実的なように思えたので、原則として、より簡単に始めたチームから始めました。
最終的に行われたこと：チームが可能な限り独立するように、主な分離は論理モジュールによって実行されました。 開発者とテスターの関連付けは、モジュールの知識、特定のチームでの作業経験、チームの限られた数の参加者、過去のチームデータの成功、1つのチームへの製品所有者の集中（製品の異なる所有者が異なるモジュールを担当しているため）の観点から行われました。 その結果、8つのスクラムチームを結成しましたが、自動テスターのチームは離れたままです。
スクラムと一般的にアジャイルの人々の抵抗をわずかに弱めるために、集会を開始するための定期的なスロットを組織しました。 アイデアは、一部のチームがプロセスの明確化を必要とする場合、このスロットを予約し、問題を説明し、チーム全体で集会に参加できるというものでした。 通常、すべての質問に答えるには20〜30分で十分です。
また、チームの構築、モチベーション、チームで友達を作る他の喜びについても思い出しました。 そのため、誰かが昇進を受け取り、誰かが有料コースに送られ、要求に応じて誰かが別のタイプの仕事または別のチームに移されました。
スクラムフライトでのチームの編成と打ち上げが完了した後、4週間のスプリントを計画することは非常に難しく、時間がかかり、効果的でない場合があることが明らかになりました。 そのような期間の人々は、単に「計画した」ことを忘れます。 そのため、反復は2週間に短縮されました。
しかし、反復の削減により、別の問題が発見されました。 現在のビルドおよび配信システムは、新しい条件には遅すぎました（新しいビルドが週に1回提供されました）。 納期の短縮（週に最大2回）が、これは非常にまれであることが判明し、特に修正の結果を毎日確認する必要がある場合、スプリントの終わりに近づくと特に感じられました。 特定のテストセットに合格したビルドの成功はホストされることを決定しましたが、この単純なソリューションでも結果が得られませんでした。
1.ケースの30％でコンパイルが失敗しました。
2.テストの30％で、テストが更新されなかったために落ちました。
3.テストの20％でエラーが発生しました。
4. 20％がビルドエンジニアのミスを説明しました。
その結果、週に2回以上、ビルドの展開は行われませんでした。 簡単なソリューションを見つけることから、ビルドシステム全体の変更に進みました。 たくさんの素晴らしいソリューションを見つけました（git + gerrit + Jenkins）。 問題番号1は非常に簡単に解決されました-プルリクエストブランチでコンパイルを設定します。
問題＃2および＃3は、プルリクエストブランチでも解決する必要があります。これにより、テストが事前にクラッシュし、共通ブランチにコードが到着する前に修正できるようになります。
その結果、5か月目までに特定の結果に到達しました。 最も重要なことは、すべてのチームが予定どおりの作業量を予定通りに提供し始めたことです。 次の重要なポイントは、作業中および処理中に緊急作業員から逃げることができたことです。 すべてのチームが1つのスキームに従って作業を開始し、結果がより予測可能になりました。 顧客の忠誠心も増し、彼は私たちの不作為についてより柔らかくなり、プロジェクトのコントロールが少なくなりました。 ところで、誰も辞めません。
いずれにしてもプロセスはまだ終わっておらず、次の大きなステップは製品所有者と協力して、多数のサービスパックのリリースで状況を修正し、すべてのドキュメントをConfluenceに翻訳し、プロジェクトを調整し、生産性を向上させるための方法論を開発することです。
これは最初のプロジェクトでも最後のプロジェクトでもないため、変革が行われているため、いくつかのアイデアが役立ち、他のプロジェクトに役立つ可能性があります。
1つのプロジェクトの調整
All Articles