アジャイルの裏側-他の人の間違いを解析する

「愚か者は彼の過ちから学び、見知らぬ人から賢く。」

すべての良い一日。 この記事では、発生したエラーを解析し、トピック「 アジャイルの裏側」で詳しく説明します。 これは決して聖戦というわけではなく、非難することはほとんどありません。 私はこれらの質問を研究の側面から分析し、SCRUMの良い名前を部分的に復元することにのみ興味があります。

質問と回答。 すべてが短い。

状況の分析と適切な解決策の探求に移る前に、ほとんどすべての状況でそれが見つかり、さらに適用される可能性があると信じています（時には多くの苦痛を通して）、読者から生じるかもしれないいくつかの質問に答えたいと思います。

1. 誰がSCRUMについて話し、エラーを分析しますか？ -私は、SCRUMマスタープログラムSCRUM.org'aの認定を受けています。 今、PSMレベルIです。はい、最近証明書を受け取りましたが、この方法論（フレームワーク;））を実践し、準備してきました。

   
   
2. 一体何を忘れてるの？ -私には自分勝手な目標があります：現在、PSMレベルII認定の準備をしています。第2レベルを確認するために、SCRUMガイドを参照して、ケースを分解し、正しい答えをクリックしてください。 したがって、このようなケースは黄金の倉庫です（誰かが興味を持っている場合は、ケースを送ってください、私はそれらを分析しようとします、または助けを求めて泣き、彼女を探しに行きます）。

したがって、すべての質問を整理したら、始めましょう。

患者を紹介します。

ある時点で、会社の経営陣は、ロシア向けの新しい形式の開発手法を試すことを決定しました。 アジャイル（スクラム）が選択され、スクラムマスターが会社に雇われ、すべての開発がTargetProcessに移されました。 管理の観点から、これは開発の速度と品質を改善し、開発者が何に時間を費やしているかを理解するために行われました。

• SCRUMマスター（以下、SMと呼びます）を雇用することは、論理的で適切なステップです。なぜなら、しばしば特定の理解に基づいてSCRUMを準備しようとする試みがあるからです。 この分野の人の経験があったことを願っています、なぜなら SCRUMを最初から実行するのは簡単な作業ではありませんが、元の記事のさらなる内容から判断すると、私はそれを強く疑います。 しかし、今のところは、彼の能力を問題のままにしておきましょう。

  
  
• 管理ウィッシュリストに触れましょう。スピードと品質の改善は良いことです。開発者が時間を費やすのは過去のものであり、SCRUMではありません。 これは定期的なタイムトラッキングであり、SCRUMガイドには記載されておらず、KonBan、Waterfall、またはその他のRUPであるかどうかに関係なく、どの方法にも使用できます。

もちろん、時代は変化していることを私は完全に理解しており、おそらく以前は、プロジェクトの開発は少し創造的だったでしょう。 現在、これは合理化されたビジネスプロセスであり、その目的はお金を稼ぐことです。 しかし、このプロセスは神格化され、創造性への渇望とプロジェクト開発への関心を抑えることができます。

• SCRUM'aの課題-創造性、関心、そして良い雰囲気を維持すること。 主なニュアンスは、それを正しく適用する方法を学ぶことであり、基本的なルールを変更しないことです。 適切に機能するメカニズムで、サイズまたは機能が適切でない1つのパーツを完全に別のパーツと交換すると、メカニズム全体から大きなものは得られません。

最初は、新しいスクラムの導入後、誰もがその論理と外部のシンプルさに喜びました。 すべてが明確であり、開発プロセスをスプリントに分割し、ユーザーストーリーマネージャー（タスクの処理）を取得し、特定のスプリントにそれらを含めます。

• ここに最初の重大な間違いがあります-マネージャーからユーザーストーリーを取得します。 元のトピックで読んだすべてのテキストから、製品所有者の役割（ROはどこでも）に関する言及は見つかりませんでした。 ROとは誰か-最終ビジョン、プロジェクトの開発、プロジェクトのバックログの管理を担当する人、彼にはまだ多くの責任がありますが、これまでのところ、これらに限定します。 つまり POは、オフィスのオープンスペースに住む管理者の群れからの最初の抑止障壁です。 だから、見た目と動作するはずです。

チームには、すべての関係者からのすべてのウィッシュリスト/ビジョン\フィードバックを集計し、このリストを処理してチームに持ち込むROがあります。クリロフのthat話で：

仲間に同意がない場合、
彼らはうまくいきません。
そして、それは小麦粉だけから出てきません。

• 次の警告は、評価の事実の欠如です。 記事の著者が示すことを忘れているか、そうではないかもしれませんが、チームは特定のユーザーストーリーの評価を行う必要があります。 評価が開発チームではなく他の誰か（DTのどこでも）によって行われた場合、これは痛み/悲しみになり、一般的にはこれを行うべきではありません。 仮定は尊重されなければならず、誰がタスクを実行し、彼は評価を与えます。 マネージャーVasyaではなく、DT全体。

経営陣は、実装中にタスクを変換し始めました。もちろんコストもかかりました。 ここでは、いつものように、すぐに経営陣と開発者の間で誤解がありました。 Symfony 2.6からSymfony 3.0にプロジェクトを移行するには、あるバージョンから別のバージョンへの単なるアップグレードであるため、開発者にとってほぼ1週間かかります。 おそらく、ビジネスの観点から見ると、開発部門は、開発コストを削減し、スピードを上げるために、3倍、または5倍速く働くことができれば、常に怠laな従業員のように見えます。

• その瞬間、SMはゲームに参加し、マネージャーの不法行為から開発者（DT） を保護するために、 すべてのマネージャーを徒歩でエロティックな旅に送ることになっていた。 経営者の要望は理解可能であり、適用可能です。評価、測定、お金の節約（すべてのマネージャーがこれを行っているわけではなく、回避することはできません）。 しかし、この場合、SMは問題に介入し、一撃をかけ、チームが何をしていたのか、何をしていたのか、なぜ触れてはいけないのかを全員に説明しなければなりませんでした。 まあ、特に熱心なマネージャーがDTの部屋に忍び込んだら、怒ったぼろきれで彼を運転してください。 はい、私は異議を予見します：「これらのマネージャーは、ぼろきれは言うまでもなく、彼らに対して言葉を言うでしょうか？」、しかし、すべては非常に簡単です、SMはチームに触れないTOP \ MegATOPおよび他の大きなマネージャーと事前に同意しなければなりませんそしてそれを通して働きます。 実際、これはSM'aの責任の1つです。組織にSCRUMを実装し、それを正しく実装することであり、失敗ではありません。 すぐに、すべてから判断すると、SMは問題を排除し、戦車に大胆不敵な座りをしましたか？

しかし、開発者の観点から見ると、わずかに異なる状況が現れました。開発者は仕事を奪われず、それぞれ3つまたは5つのプロジェクトに同時に取り組みました。管理者からのプレッシャーと労働時間ごとの報告があったためです。 「なぜこれを開発したりテストしたりするのに丸一日費やしたのか」という精神から疑問が生じ始めました。

• 1つのDT-1つのPO、できれば1つのプロジェクト（または1つの製品バックログ）、またはプロセスを真剣に変更し、方法論を純粋なSCRUMからかんばんに変更する必要があります（またはSCRUMBanを作成するためのより良いミックスでさえありますが、問題ありません）興味深いことに、その方法と実装方法に加えて、さまざまなチェルヌカを紹介します ）。 つまり 多くのプロジェクトから多くのリクエストが寄せられている場合、すでにサポートが盛んになっているため、SCRUMを離れることをお勧めします。 さらに、SMはどこにいたのですか（ahhhh？）、なぜDTを保護しなかったのですか？ 彼は正確にスクラムを知っていましたか？ 実装する準備はできましたか？ 経験はありましたか？ この段落に対して、私はこれらの質問に対する肯定的な答えをもう少し完全に疑います。

マネージャーからのタスク（ユーザーストーリー）のみが実行され始め、開発者には目立たないが有益なアクティビティの時間はありませんでした。

• POがなく、SCRUMが誤って実装されていたため、ひどい痛みがありました。 Project \ Product Backlogの管理を担当するPO（！）が1つあり、過激なマネージャーの群れではない場合、すべてがよりシンプルになります（はい、マネージャーと議論し、彼らに愛されなくてはなりませんが、どうすればよいでしょうか？彼はいくつかの現実のものを持っています。そうすれば、誰もがそれに慣れて和解するでしょう。）

プロダクションのどこかでバグが見つかった場合、開発者はそれを修復できませんでした。 そこで時間を帳消しにするのにタスクが必要です。 そして、開発者自身が自分のタスクであふれていました。 タスクの優先順位付けが開始されました。 マネージャーは、自分たちのuserStoryに最高の優先順位を割り当てようとして、お互いに対立し始めました。 彼らには顧客に対する義務があり、誰も忙しい開発者を気にしません。

• POがなく、SMが嫌いな人であり、これが主な問題であると言う場合、繰り返します。 実際、バックログアイテム（この場合、ユーザーストーリー）は必要なアーティファクトです。誰かがこれは形式主義へ​​のオマージュであると言うでしょうが、ここでは反対します-いいえ。 これは、実行する必要があるものの最終結果の説明、理解、およびビジョンです。 そして、DTのVasya \ Petya \ Cthulhu-誰もが行う必要があることを理解し、これをPOとSMに説明できるような方法で組み立てられるべきです。 彼らがすでに知っているのに、なぜ彼らに説明しますか？ 次に、DTメンバーが正しく理解し、誤解がないことを確認します。 推奨事項によると、すべてがシンプルで、POとSM'aをDTの最前線に配置して、すべてのうんちが飛び込んでくるようにし、DTを世界から切り離して、紅茶/コーヒー/クッキー/遊女に合わせます。

開発プロセスをコンベヤーに変えるスクラム方法論は、主にチームの人間関係を考慮せず、会社の一部のことは従業員の熱意のためにしかできないという事実を考慮せず、UserStoryにラップすることはできません。

• フレームワーク、仲間 方法論ではなく、一度もありません。 それは、人間関係がSCRUM'aの主要な目標の1つであり、これらの関係に基づいていることを考慮に入れています。 なぜ私はそう決めたのですか？しかし、ここに理由があります（SCRUMガイドから破れました）：
  

  コミットメント、勇気、集中力、オープン性、尊敬の価値がスクラムチームによって具現化され、実践されると、透明性、検査、適応のスクラムの柱が生き返り、すべての人に信頼を築きます。 スクラムチームのメンバーは、スクラムイベント、ロール、およびアーティファクトと連携しながら、これらの価値を学び、調査します。 スクラムの使用を成功させるには、これらの5つの価値観をよりよく習得することが重要です。 人々は個人的にスクラムチームの目標を達成することを約束します。 スクラムチームのメンバーには、正しいことを行い、困難な問題に取り組む勇気があります。 誰もがスプリントの仕事とスクラムチームの目標に集中しています。 スクラムチームとその利害関係者は、すべての作業とその作業を実行する際の課題についてオープンであることに同意します。 スクラムチームのメンバーは、お互いを尊重し、能力のある、独立した人々である
  

SCRUMによると、人々は基盤です。 ただし、ここで私が称賛しているのは、人々はあらゆるマネージャーやあらゆるプロセス、アプローチ、方法論の基盤であるということです。 頭脳がない場合、管理者が坐骨神経痛を考える場合、すべては悪いです。

親愛なるKeks650 、私はあなたの記事を補足しようとすることさえできます、私はあなたがチーム全体とプロセス全体に大きく影響した1つの重大な要因に言及するのを忘れたと思います。 たぶん私は間違っているかもしれませんが、私の直観から言うと、そこにあるべき場所がありました-ユーザーストーリーの評価はコミットメントと見なされ、開発者は耳を貸していました。 推測？

• これは何らかの形で少しのコミットメントまたは予測であると思われます。 切り株の違いは何ですか？ そして、違いは本当に大きいです。 SCRUMガイドには、期限へのコミットメントなどはありません。 タスクが誤って/誤って評価された場合、またはすべての要因が考慮されていない場合、これはDTとPOの間の交渉の対象となりますが、「死ぬが、やる」ことはありません。 実際、予測の概念があります。注意を払うと、SCRUMガイドは推定の方法と測定単位を説明しません。 これらのすべての時計、ポーカー、および他のサイズのパンツは、「ルートを奪った」ローカルエクステンションとして登場しました。 しかし、最初の詐欺ではそうではありません。 したがって、予測が失敗した場合、Retroのフレームワークで、DTは、これが再び発生しないように、その理由と修正方法を検討する必要があります。 また、SCRUMが正常に実装されていれば、これに問題はありません。

死後のエピクライシス。

患者は救われていないと思うので、要約しましょう。
原則として、エラーの修正はすべて記事に記載されていますが、以下に簡単な要約をまとめます。

1. ROおよびSMは、それぞれの責任に従ってプロセスに関与する必要があります。
2. ROは利害関係者と直接連携する必要があります。 DTは、プロジェクトのバックログに従ってROのビジョンのみを満たし、質問の明確化とレビューのフレームワークでのフィードバックの受け取りを除き、マネージャーとはまったく通信しないようにします。
3. SMはショーのためではなく、ファッショナブル/若者であるためではなく、生地のためではなく、プロセスをセットアップするためです。 有能なSMがなければ、プロセス全体が無駄になります。 特に、この状況では、彼はRO役割の作成を開始し、バックログ、DT、および外部マネージャーとの連携方法を彼に教えなければなりませんでした。 また、最初のカップルでは、​​彼が混乱せず、マネージャーが彼に過度の影響を及ぼさないように注意してください。
   次に、チームと協力して、チームからフィードバックを受け取り、チームを妨げるものを排除します。それが部屋のドラフトであろうと、特に面倒で熱心なマネージャーであろうと。
4. ROには、優先順位の明確な定義とともに、十分に開発され、優先順位付けされたプロジェクトバックログが必要です。次の人が来て、彼がそれを必要とするので、非常に高い優先順位を導入しました。

エピローグ

なぜ私はこの記事に反応し、時には論理的なナレーションのスレッドを失い、推論に陥ったのか-SCRUMがしばしば誤解されているために火傷を負ったからだろう。 結果として、「％username％、あなたはSCRUMを知っています-たわごと、ジューサー、ファシズム。私たちはそれを紹介しません。」と言う人につながるでしょう。 その結果、誰もが何かを失います。
最初のトピックでは、プロセス自体の編成における大きな問題が明確に表示されており、\ put \ substitute_to_optionsを獲得しました。 スクラムはそれとは何の関係もありません。 適切なアプローチで、彼はただのビーズであり、一般的に

これは、最初からSCRUMを実行し、SCRUMを変更し、かんばんと混合し、固定価格（！）プロジェクトで正常に使用した人の完全な自信を持って述べることができます。
はい、それへの移行は積極的であり、革新は常に、おそらく、予想外で病気ですが、適切に提示されれば、非常にうまく機能します。

PS-私はSCRUMがすべての万能薬だとは言いません。 歌うアサナの種類に関係なく適用できないこともありますが、この適用不可能性はさまざまな要因、つまり予算、制限、異なるプロセスを使用する必要性にあります。 しかし、その適用不能性は、曲がった手に起因するものではありません。 曲がった手は曲がった手であり、SCRUMだけでなくすべてを追放できます。

私の推論のほとんどは、 SCRUMガイドと交差しています。 慎重に勉強し、このドキュメントを積極的に使用することを強くお勧めします。