定義された役割を持つチームでスクラムを機能させるにはどうすればよいですか？
背景情報
私は社内のソフトウェア開発チームの一員です。それはで構成されています
- 5人の開発者（2〜5年の経験を持つ私はその1人です）
- 3人の実装スタッフ（ソフトウェアの導入とトレーニングを担当）
- と1人のプロジェクトマネージャー。
私たちは多くの中小規模プロジェクトを開発しており、それらのタイムラインは通常重複しています。開発は次のようになります。
- 「クライアント」は、一連の初期要件を提供します
- 上記の仕様に合わせてシステムを開発
- 上記のシステムを「クライアント」に提示する
- 「クライアント」は、このプレゼンテーションに基づいて追加の要件を提供します
- 「クライアント」が新しい要件を使い果たすか、展開の目標日が近づくまで、2〜4を繰り返します。
- システムをセットアップして展開する
これは、ほとんどの場合に締め切りを処理するのは「クライアント」であるという事実（プログラマーとPM.SEで私が見ているものから、これは危険信号です）と、明確な開発方法論に従っていないという事実とりわけ、カウボーイコーディング、保守が困難なコード、本番環境で発生するバグなどです。それが、スクラムのようなアジャイルベースの方法論を採用することを選択した理由です。
なぜスクラムなのか？
それは私たちのマネージャーの主導であり、私たちの現在の状況を考えると、誰もがそれに同意するようです。
スクラムの問題
スクラムの一部の要素は、現在のセットアップと競合しているため、簡単には対処できません。特に、アジャイル開発者の「すべてのトレードのジャック」という性質があります。導入チームはプログラミングの方法を知らず、開発者は平均以下のコミュニケーションとトレーニングのスキルを持っています。そして、このラインナップは実際にはすぐには変わりません。
質問
方法論としてのスクラムの有効性に影響しますか？補正するために他の変更を行う必要がありますか？または、思考を完全に放棄して、別の方法論について考える方が良いでしょうか？
実際、あなたの現在の作業方法は、ご想像のとおり、スクラムからそれほど離れていません。
スクラムでは、要件の初期セットも取得し、それらを実装して結果を実証します。デモに基づいて、新しい要件をユーザーに提供したり、関係者が製品を十分に優れていると判断したりして、さらなる開発は必要ありません。
あなたの状況では、あなたが話し合った「クライアント」にスクラムのプロダクトオーナーの役割を与えることができます（彼らはすでにプロジェクト内に優先順位を設定し、いつ準備ができるかを決定することによってその役割を果たしているようです）ロールアウト）。
大きな変更の1つは、反復の長さです。スクラムでは、反復は1週間から4週間の間続くはずです。
チーム構成とすべてのトレードの誤解については：スクラムはnotが全員にすべてのトレードのジャックであることを要求します。スクラムでは、チームが全体として、製品を要件のリストから展開済み/展開可能なものまで取得するために必要なすべての能力を備えている必要があります。
あなたの状況では、1人以上の開発者（主に実装とテスト作業を行う）と、マニュアルの作成とトレーニングに主に焦点を当てている「実装スタッフ」のメンバーで構成されるプロジェクトごとのチームを簡単に見ることができます開発者が現在実装している機能の資料。
クライアント/プロダクトオーナーが展開に青信号を出した後、スクラムチームの作業はほとんど完了します。そのため、開発者は別のプロジェクトに行くことができ（展開後の問題を修正するためにオンデマンドでのみ利用できます）、実装します。スタッフは、トレーニングの実施とロールアウトのサポートに切り替えることができます。
そのリリースで必要な機能に十分な柔軟性がある限り、期限があるという事実は実際の問題ではありません。
あなたは代替案を求めているので、eXtreme Programming（XP）と言います。具体的には、ペアプログラミングが役立つと思います。
スキルの異なる人をペアにすることで、コーヒーの製造、テスト、トレーニングなど、どのスキルでもかまいません。チームにスキルを広げることができます。
しかし、正直なところ、SCRUMがそれほど遠くにあるようには思えません。 SCRUMの一部は柔軟で、チームに最適なものを見つけることです。 XPはあなたのチームを尊重し、順応しています。おそらく100年後には、厳格で迅速なルールを備えたより完全に発展した専門職になるかもしれませんが（私はそれを疑いますが）、今のところ、重要なのはフィードバックループを持つことです。何かが機能しない場合、チームはそれについて話し合い、機能するものが見つかるまで新しいことに挑戦する必要があります。
役割が定義されたチームでスクラムを機能させる方法は？
早くやれよ。 スクラムガイド によれば、誰もが開発者ですが、ここ地球に戻って、さまざまな人々がさまざまなものをテーブルに持ってきます。私は ほぼリンチされた ある人が本当にテスターである一方で他の人がソフトウェアを書いていると提案したとき。
あなたが対処したいかもしれないいくつかのこと：
スプリント
最初の開発フェーズに続いて、表面的にはスプリントと呼ばれる一連のものが続くようです。これを分割することを検討してください。クライアントは何かを早く目にするだけでなく、開発のマイルストーンが発生するので、より良い感覚を得られます。
固定期限
これは何度も何度も発生し、実際に私が現在働いている開発者側の永続的なとげです。スクラムはスプリントの見積もりを設定します-それ以上はありません。はい、一連のスプリントの後でターゲットに到達する可能性がありますが、クライアントが初期のバージョンに目を向けると、スコープが大幅に拡大する可能性があります。これ自体は問題ではありませんが、クライアントは、後のスプリントでさらに作業が行われ、既知の要件を超えていることを認識させる必要があります。
かんばんには、最初からやり直すことができるので、かんばんの状況に適している可能性があります。つまり、現在のプロジェクトに悪影響を与えるようなビッグバンの導入はありません。まず、ボード上のタスクを視覚化し、回顧や毎日の会議などのプラクティスの一部を採用するだけです。
スクラムはそれほど規範的ではないため、スクラムよりも少し注意する必要があります。そのため、適切なアジャイルな考え方を導入するのではなく、以前に行ったものに戻ってしまう傾向があります。
完全なスプリントのためにプロジェクトに取り組んでいる安定した人々がいないため、オーバーラップする個別のプロジェクトではスクラムはうまく機能しません。したがって、冗長性などの概念は、単にあなたを落ち込ませる可能性があります。
ただし、次のストーリーに取り組む前に、クライアントに最高のコスト/メリットをもたらすストーリーを最初に取り、展開するのに十分な品質で完全自動テストを含めてそれを実装することは、有用な概念です。同様に、ストーリーが「完了」と見なされる前に、ストーリー用に作成されたすべてのコードを別の開発者がレビューする必要があります。
私はあなたの実装スタッフがトレーニングと参照ドキュメントを書く必要があると思います、それらはコードが書かれる前に各ストーリーのために書かれることができ（最初のドラフト）、それゆえ受け入れテストになります。
実装スタッフの入力が開発者に最も役立つ各プロジェクトの開始時に、前のプロジェクトの展開に100％取り組んでいることがわかります。したがって、開発者が現在のプロジェクトのコードを記述している間に、実装スタッフが次のプロジェクトのストーリーとユーザードキュメントの記述に取り組んでいるかどうかを検討してください。
テストで使用される例を実装スタッフが作成する「行動主導型開発」が機能する場合があります。
ですので、あなたに役立つスクラムが少しありますが、スクラムを使用する代わりにスクラムを利用してみてください。