「テーラードスクラムアプローチ」でよくある間違いは何ですか？
私はこれを以前に見たことがあります。経営陣はアジャイルで精査されることを望んでいますが、現状から抜け出すことは望んでいません。私の最近の観察も同じです。ここでは、スクラムは組織に合わせて調整されています。特に奇妙な多くの人々のプロセスに。
ここhttp://img684.imageshack.us/img684/6175/modifiedscrum.jpg
さまざまな参加者を示す図。
これが機能しない理由をリストしたドキュメントをまとめています。明らかなものは次のとおりです。
1。 製品所有者（明らかなWTF）が製品所有者に報告します：意思決定能力の希薄化を引き起こします
2。従来のアプローチのマネージャーと同様に見える役割があります-開発マネージャー：コマンドアンドコントロールモデルでの明らかな試み
3。 ScrumMasterの役割には、バーンダウンチャートの代わりに進捗状況の追跡に使用されるtimesheetsの収集が含まれます：やる気のあるチームを構築するためのアジャイルの取り組みに有害個人
「経営陣をどのように説得しますか？」という質問を残して、私の質問は、「この/類似の「テーラードスクラムアプローチ」の失敗として他に何を見ているか？
[〜＃〜]編集[〜＃〜]：図にはさらにいくつかの詳細が使用されている場合があります
1。 開発マネージャーは、開発チームの一部ではありません。ただし、以下を除いて、明確に定義された責任はありません。開発者のパフォーマンス評価、採用など。
2。すべてのチームに同じ製品所有者がいる3つ以上のチーム（スクラムマスター+開発マネージャー+開発チーム）があります！
コメントから移動...
ロビー活動を行う前に、試してみて、どのように機能するかを確認することを検討しましたか？彼らが時間の経過とともに構造を適応することにオープンである限り、それが手紙のアジャイル教義に従わないことを除いて、この計画に致命的な欠陥は見られません。
考慮すべきもう1つのことは、ビジネスリーダーのアイデアを十分にアプローチに取り入れて、アジャイル採用の所有権を感じられるようにすることです。もしそうなら、物事が横向きになった場合、彼らはそれを軽蔑するのではなく（彼らのアプローチがより良かったので）それが成功することを確実にすることに権利があります。そして、特に最初は、必然的に横向きになります。人々は通常、変化に抵抗力があり、新しいやり方を採用せざるを得なくなると、しばらくの間不器用になることがよくあります。
経営陣を敵対的ではなく、プロセスのパートナーにします。
開発マネージャーとある程度までスクラムマスターは、技術リーダーの従来の役割のバリエーションです。典型的なテクニカルリードよりも、開発マネージャーが多かれ少なかれコマンドとコントロールを持っているとは思いません。
スクラムマスターはそれよりも少し特別です。開発マネージャーはスクラムマスターであってはなりませんが、スクラムマスターがPM）になれない理由はありません。なぜなら、彼らはタイムシートに最も関心があるからです。プロジェクトのスケジュールは、ユーザーストーリー、ポイント、バーンダウンチャートの概念と矛盾していません。
プロダクトオーナーエージェントの役割については、ある程度のポイントがあります。その役割の人が指揮系統の追加のリンクになること以外に明確な固有の責任があるとは思えません。
ただし、プロダクトオーナーは途方もなく重要です。彼はその製品を所有しています。私はそれの重要性を説明するつもりはありませんが、ミドルマネージャーがあまりにもチキン-$$$$で、製品の方向性の所有権や製品に関する決定を下すことができなかったために明確な製品所有者がいないプロジェクトに取り組んだことがある場合PRODUCTを実行すると、開始する前に、完全に妨害されることがわかりますすべてのプロジェクト。
会社がどのように構成されているか、スクラム開発プロセスの人々がどのように構成されているかを区別するためにそれらが必要です。これは組織図では問題ありません。
非常に大規模なERPプロジェクトの場合、独自の製品所有者がいるほぼ別個のセクションを持つことができます。彼らは誰かに報告する場合がありますが、スクラムの観点からは、1人の製品所有者が協力する必要があります。プロジェクトのその部分に割り当てられたグループ。
開発マネージャーは、評価を行ったり、休日のスケジュールを整理したり、開発とは関係のないその他のマネージャーの職務を行ったりする可能性のある人物です。
2つをどのように分離するかを見せてください。大企業に小さなスクラムグループが存在できない理由はありません。あなたは人々が両方の世界のどこに収まるかを知る必要があります。
実際、それほど遠くはありません。それは特定の人々の役割が何であるかに依存します。
チーム内には、（要件の生成、優先順位付け、および受け入れを担当する意思決定エンティティのように）製品所有者の役割を担う複数の人がいる場合があります。大規模なプロジェクトでは、1人ですべてを行うことはできません。重要なのは、プロダクトオーナーとの間の単一のコミュニケーションパスがあり、そこに質問が送信され、そこから要件ディレクティブが送信されることです。ただし、多くの人がプロセスを支援します。要するに、彼が答えを得るために誰と話しているか、または彼が誰を通して答えを伝えているかに関係なく、あなたが質問で呼ぶことができる一人の男が常にいるはずです。したがって、エージェントが単にIPMと毎日のスタンドアップに鶏肉として参加し、POに報告する製品所有権の「チーム」からの誰かである場合、それは問題ありません。 POはどこにでもあることはできません。これが他のエージェントやプロダクトオーナーから独立して意思決定を行うことができる人、またはPOへのアクセスを制限するように設計されている人である場合、それは問題になる可能性があります。
開発マネージャーは「プロジェクトマネージャー」または「チームリード」のように聞こえます。また、優れた設計構造を維持し、特定の領域を開発する際に従うべきエンタープライズレベルのパターンを決定する責任者である「アーキテクト」である可能性もあります。通常、アーキテクトは1人だけです。たとえば、プロダクトオーナーは1人だけです。したがって、この人が「プロジェクトマネージャー」または「アーキテクト」の役割である場合は、チームごとの仕事ではなく、チーム間の仕事である必要があります。
このチャートにはBAが表示されていません。私の最後のアジャイルの仕事で、BAは生のストーリーを受け取ってレビューし、スケジュールの競合と「クリティカルパス」を作成する依存関係を特定し、通常はいくつかのQAも行いました。彼らはまた、POを持つ電話で最も多くのものでした。これにより、コーディングチームは、ヘッズダウンコーディングという最善を尽くすことができました。
進捗状況を追跡するバーンダウンとは対照的に、タイムシートの考え方は奇妙に思えます。契約は時間と材料について交渉されたようで、ポイントの複雑さに基づく時間の見積もりではなく、時間を求めています。ある程度は問題ありませんが、アジャイルのポイントは、クライアントが1時間ごとではなく1ポイントごとに支払うことを望んでいるということです。ポイントは調整可能な作業単位であり、それが完了すると、プロジェクト全体の一部としてその量の価値があるはずの実際の製品が得られます。
物事が失敗することは明白だとは思いません。
製品所有者に報告する製品所有者エージェント（明らかなWTF）があります：意思決定能力の希薄化を引き起こします
誰かが顧客を代表する必要があると仮定すると（実際の顧客が不在の場合）、これは失敗ではありません。ただし、成功の基準は、実際の顧客のニーズを視覚化することです。
従来のアプローチのマネージャーに似た役割があります-開発マネージャー：コマンドアンドコントロールモデルの明らかな試み
これは通常、従来の技術者が十分に年長ではない（またはプロジェクトマネージャーを行うのに十分であることが知られているが、ほとんどの技術者よりもよく知っている）場合に発生します。（他の方法でない限り）実際の違いは、実際に何をするかに基づいています。
スクラムマスターの役割には、バーンダウンチャートではなく進行状況を追跡するために使用されるタイムシートの収集が含まれます。やる気のある個人でチームを構築するアジャイルの取り組みに有害です。
しかし、これは驚くべきことです。しかし、私はほとんどの伝統的なソフトウェア会社がタイムシートを取り除くことができないと信じています。どうして？しかし、次の観点からプロジェクトを追跡する以外に方法はありません。
物事を成し遂げたり壊したりする基準はほとんどありません。
アジャイルの本当の課題は、それを守るプロセスと正確さではありません。本当の課題は、開発者がプロセスの簡素化を支援するのではなく、開発者が純粋な儀式を開始するときに、開発者が良いことに集中できるようにすることです。
本当の必要性を理解し、それを繰り返し改善していきます。必要なのは、適切な目標を達成するために、すべての人々の明快さ（および透明性）とすべての人々からの個人的なコミットメントを得ることです。
もちろん、知っておくべき 12のコア原則 があります。私のポイントは、これらのコアコンセプトに固執することです。つまり、どのような組織構造でもアジャイルな作業を行うことができます。
この基本的なことが失敗すると、すべてが失敗します。それ以外の場合はすべて問題ありません。