スクラムとペアプログラミング
私は現在スクラムを使用しているチームに所属しており、チームのクロスファンクショナルスキルを向上させ、「2つのヘッドは1つよりも優れている」という哲学で欠陥を減らすのに役立つペアプログラミングを追加することを検討しています。
私たちのチームでは、各チームメンバーは通常、スプリントの計画中にフルワークロードにサインアップします（「フル」は週40時間未満の数であり、会議やコラボレーションなどが可能です）。各タスク。これはスクラムチームではかなり一般的だと思いますが、必ずしも本ではそうではありません。
特に、チームメンバーが作業するために独自のタスクを持っているためにペアリングをためらう状況を避けたいと思います。ペアリングのための時間を確保せずにチームが単純に自己組織化する場合、これは起こりそうです。 。
これを踏まえて、ペアリングの時間を適切に割り当てていることを確認するために、ペアリングシナリオでの労力/時間/ストーリーポイントを説明する最良の方法は何ですか？
考慮されるいくつかのオプションは次のとおりです。
- 2人が各タスクにサインアップできるようにし、（およそ）推定時間数を2倍にします
- 「キーボードを操作する」チームメンバーだけが各タスクにサインアップします。これは、その人の推定時間に基づいて推定されます。ペアリングをサポートするチームの誰もが、ペアリングをサポートする時間を確保するために、スプリントのより少ないタスクにサインアップします。
スクラム内でペアプログラミングが採用されているときに私が見た最も一般的なオプションは、開発の見積もりを2倍にすることです。
つまり、タスクが1人で3時間かかると推定される場合、割り当てられる時間はペアで6時間になります。
それがあなたをよりきれいに感じるなら、ポイントを時間に置き換えてください;）
他の人はすでに良い答えを提供してくれたと思いますが、私が追加するのは、あなたのチームがスクラムに移行したばかりで、私たちが始めたときと非常によく似た立場にいるためです。
まず、アジャイル、より具体的にはスクラムの紹介はあまりスムーズではありませんでした。基本的に経営陣が降りてきて言った、この日からあなたはスクラムを行うべきであり、これはあなたがすべて従うプロセスです。 People over Process。
私たちが最初に行ったプロセス（盲目的に、私は追加するかもしれません）は、あなたが説明した方法と非常によく似ています。人々は割り当てられたタスクを取得し、誰もが予約され、私たち全員が私たちのデスクに戻ってプラグインします。それから私達は退屈なスタンドアップ会議を毎日持っています。
実現するための鍵は、アジャイルとスクラムが含まれているということは、実際には人々についてであることです。チームがイテレーション計画に入るとき、あなたのスクラムマスター（おそらくマネージャーである）に時間、ストーリー、タスクを割り当てさせないでください。それは完全にチーム次第です。多くの人にとって、これは非常に難しい概念だと思います。何年も前に彼らは仕事に来て、彼らには単に仕事を割り当てる上司（マネージャー、テクニカルリード...）がいたからです。彼らはスクラムに飛び込みますが、誰もが（スクラムマスター自身を含む）同じモードで操作を続けます。
ある日、あなたはこれにうんざりするでしょう、それであなたは本やブログを読み始め、スタック交換でこのような質問をし続けるでしょう。あなたが得ることの実現は、開発者とあなたのチームメイトとしてのあなたがストーリーへのコミットとタスクの割り当ての背後にある原動力であるべきであるということです。ペアプログラミングのメリットがあると感じたら、必ずエンジニアごとに2つのタスクを作成し、両方に時間を割り当てます。スクラムマスターがすべきことは、前回のイテレーションでAS A TEAMとして提供した完成したストーリーに対して速度を測定することだけです。
私のがらくたを悩ませるもう1つのことは、容量がIS常に合計時間の75％であることを人々がどのように受け止められるかということです彼らは、a）彼らはあなたを助けることができない、またはb）彼らはあまりにも多くの時間が割り当てられているため、正しいことを行うことができないと不平を言っています。コミットに何時間かかるかは知らされるべきではなく、スクラムマスターがこのようなものをプルしようとしている場合は、プッシュバックする必要があります。誰もが自分が何に満足しているのかを正確に約束すべきです。たとえば、私はチームリーダーであり、計画外のランダムな設計に関するディスカッションをしたり、誰かをコードで助けたり、奇妙な問題のトラブルシューティングをしたりすることがよくあるため、私の能力は50％を超えることはありません。
私たちのチームは、今述べたようなことを行わないことを学ぶのに4つのリリースサイクルを要しました。ですから、まだ学ぶことはたくさんあります。
更新1：クリフのコメントへの応答さて、耳を貸してくれたので、ここに...
そうです、文化の変化が重要ですが、この変化は幹部レベルで起こる必要はありません。自分のグループマネージャーは、チーム内の文化を変えて、彼が対処しなければならない企業のBSからあなたを隔離することができます。あなたが説明しているのは、2007年から2010年までの正確な私たちです。私たちのチーム（および他のチームも）はリリースごとにリリースをフロップしました。経営陣の「アジャイルになるためのプロセス」を使用したリリースの1つで、通常は1人で行う作業を9人のスタッフにプロデュースし、2倍の時間を費やしました。余暇がたくさんあったので、履歴書も更新しました。
次に、上司と話し合って、これらすべてのことを人に対してアジャイルであるということを説明しました。製品について気にしてもらいたい場合は、製品の取り組みと提供方法に影響を与える決定を下しましょう。彼はそれを実験的にすることを決めたと思います、彼は私たちのすべての変更を行いました...まあ、ほとんど私自身ですが、私はチームの他のメンバーと頻繁に話し合います。彼が私たちが求めているすべての変更を加えても失敗する場合、彼は勝利の「私はあなたにそう言った」と戻ってくるだろうと考えた可能性があります。
したがって、過去12か月間に、私たちはあまりにも多くの「愚かな」ことを排除しました。私たちはスタンドアップミーティングを実際に意味のあるものにしています。私たちはまだ製品の特定の部分の所有権を（少なくとも今のところ）持っていますが、お互いのコードに頻繁にぶつかります。チームのメンバーが他のコードを学習するだけでなく、より優れたコーディングおよび設計手法も学習できるように、私たちは常にコードレビューを行っています。モノリシックで巨大な「アジャイル」チームを3つの異なるチームに分割したため、計画やその他のミーティングははるかに短くなり、人々は周りに座って気にしないことについて耳を傾けることがないため、実際に気にかけます。うち5人のうち4人（チームの1つ）が夜11時にオンラインになる夜を見たことがありますが、実際に一生懸命に仕事をしなければならない、または40時間以上仕事をするように圧力をかけられたという人はいません。半年前まで気にならなかった人々は、突然、彼らがしている仕事に従事し、興奮しています。そして、私たちのマネージャーがすることは、「あなたたちは何が正しいかを決定し、あなたがする必要があることをします、そして私はできるだけチームから企業のBSを守ります」と言うだけでした。
それは実験として始まりました（私の疑い、彼は私に言わなかった）が、今、私たちのグループは、部門の他の開発グループと比較して突破口を開いており、私たちに来て参加しようとしている他の開発者もいます。
この変化が起こって以来、私たちにとって最大のハードルは（そして今日でもまだ問題です）、通常の企業環境のエンジニアは、檻の中の実験用マウスのようなものでした。あなたのマネージャーが本当に「機敏」に行くことを決定し、ケージを取り外したとしても、誰もが長い間そのケージにいました、彼らは彼らが自由であることにさえ気づいていません。そのため、すべての自由があっても、彼らはまだ制約を受けているかのように行動し続けます。グループの境界の外に出て、より良い方法を模索するチーム（自分など）を少なくとも数人持つことが役立つと思います。次に、そのグループに戻って少しかき混ぜます。
あなたのケースでは、チームに降りてきて作業方法を伝えるために別の外力を探している場合、おそらくペアプログラミングは解決策ではありません。代わりに、ルールを破棄し、管理なしで彼らと一緒に座り、彼らに何をしたいのか尋ねますか？彼らを幸せにするものは何ですか？生産的？最大の問題を特定し、解決策がどうあるべきかをチームに尋ねます。
スクラムでは、タスクを個人に割り当てることは義務付けられていません。完了するタスクの責任は、全体としてチームにあります。チームがペアプログラミングを実行する場合、各ペアがタスクを選択するのであれば、間違いなくそうする必要があります。
スクラムガイド から：
開発チームは通常、システムの設計と、製品バックログを有効な製品増分に変換するために必要な作業を開始することから始めます。作業のサイズはさまざまで、作業量は推定される場合があります。ただし、開発チームが次のスプリントで何ができると信じているかを予測するために、スプリント計画会議中に十分な作業が計画されます。開発チームによってスプリントの最初の日に計画された作業は、この会議の終わりまでに1日以下の単位に分解されます。 開発チームは、スプリント計画会議中およびスプリント全体の必要に応じて、スプリントバックログで作業を行うために自己組織化します。
会議の計画にタスクを割り当てることは、まさにその時の決定とチームに権限を与えることに反対するものです。また、スプリントの初日から、すべての開発者が自分のやるべきことを正確に調整しているため、スプリントの俊敏性に反します。また、すべてのタスクを非常に正確に推定する必要があることも意味します。
Imhoの推定タスクは冗長です。一連のストーリーにコミットし、ミーティング2を計画するのは、これらのストーリーをタスクに分割し、それらのタスクのカードを作成する（またはそれらをシステムに入力する）のに十分な時間です。各タスクを見積もるのに十分な時間がありません。これらの見積りは、実際の開発に時間を費やすべきではありません。
どうして？見積もりはゴミです。どのようにしてゴミになるのでしょうか？より多くの見積もりを行うことは、より多くのビジネス価値をもたらさないので、それはごみであり、必要最小限に減らす必要があります。最小はストーリーの見積もり/サイジングであり、コミットメントを行うのに役立ちます。コミットメントを行った後は、他の見積もりは必要ありません。あなたはあなたがあなたがコミットした何かを提供するための固定された日付があることを知っています。コミットされたストーリーを提供できるかどうかを決めることができます。タスクの見積もりは、そのデリバリーには役立ちません。
進捗状況の実際の測定値は完了したストーリー（ストーリーポイント）の数のみであり、スプリントバーンダウンチャートに表示できるため、タスクの見積もりをスキップしても、スプリントの進捗状況への可視性にはまったく影響しません。
明確にするために。コミットメントとは= やりますです。それをやろうとするつもりはありません。はい、あなたがコミットしたものを提供することに失敗する可能性がありますが、あなたのコミットメントはあなたの現在の知識であなたが選ばれた物語を提供するというあなたの信念に基づいているべきです。この信念を持っている場合は、別の見積もりは必要ありません。
私は常に、開発者が最後のタスクを完了したときに新しいタスクを選択する方法でスクラムを使用しました。開発者は通常、スタンドアップ会議でどちらを選択するかを言います。一般的に、彼がどのタスクを選択すべきかについてのルールはありません。チームの自己組織化とチームメンバー間の話し合い（スタンドアップミーティング以外）に依存します。それは、想像上の計画に影響を与えることなく、いくつかの変更や問題に対応できる最新の可能な時点まで決定を延期することです。誰かがそれを完了するためにいくつかの問題を抱えている場合、タスク自体が所有者を変更することさえできます-あるいは、そのようなタスクはペアで開発することができます。
ペアプログラミングはこれにどのように関与できますか？簡単に。チームはコミットメントを行い、チームは製品の有効な増分を提供するために必要なすべての開発手法のためのスペースを作る方法でそれを作らなければなりません。タスクまたはタスク開発とタスクテストを見積もりますか？後者のアプローチは完全に間違っています。テストは開発の一部であり、同様に、コードレビューまたはペアリングは必要に応じて開発の一部です。
ペアプログラミングを行うと、バグが少なくなり、コードの品質が向上し、タスクがより速く完了します。速度は2倍にはならないため、オーバーヘッドは残りますが、ペアリングが時々発生することによるコミットメントへの実際の影響は非常に小さいはずです。これは、メンタリングや教育の場合ではありません。メンターや指導が必要な開発者がいる場合は、製品のコードベースや技術を学ぶスプリントの能力をまったく計画すべきではありません。