18

スクラムは最近非常に人気のある開発プロセスであり、多くの場合、プロジェクト マネージャーは突然新しいタイトル (スクラム マスター) を取得します。ただし、それは単なる新しいタイトルではなく、新しい習慣と新しいパラダイムであるべきです。あなたのスクラムマスターの悪い習慣は何ですか?

4

12 に答える 12

14

スクラムを順調に進めていない - 技術的な議論やより長い会議に陥らせてしまう。

于 2008-10-03T19:55:39.133 に答える
10

私たちのスクラムマスターが最初に持っていた大きな悪い習慣は、私たちが自分の障害を処理することを考えていました。それはスクラムマスターがすることになっていることの1つですが、彼女はそれが手に負えなくなるまでそれを私たちに任せました。

私たちが扱ってきたもう1つのことは、タスクが処理されるまで開発者の背中に乗ることを彼らが担当していると考えているスクラムマスターです。彼らは自己管理することになっているので、これはチームに悪い雰囲気を作り出します。

私と私たちのチームにとって、スクラムマスターの仕事は、チームの盾とアシスタントになり、障害をブロックし、物事を迅速に進めるためにできることを行うことです。Ken Schwaberのスクラムを使用したアジャイルソフトウェア開発は、スクラムの優れた入門書です。これは、私たちのチームが使用したものであり、かなり成功しています。スクラムを使用したアジャイルプロジェクト管理もあります。これは、特にスクラムマスターとプロダクトオーナーの役割に適しています。

于 2008-10-03T20:16:59.573 に答える
10
  1. マイクロマネジメント
  2. 自主的なチームを促進する代わりに、古いスタイルのコマンドアンドコントロールを行使する
  3. チームを構成する人々よりも、数字/バーンアップ/バックログに焦点を当てる
  4. チームを外部の干渉から保護しない
于 2008-10-07T15:50:44.147 に答える
10

チームが自分の仕事を管理する方法を学ばせる代わりに、仕事を割り当てて毎日の進捗報告を求めます。

于 2008-10-03T20:02:07.027 に答える
9
  1. ハイパー アクティビティでチームを細かく管理する
  2. 「スクラムが言う」「チームは投票しなければならない」という理由で、技術的な決定について上級開発者をオーバーライドします。上級技術者の権限を完全に奪います。
  3. 実際には問題ではない問題についての回顧展で石から血を搾り取ろうとしています。
  4. ポイントは重要ではありませんが、各レビューでポイントが分析され、レビューで2週間ごとに分析されます. さらに、年間ボーナスはポイントのパフォーマンスに基づいています。

スクラムは優れていますが、長い間魅力的に機能してきた優れたエンジニアリング プラクティスや技術プロセスを無視する可能性があります。

于 2009-09-05T13:36:23.970 に答える
7

スプリントの内外で常に新しいバグを交換します。

于 2008-10-03T19:58:50.013 に答える
6

スクラムマスターには次の 2 種類があります。

  1. アジャイルの採用により肩書きが変わったプロジェクトマネージャー。
  2. スクラムのファシリテーションのみを行い、プロジェクト マネージャー (shusa) に報告する専任のスクラム マスター。

2 番目のポイントは、「真の」アジャイル組織で説教され、実践されています。高価ですが、いくつかのメリットがあります。

また、

  1. スクラム マスターは、スプリント チームと常に一緒にいることが期待されます (文字通りではありません)。プロジェクトマネージャーがそれを行う場合、彼/彼はマイクロマネジメントになります。
  2. スクラム マスターの役割は、予算を管理することではなく、チームが実行できる作業量に関して、スプリント チームに予測可能性を持たせることです。
  3. スクラム マスターは、チーム メンバーの長所と短所を理解し、スクラム間のベスト プラクティスの共有を促進する必要があります。

つまり、私のポイントは、これらの役割が混同されていると、チームはうまく機能しない可能性があるということです.

于 2009-01-03T16:36:33.863 に答える
5

プロセスのプッシュバック部分を支援しない。たとえば、「これらは顧客がこの反復で必要とするすべての店舗なので、それが私たちがしなければならないことです」.

于 2008-10-03T19:54:42.533 に答える
3

実際の作業時間をストーリー ポイントの見積もりに結び付けようと常に試みていました。

于 2008-10-03T23:30:35.703 に答える
1

私は、元 PM がスクラム マスターに転向したときに、スクラムを、その時間をチームワークや積極的なストレス軽減 (後退の計画) に投資することなく、元の (個人の) 義務を削減する方法だと考えていることを本当に嫌います。彼らはリラックスして素晴らしい結果を称賛し始めますが、彼らの存在がなければチームのパフォーマンスがさらに向上することは誰の目にも明らかです。

私の意見では、私たちの最高のスクラム マスターは、大きな責任感を持つ開発者、または非 PM です。

繰り返しになりますが、私は (世界がスクラムについて知る前に) 真剣に揺れ動いた PM のために働いてきました。彼らは今日、素晴らしいスクラム マスターになると確信しています。

于 2009-09-08T12:56:52.350 に答える
1
  1. サイクル内でタスクを適切にスロット化できない (通常は多すぎる)
  2. 外部の顧客にうまく対処できない (特定のタスクが 1 つのサイクルに対して大きすぎる場合、顧客を押し返す代わりにチームに泣き言を言う)
  3. 毎日のスクラムのプロセスが大きすぎる -- 特定の時間制限に固執しない (最大 15 分が望ましい)。
于 2008-10-03T22:23:34.277 に答える
1

私がスクラムに関わっていたとき、スクラム マスターはすぐに、私たちに自分のことを任せるという習慣を身につけ、スクラムは私たちの通常の開発ルーチンに戻りました。

于 2008-10-03T19:53:36.437 に答える