この記事では、Acronisでさまざまな開発管理手法（ウォーターフォール、スクラム、かんばん）を使用した経験を共有し、特定の手法または実践の選択の原因を説明したいと思います。
いくつかの入門的な言葉から始めましょう。 通常、Acronisの製品開発サイクルは6か月から1年続きます。 40〜45人のチームが開発に参加しています。 製品自体はシステムアプリケーションであり、主な開発はC ++です。 重要なポイント：製品は、固定された時点よりも遅くなく正確にリリースされなければなりません（はい、はい、それが起こります）。
当社の最後の発案はATIであり、 Acronis True Imageとして世界的に知られています。 この製品はかなり長い間開発されてきたので、Habrでそれに関する記事を1つも2つも2つも3つも書きませんでした（4つ目は自分で見つけてください ）。 ATI開発チームは非常に印象的であるため、このようなプロジェクトの管理において豊富な経験を積んでいます。
そのため、昔々、古典的な「ウォーターフォール」開発モデルがありました。
要件->設計->実装->テストと安定化->サポート。
この理由は何ですか？ 部分的にこれは歴史的に起こり、部分的にはほぼ毎年製品に新しい技術が登場したためです。 カスケードモデルでより便利なのは、まさに既存のテクノロジー全体に基づいた製品ではなく、まさに開発された新しい技術ソリューションです。 確かに、ハードディスクのスナップショットを作成する開発を1回のイテレーションに入れて、それをユーザーインターフェイスに拡張し、1回の短いイテレーションで結果を表示できるようにすることは困難です。
次に、柔軟な開発方法論に焦点を当てます。 将来に目を向けると、短い反復での柔軟な方法論により、チームは非常にアーキテクチャ的に正しくないソリューションを作成するようになります。 技術的な負債が蓄積し始め、遅かれ早かれ支払わなければなりません。 そして、率直に言って、2004年から2006年のロシア（そしておそらく世界）で、アジャイルやスクラムはまだあまり人気がなく、有名ではありませんでした。
しかし、明らかに、欠点もありました。 私たちの場合、最大の問題は時間通りに取得することでした。 はい、計画は行われ、時にはプロトタイピングさえ行われましたが、この機能セットの作成が期限に間に合うかどうかを予測することは非常に困難でした。 さらに、この場合の開発は水平方向に行われ（最初にシステムロジック、次にビジネスロジック、次にUI）、結果として均等に不安定な機能の均等な層が得られ、それは長く高価な安定化サイクルを必要としました。
アジャイル 長い繰り返し
まず、1〜2か月（通常は2か月）の反復に切り替えることにしました。各反復は、実際には小さなカスケードサブプロジェクトです。 最初のイテレーションでは、重要で困難な機能を実装し、次のイテレーションでは、それほど重要ではないなどの機能を実装しました。 私たちはしばしば最後の繰り返しを破棄し、今回は安定化に専念したことが判明しました。 肯定的な結果が明らかになりました-プロジェクトはより予測可能になりました。
ただし、ご存じのとおり、常に「BUT」があります。 原則として、反復は期限に収まりませんでした。多くの機能が長い反復で実装されたため、技術的な負債とエラーが累積し始め、安定させる時間がありませんでした。 その結果、私たちはまだ安定期間を待っていました。 確かに、いずれかの反復の終わりに、より早く開始することを決定できます。
スクラム
私たちがプロジェクトに取り組んでいると、プラクティス自体が現れ始め、その必要性を自分自身で感じました。 そのため、プロジェクトのコミュニケーションが不足していることに気付きました。一部のチームメンバーは、「自転車」を書いたり、コードを複製したり、詳細を明確にするのが恥ずかしすぎて時間を遅らせたりする傾向を示しました。 これに気づいた私たちは、前日の問題と今日の計画を議論するために朝の会議を開催することにしました。 そのため、スクラムについて何も知らずに、その要素の1つを作業に導入しました。 さらに、この手法は開発者自身によって非常に前向きに認識されていました（ご存じのように、常にそうなるとは限りません）。 これは、そのアプローチがその時点で私たちの差し迫った問題を解決していたという事実によると思います。
次に、スクラムプラクティスの適用を開始する必要があることを認識した方法について詳しく説明します。
締め切りに間に合わせるための要件は私たちにとって最も重要であるということを思い出させてください。そのため、最初に行うべきことは、プロジェクトがタイムラインのどこにあるかを常に理解する必要があることです。 原則として、現在のタスクのバーンダウンチャートでこの質問に答えることができます。
しかし、いくつかのニュアンスがあります。
1.最初から、適切なプロジェクト計画が必要です。 良いとは非常に詳細な意味です。すべての機能を説明し、考え、計画する必要があります。 カスケードモデルの最初の段階に非常に似ています。
2.計画が実行されると、サプライズが発生することが保証されます。
3.時間が経ち、人々は通常、それに伴って新しいタスクを設定します。
必要なのは、当初からの詳細なプロジェクト計画ではなく、品質と最終リリース日を管理しながら、変更に迅速に対応する能力であることがわかります。 スクラムの実装には時間がかかりましたが、すべてがスムーズに進むとは限りませんでした。 スクラムプラクティスから私たちが行うことの概要を以下に示します。
1. 2〜3週間スプリントします。 最近、3週間はさらに効果的であると判断しました。
2.各スプリントには、再計画、デモ、および回顧が含まれます。
3.すべてのプロジェクト参加者のスプリントの目標を明確にします。
スプリントの目標はユーザーストーリーです。 優れたユーザーストーリーがなければ、効果的なスプリントは機能しません。
ユーザーストーリー
なぜ私たちはそれらについて話しさえしたのですか？ Acronis開発者の一般的な要件は、製品の機能の特定の部分の動作を説明する大きな「シート」です。 たとえば、コンピューター全体をバックアップします。 さらに、何をコピーし、どこをコピーし、どのようにコピーするかを説明する要件もここにあります。 そして、真剣に座ってこれをすべてペイントすると、複数ページのテキストが表示されます。
この説明を得たとします。 さらに、この説明はプロジェクトマネージャー、開発者、テスターが理解する必要があります。 これをすべて実装するには開発者向けのタスクを取得する必要がありますが、テストするために多くのテストケースを作成する必要がある人もいます。 主な問題が発生します：要件が満たされていることをどのように理解するか？ それがまさにストーリーとユーザーシナリオを説明することにした理由です。
ストーリーの典型的な形式は次のようになります。
1.ユーザーの問題。どの履歴を解決するか。
2.ストーリー自体。
3.チェックリスト。
問題の説明は、私たちが何をして何をしているのかを明確に理解するために非常に重要です。 チェックリストは、ストーリーが合格しなければならないテストケースの最小限のセットです。 実際、これはすでに行われていることの定義です。 ストーリーの重要な要件はそのサイズです。1つのストーリーが1つのスプリントに収まらなければなりません。
かんばん
上記のメカニズムの導入により、他の問題が明らかになりました。チームが同期していないことと、個々のメンバーの焦点がずれていることです。 このことは何を示しましたか？ 「要件の開発」の段階で長い間製品要件の開発が困難でした。 なんで？ 第一に、ある種の需要を仕事に簡単に取り入れることが常に可能であり、交渉を延期し、プロセスの他の参加者との問題を解決しました。 2番目の問題は、スプリントの首尾一貫した画像の欠如です。スプリントを正常に完了するために、今、何が重要ですか？ 何か仕事をすることは可能ですか？ ボールはどちら側にありますか？
私たちにとっての問題の解決策は、各列のストーリー数に制限のあるかんばんボードを使用して（フォーカスを維持するため）、ユーザーストーリーの作業の特定の各段階に責任を持つ人々を明確に特定することでした。 さらに、かんばんボードの使用は、作業におけるスクラムの慣行と矛盾しません。
結論
読者への主なメッセージは次のとおりです。最初に-問題を理解し、それから-その解決策。
結果や問題の解決のためではなく、方法のためにいずれかの方法を選択したいという希望をよく見ます。 したがって、この記事では、必要なものと、この方法またはその方法論が適切な場合を具体的な例で説明しようとしました。
カスケード-正統派の古典、コードの支持者。
アジャイル-有能なリーダーと時間管理の第一人者を中心に、特にプロセスに無関心ではないチーム向け。
スクラム-確立されたコミュニケーション、役割と互換性の明確なシステムを備えたチーム向け。 そして、重要なことは、このシステムは、仕事のリズムを取り入れ、プロセスの改善に参加する準備ができている顧客に適しています。
最後に、かんばん-タイムボックスがない場合に大きな問題を解決する準備ができているチーム向け。 つまり、進行中の作業量を最小限に抑えることが最も重要な人向けです。
各プロジェクトは開発の方法論に値する
（Acronis開発チームのマントラ）