スクラム。 カオスから秩序、そして高い生産性まで

スクラムとは何か、何が食べられるかについて、何百万もの記事が書かれています。 ただし、それらのほとんどは、スクラム前に特定の真空があるか、PMBOKプロセスなどの厳しい環境があることを前提としています。アジャイルの方法論を既存の環境に導入することに関する多くの記事は見つかりませんでした。以前の方法論はありませんでしたが、すでに確立された伝統がありました。



2年半前、チームと私（より正確には当時はなかった）が製品の開発を開始したとき、私たちは方法論、プロセス、その他不要だったと思われる官僚的な問題について考えませんでした。 時間が経ち、製品が増え、チームは成長しました。 徐々に、ある種のカオスが形成されていることを誰もが認識し始めました。これは、制御がますます困難になりつつあり、最も重要なことは、私たちの能力を深刻に制限しました。 実際、私たちにとってはいつの間にか、状況は重大に近づいていました。



カットの下には、苦労していた開発プロセスにスクラムが導入されたという長い実話があります。 この物語があなたにとって興味深く、そしておそらく、あなたがいくつかの問題を決定または解決するのに役立つことを願っています。





状況をよりよく評価するには：

だから状況：

2014年秋。チームは2つの小さなシステムをサポートし、他の3つのシステムを積極的に開発し、共通のアーキテクチャを備えた1つの複合体にまとめました。 実際、これはチームではありません。 開発の過程で、歴史的に、各システムに責任を持ち、それを扱うだけの人々がいました。 2つの小さなシステムのサポートと1つの開発は1人のプログラマーによって行われ、さらに2つのシステムが他の2人のチームメンバーに分散され、最後に1人のフロントエンド開発者がすべてのシステムが使用できる単一のインターフェイスを開発しています。



当時のコードベースはすでに数十万行で、最小限のテストで自動化されていませんでした。 Git-eは、プロダクションでmasterの2つのブランチを使用し、開発でdevを使用しました。当然、大規模なマージなどで多くの問題がありました。 徐々に、新機能の導入速度はほぼゼロに低下しました。 経営陣は私に何らかの形でタイムラインを評価するように頼みましたが、実際には、どんな見積もりも空​​の指でした。



もう1つの大きな問題は、プロジェクトと優先順位のバランスを取ることができなかったことです。 たとえばシステムBの開発を一時停止するなど、システムAにより多くの人を割り当てようとすると、プログラマーが他の誰かのコードを絶対に知らず、システムのビジネスタスクについてほとんど知らなかったという事実に直面し、実際には長い間開発が遅くなりました。



なぜすべてがそんなに悪かったのですか？ すべてがシンプルです。 私たちが始めたとき、主なことはすべてを迅速に行うことでした。そしてご存じのように、品質は常に速度を追求することに苦しみます。 心の底では、誰もがこれが間違っていることを理解していましたが、それについて考える時間がないように思われました。 はい、私たち自身のせいですが、それはそうです。



何かを変更する必要があることは明らかでした。

開始する

スクラムを使用するというアイデアは、長い間空中にありました。 その主な利点はまさに私たちが必要としていたものでした：短いリリースサイクル、柔軟なバックログ、迅速なフィードバック。 しかし、問題がありました。 まず、少なくとも1つの複雑なシステムがありますが、システムごとにバックログ、優先度があり、各システムに独自のチームを提供する方法はありません。 第二に、プログラマーは非常に不活発な従業員であり、以前と同じように働くことに慣れています。そして、彼ら自身はすべてがスムーズではないことを理解していました。 第三に、スクラムはプロジェクト管理だけでなく、自動テスト、CI、クリーンなコード、そして当時我々が持っていなかった多くのものです。

しかし時が来て、先延ばしにすることはもはや不可能であることが明らかになり、私たちは仕事のやり方を世界的に変える準備を始めました。

実装

そもそも、主な問題を解決する必要がありましたが、それなしでは次のステップは不可能でした。



知識の共有

私たちは長い間これを準備してきました。 その時点で開始されたすべての主要なタスクを完了し、システムのビジネス機能の説明を作成し、各開発者は自分のコードの薄い場所または明白でない場所についてのストーリーを準備しました。

すべての準備が整ったら、2週間、バグの修正のみを行い、極端な場合にのみ、新しい開発を中断しました。 2週間、チームの各メンバーがコードを提示し、ユーザーのニーズについて詳細に話しました。

2週間、人々はコードを研究し、「エイリアン」バグの修正を試み、多くの質問をしました。



これが終了し、少なくとも各プロジェクトが何について話しているのか誰もが知っていたとき、プロセスを変更する時が来ました。



ここで言及する必要があるのは、すべての初めに、私はスクラムマスターでありプロダクトオーナーでもあったことです。 私はこれが正しくないことを完全に理解しましたが、その瞬間、異なる方法で作業することはまったく不可能でした。 スクラムの原則とルールを定性的に知っていたのは私だけでしたが、製品を提示する必要がありました。



プロセス



すべてがこの時点まで比較的うまくいけば、問題が始まりました。 プログラマーは一般的にスクラムをサポートしていましたが、計画については、「なぜそんなに時間を費やすのか」、「私たちは一日中チャットルームに座っていた」という形で異議が始まりましたが、もちろんデイリースクラムについてヒントを与えたとき誰もがショックを受けました- 「毎日チャットするのはひどい」、「誰もがジグ/ビットバッグですべてを見ることができる」、「誰かが興味を持っているなら、彼は尋ねます。」

何かを徐々に導入しなければならないことは明らかであり、ポイントはプロセスが「上から」課されるということではなく、人々は変化を望んでいましたが、これは彼らの強さを超えていました。



私たちはスプリントを導入することから始め、はい、計画しました。

すべてのサブシステムのバックログを1つにまとめ、優先順位付けを試みました。 最初のユーザーストーリーは古いタスクであり、純粋に技術的なものなどでした。 2段階のスケールに基づいてストーリーポイントで評価されましたが、もちろん、初期評価は大きく異なりました。 最初のスプリントは1週間続き、一部はそのような短いスプリントを承認せず、頻繁に「ガタガタ」しましたが、私をサポートしてくれた人は、1週間でもすべてを確実に計画することはできず、大きなスプリントの問題はまだないことを理解しました。



私たちは水曜日の夕方に最初のスプリントを開始し、水曜日の朝に回顧展を1週間にすると決めたので、半日かかり、その後計画して新しいスプリントを行うことにしました。 もちろん、デモの問題はありませんでした。実際、私たちは何も示すことができませんでした。さらに、これはプログラマーの感情的な負担を増やすもう1つのポイントです。

ですから、水曜日の朝、回顧展に到着すると、私たちは皆、「少し仕上げる」というスプリントタスクがいくつかあることに気付きました（実際、少しは仕事の1日を意味する可能性があります）。 ここでもう1つの誤解が明らかになりました。振り返ってみると、問題とプロセスを改善する機会について話し合う必要がありましたが、プログラマは満場一致で「問題はない」と宣言しました。 時間がないとは感じていませんでしたが、今日はすべてについて話し合っており、その後は終了します。 循環プロセスの感覚はありませんでした。



数週間、このモードで作業を続けました。スプリントは途中のセグメントではなく、単なる反復であるという事実に注意を払おうとしました。 最終的に、あまり良くない解決策が見つかりました。 レトロスペクティブとプランニングを分け、火曜日のレトロ、水曜日のプランニング、これらの会議の間で、プログラマーはさまざまなRND問題を解決しました。 しかし、最も重要なことは、レトロと計画の間、過去のスプリントのタスクに取り組むことは禁じられていました。 最初は、不完全なコードが残っていて忘れられていたので、これも好きではありませんでしたが、この方法は功を奏しました。 チームは、スプリントで完了しなかったタスクが実際に完了していないこと、忘れられたり、無期限に放置されたりする可能性があることに気付き始めました。



その間、コードの操作に注意を払う必要がありました。 以前は、テストは主要な機能についてのみ記述されており、実際には、コードの非常に小さな部分をカバーしていました。 この瞬間から、解決する問題に影響するすべてのコードをテストでカバーすることにしました。 ここでも、たとえば計画の最初の5つのスプリントなどの瞬間がありました。「テストでは、このタスクは何ポイントかかるのか」を評価するときに思い出す必要がありました。 しかし、それはまだ非常に単純に実装されており、誰もがなぜこれが必要かをよく理解していました。



もう1つの大きな不幸は、2週間の研究にもかかわらず、人々はまだ「外国」のプロジェクトをよく知らなかったことでした。

まず、プロジェクトAのタスクを計画する際に、それを開発した人が4ポイント、他の16と32を評価しました。このプロジェクトに以前参加していた人がタスクを持っているという事実を考慮に入れる必要があることを説明するのに長い時間がかかりましたうまくいきませんでした。

第二に、開発者はスクラムがチームメンバーに自分のタスクを選ぶように誘うという事実を積極的に利用し始めました。したがって、プログラマーは通常、他の誰かのコードに煩わされないように自分のプロジェクトに従ってタスクを引き受けようとしました。 数週間、ボード上に他の人がいる場合、「自分の」プロジェクトからタスクを取ることを禁止するというルールを作成する必要がありました。 不満がありましたが、私は言わなければなりません、人々がコード全体を十分に研究するとすぐに、それはすぐに無駄になりました。



しかし、もちろん、この移行中に起こった主なこと、そして間違いなく最高のことは、同じテーブルで働いていた少数の善良な人がついにチームになり始めたことです。 それ以前は、彼らは一緒に夕食に行っただけで、それでもめったにありませんでした、そしてその後、本当の相互援助、共同作業と責任が生じ始めました。

開発

ゆっくりと、しかし確実に、私たちは仕事をするのに役立つ正しいプロセスに向かって動いていました。

数か月後、私たちはデイリースクラム（スタンドアローン）を導入し、12：00に割り当てました。それまでは全員が仕事をしていたからです（非常に柔軟なスケジュールになっています）。 スタンドアップで長い間、誰もが作業したタスクを単に呼び出しましたが、これはあまり有用ではありませんでしたが、一定の適応期間が過ぎ、チームは問題と進捗に関する有用な最新情報を本当に交換し始めました。

スプリントは2週間になり、タスクをよりよく評価する方法を学び、それを買う余裕ができました。 ほとんどの場合、計画に関する見積もりは一致し始めました。一致しなかった場合は、すべてについて話し合うことができ、ほとんどの場合、共通の意見になります。

バックログの純粋に技術的なタスクの割合は、徐々に低下し始めました。 そしてますます、タスクはまさに​​ユーザーストーリーでした。



プロセスの弱点は依然として回顧であり、それらのほとんどについて、チームは議論のためのトピックを提供できませんでした。 「私たちはうまくやっています」はかなり一般的な声明です。 スクラムマスターとして、このトピックに関する多数の資料を読み、いくつかの手法を使用し始めましたが、理論と実践には大きな違いがあります。たとえば、根本的な問題を見つける標準的な方法は非常に優れていますが、実際には、既に知っているいくつかのタスクの不可分性に問題がありますが、この問題を解決するのに役立つsingleな方法はありません。 しかし、時間の経過とともに、彼らはイニシアチブを示し始めました。これは確かに非常に有用でした。



Git Flowの使用を開始し、コミットごとに自動テストを実行するようJenkinsをセットアップし、コードカバレッジの測定を開始し、改善を試みました。 最初はスプリントのフロアを占有する可能性があった修正プログラムの数は減少し始めました。 製品の品質、そして最も重要なことはユーザーの気分が大幅に改善されました。 開発プロセスのどこに弱点があるかを分析し、長いコードレビューで何をすべきかを見つけました。

私たちの日々

この叙事詩を始めてから6か月以上が経ちました。 今日、私たちはまだ開発中であり、永遠にそれをやろうとしています。 ただし、結果についてはすでに言うことができます。

• 私たちはすべてのタスクでチームとして働いています。つまり、誰かが病気になった場合、サポートなしでプロジェクトが残されることはありません。
• 実装された機能の数の一定期間にわたる開発速度は、昨年の秋に比べて数倍に増加しました。
• 現時点では、スプリントごとに0から1までのバグと修正プログラムの数は、システムの品質が桁違いに向上したことを示しています。
• 過去6か月にわたって、蓄積されたタスクからバックログを収集し、不要なタスクを削除しました。これは、次の四半期に実際に実装する機能の本格的な動的変更リストです。
• さらに、現実的な見積もりの​​おかげで、チームのスピードを知っている私たちは、長期計画を立てて、今後6か月間で何をするかを計算できます。

まだ多くの仕事があります。 最近、ついにデモを導入する時が来ました。これが何につながるのか見てみましょう。 さらに、私たちはまだ理想からはほど遠いことを理解しており、一桁速く作業してこれを達成しようとすることができます。 しかし、私が言える主なことは、私たちがこれを始めたことを後悔していないことです。多くの困難にもかかわらず、その多くはアジャイルプロセスの経験不足に関連している可能性がありますが、スピードの追求と官僚制への恐怖に導かれた状況から実際に逃げました。



読んでくれてありがとう、私はどんな質問にも答えて、どんな批判も受け入れてうれしいです。