スペシャリストチーム向けのスクラム


11

スクラムは、ジェネラリストメンバーがいるチーム、つまり、少なくとも2人が同じタスクを実行できるチームに最適です。私の主な関心事は、専門家で構成されたチームのためにスクラムを適応させるための優れたソリューション(何を保持し、何を削除し、改善するか)を見つけることです。

5人の開発者からなるチームがあると仮定します(実例ではなく、単なる例です)。

  1. Cの強力なスキルを持つ1人の数学者。
  2. 1人のDB開発者。
  3. 1人のWeb開発者。
  4. UX / GUI開発者1人。
  5. 1人のソフトウェアアーキテクト。

ここでは、すべてがスペシャリストであり、誰も他の誰かを置き換えることはできません(このようなチームを構築するリスクは気にしません。スクラムに集中したいと思います)。だから、スクラムの文脈で、ここに私の考えがあります:

  1. 役に立たない春の計画:実際、数学者が特定のタスクに2ポイントの価値があると言ったとき、誰も彼に反対することはできません。
  2. 役に立たないチーム速度メトリック:誰もが自分のタスクに任意の数のポイントを割り当てることができるため、速度の計算は意味がありません。
  3. 毎日のスクラム会議を毎週(より長い)スクラム会議に置き換えます。チームの各メンバーが自分のタスクに取り組んでいるため、毎日のスクラム会議は「チームスピリット」を維持するために非常に重要です。ただし、毎日のスクラム会議は約15分間続くことになっています。これは明らかに、他の人が何をしていて何をするのかを理解するには不十分です。さらに、数学者はほとんどの場合、同じことを答えます。「私はまだ%&Lo(+?$$ +&)をやっています」...毎週のミーティングでより多くの時間が与えられます。「最初の」スクラム会議と「毎週の」スクラム会議の間で同じ会議時間を維持するには、各週のスクラム会議を継続する必要があります(週5日、4週間のスプリント、スプリント会議は4時間、毎日の会議は15分)。 (4 * 60 + 20 * 15)/ 4 =>

または、スクラムはまだ使用可能ですか?たぶん別のアジャイル技術を使用する必要がありますか?


好むと好まざるとにかかわらず、スクラムからすべてのスクラムを取り出すと、スクラムはもう行われなくなります。ところで、毎日のスクラムは15mよりも5mのようにすべきです。
Jamiec

まあ、SOにはスクラムタグがあるので、スクラム関連の質問をすることができると思いました^^。また、すべての参照は、私はしません5.、15分の日々のスクラムを使用している
Korchkidu

うん、スクラム、アジャイルタグは、programmers.seよりも前のものだと思う-しかし、確かに今日では、そのような質問をするのに良い場所です。
Jamiec

はい、ありがとう。この質問をprogrammers.seに移行することはできますか、それともこの質問を削除して新しい質問を再開する必要がありますか?
-Korchkidu

'私はこれを動かす力を持っていないことを恐れています。ごめんなさい。
Jamiec

回答:


7

スクラムは特効薬ではありません。すべてのプロジェクトが成功するためにスクラムを使用する必要はありません。ただし、あなたが説明している状況は、リーン/カンバンにぴったりのようです。あなたはそれをチェックアウトしたいかもしれません。

かんばんは基本的にいくつかのことだけを行うように求めますが、あなたが説明しているチームの種類と対立するものはありません。

  • 価値の流れ、つまりかんばんボードを視覚化します。スクラムボードは、かんばんボードの特定のアプリケーションです。特殊化を可能にするためにそれを適応させることは可能です。
  • チームに割り当てられた作業量が作業の流れを維持するのに十分であるように、進行中の作業(WIP)を制限します。つまり、ストリームの開始(設計)または終了(配置)で「閉塞」がありません。

かんばんに関​​するいくつかの参考資料をご覧ください。


大助かり!リーンとかんばんをチェックします!SEでどのように+2するのか?..;)
Korchkidu

2

あなたは、アジャイルが提供するものを見ることなく、スクラム/アジャイルのメカニズムに少し集中しすぎています。あなたは、数学の男が2ポイントを推定した場合、誰も彼が間違っていると言うことはできないと言います。これは目標ではありません。目標は、今後のスプリントの達成可能な目標セットに同意することです。そのタスクの専門家として、彼はそれがどれくらいかかるかを最もよく知っているでしょう。

「だから、彼が嘘をついたり、それを間違えたらどうするの?あなたは言う。私の経験では、正確な推測をするために撃たれるのではないかと恐れているため、人々はさらに多くの見積もりを下しています。推定中の他の人は、すべてのバランスをとる安全マージンを追加し、奇妙な怠け者は過剰に見積もるので、急ぐ必要はありません。3つのうち1つ目はベロシティトラッキングでピックアップされ、2つ目は間違った音で動作し、3つ目はスクラム以外で対処する必要があるものです。

毎日の会議にはまだ利点があります。チームメンバはそれぞれスペシャリストであっても依存関係があります。UIの人は、サーバーの人が通知のバグを修正するのを待っているかもしれません。サーバーの人は、計算が間違っている理由を解明するために数学の人を待っているかもしれません。また、彼らの仕事があなたにどのように影響するかだけではありません。「Reason X」が原因でチームメンバーが常に遅延しているが、将来の「Reason X」の発生を緩和するために時間がかかっていない場合は、チャレンジすることができます。


私はコミュニケーションがまだ起こるべきであることに完全に同意します。ただし、スプリントプランニングのミーティングは、ストーリーポイントを評価するだけです。ストーリーごとに一人がその価値を見積もることができれば、この会議は役に立たないでしょう...そして、スクラムのメカニズム(一般的にはアジャイルではない)は本当に重要だと思います。
-Korchkidu

1

説明したような資格を持つ専門家がいる場合、各自が自分のタスクに取り組んでおり、他の人と通信する必要はほとんどないという仮定は間違っています。実際、新しい機能(「ユーザーストーリー」)を実現するには、多くの場合、

  • データベースを変更する
  • GUIまたはWebインターフェースの追加または変更
  • これを正しいビジネスロジックと組み合わせます(おそらく、あなたは「数学者」が入ってくるでしょう)
  • これらの変更がすべて一緒にうまく機能することを確認してください

だから、彼らはゼネラリストのチームのように、もっとコミュニケーションをとる必要があると思います。そこでは、誰もが異なるアプリケーション/ユーザーストーリーに取り組み、すべてのアプリケーション層に必要な変更をすべて自分で加えることができます。したがって、上記のスクラムのすべてのチームアクティビティは、このようなチームにとって非常に理にかなっています。


「だから、ジェネラリストのチームのように、彼らはもっと多くのことを伝えなければならないと思います」:これは実際に私のポイントです。そのため、毎日のスクラム会議では不十分であり、毎週の会議に置き換える必要があると考えています。または、代わりに30分間続く毎日のスクラム会議。
-Korchkidu

@Korchkidu:いいえ-毎日のスクラム会議は技術的な会議ではなく、進捗レポートです。会議に15秒を費やして、その日の後半に15分の会議をスケジュールします。スクラムマスターとして、スタンドアップに集中することはあなたの責任です。
MSalters

はい、確かに。したがって、15フィートのスタンドアップと15フィートのオプションの技術会議があれば、それが可能性があります。ありがとう!
Korchkidu

1

スクラムは確かにあなたの状況に適していますが、他のフレームワークも同様です。

新しい機能を提供するには、これらのスキルのすべてまたは多くが必要になる可能性があります。チームが相互に影響を及ぼし、協力して意思決定を行うためには、コミュニケーションをとる必要があります。スクラム会議の間隔が長いほど、ネガティブな計画がチームを逸脱する可能性が長くなります。毎日ミーティングを行うことで、チームはこれらの状況に迅速に対応し、新しい計画を立てることができます。

あなたが提起するいくつかの特定のトピックにも対処したいと思います。

機能 横断チームチームは、スプリントの目標や製品のバックログアイテムを提供するために必要なすべてのスキルを備えている場合、機能横断と見なされます。これは、すべての仕事に2人いるという意味ではありませ

サイジング ソリューションまたはソリューションの一部ではなく、ビジネスの問題またはニーズのサイジングを行っていることを覚えておくことが重要です。たとえば、ソーシャルメディア/ Twitterを電子商取引サイトに統合することは、UX、UIデザイン、プログラミング、データベース、Twitter APIの知識を必要とする問題です。チームはこの機能を提供するため、チームとしてそれをユニットとしてサイジングする必要があります。このサイズは100%正確ではありませんが、相対的なサイジングに基づいた予測は、全体としてより正確であることがわかります。これは、一部は高く、一部は低くなり、計算された予測は推定期間よりも正確であることを意味します。

役に立たない春の計画 スプリント計画は、スクラムチーム(開発チーム+プロダクトオーナー+スクラムマスター)として協力して、何を作成するべきかを決定し、開始方法の計画を立てるときです。一部のチームは、選択されたこれらの製品バックログアイテムをタスクに分割しますが、他のチームは、合格する必要のあるテスト(XPなど)のような独自の進捗方法を考え出します。

これは双方向のコラボレーションです。チームに一連のPBIを割り当て、「go」と言うことは独裁者の役割です。チームはスプリントの時間を最大化するためにプロダクトオーナーと交渉しています。

役に立たないチーム速度メトリック アーキテクチャ/システムを切り抜けるビジネスの問題とニーズのサイズを決定するチームと、チームが一貫した時間枠(スプリント)で配信されたチームの数を示す過去の経験により、チームの予測を提供できるようになりましたバックログの残りの部分。

繰り返しますが、2つのスプリントは同じものではなく、使用する製品バックログアイテムのサンプルセットが小さいほど、推定値の誤差は小さくなります。株式市場のように考えてください。常に上昇していますが、だからといってダウンタイムがないわけではありません。総計でお金を稼ぐことができますが、任意の月、四半期、年にあなたは間違っていると思います。

毎日のスクラム会議を毎週の(より長い)スクラム会議に置き換える毎日のスクラム は、チームに24時間のフィードバックサイクルを提供し、次の24時間を計画する機会を提供します。これ以上でもそれ以下でもありません。「3つの質問」は、その努力を促進するためのものです。

5日間フィードバックがない場合、タスクは十分にきめ細かくないと思います。これは単に私の意見ですが、コーチおよびチームメンバーとしての私の経験に基づいています。チームはFARを頻繁に話し合い、計画し、統合する必要があります。

結論 スクラムは、学習を促進し、その学習と配信(実際の学習が行われる場所)のバランスを取ることを目的としています。時間の経過とともにプロセスとツールを試し、スクラムを使用して影響を検査します。毎日のスクラムから毎週のスクラムに移行してみて、それがチームが適切な機能を提供するのに役立つかどうかを確認してください。それはあなたのために働くかもしれません。


1
あなたの答えは詳細であり、それらのスクラムの構成要素間の理論的根拠をよく説明していますが、質問の核心に答える場所がわかりません。そのようなチームにはうまくいきません。
Doc Brown

まあ 私の試みは、懸念の各項目に直接対処することでした。私の結論は確かに貧弱でした。応答に感謝します。
ライアンクロムウェル
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.