アジャイルは新しいマイクロマネジメントですか？

この質問はしばらく私の頭の中で調理されてきたので、開発環境でアジャイル/スクラムのプラクティスに従っている人に尋ねたいと思いました。

私の会社はついにアジャイルプラクティスを取り入れることに挑戦し、トライアルベースでアジャイルグループの4人の開発者のチームから始めました。3回の反復で4か月が経過しましたが、他の人にとっては完全にアジャイルになることなく、それを続けています。これは、経営者がビジネス要件を満たすための信頼が、上記の非常に多くのアドホックタイプの要求であるという事実によるものです。

最近、私はこのイニシアチブの一部である開発者と話をしました。面白くないと言われます。彼らは彼らのスクラムマスターによって他の開発者と話すことを許可されておらず、作業エリアで電話を取ることも許可されていません（ある程度は問題ないかもしれません）。たとえば、アジャイルチームに所属するキックについて友人と話したい場合、スクラムマスターの承認なしでは許可されません。アジャイルチームのすぐ隣に座っています。

このすべてまたはアジャイルのアイデアは、アジャイル開発者に中断が生じないように完全な真空を提供し、6時間以上の生産時間を確保することです。まあ、私はアジャイルの第一人者ではありませんが、ヤフーのアジャイルロールアウトドキュメントや他の組織の同様の記事を読んだことから、アジャイルは安くないという印象を与えます。チームにアジャイルを浸透させ、到着した問題を修正して軌道に戻すには、リソースと予算が必要です。

まず、開発者向けのトレーニングとマネージャーなどのコーチングが必要です。現在のスクラムマスターは、管理者が支払うアジャイルトレーニングクラスを数日間受けたマネージャーで、現在このアジャイルチームを率いています。また、アジャイルマニフェストはアジャイルが石に設定されておらず、会社ごとにカスタマイズされていることを指示しないと会議で聞いたことがあります。まあ、それはすべて良いと理にかなっています。

結論として、私はアジャイルが開発チームに調和をもたらすはずだと常に思っていました。ただし、アジャイルチームの開発者と話をするとき、私は非常に反対の気持ちになります。彼らは仕事以外は何も話せないのに不満であり、一日中静かに座って仕事をしているだけであり、経営者が仕事をより良くするための別の方法だと感じています。

これがより多くのドルのために利己的な優位性の目的のために使用される良い習慣の例であるならば、私に教えてください？あるいは、私のような開発者だけがこのアジャイルチームであり、仕事をしているために仕事をするだけの環境で働くのは好きではないと感じています。

これは、全米にオフィスを持つヘルスケア分野の会社です。それは間違いなくカウボーイスタイルのアジャイルのように感じられるので、現在の会社では特に、アジャイルをまったく望んでいません。

それはすべて、管理が完全に安価であることと関係しています。安価なバージョンのために高価なコーヒーを切り取り、可能な限り無駄を省きながら、節約と生産性を重視します。

私は、ドアの後ろの経営陣がこのアイデアを捨て、アジャイルにより生産性が向上し、同じ人員でより多く生産している上司に見せることができると感じています。または、もしそうであれば、人員を減らすことができます。

彼らは毎日5分間の会議を開いています。ただし、チーム外の人とチャットや会話をすることはできません。すべての焦点は仕事にあります。

アジャイルではなく、経営独裁を説明しています。アジャイルは、要件を変更する分野での漸進的な開発に関するものであり、人々が個々に作業を行う方法を指示することではありません。

スクラムマスターは他の開発者と話すことはできず、作業エリアで電話を取ることもできません。

これは実際にはアジャイルプラクティスの一部ではなく、別の問題です。

アジャイル手法の大きな動機は、開発者間のコミュニケーションの増加です。開発者<->開発者のコ​​ミュニケーションを制限することは、アジャイルプラクティスとは別の問題です。私はこれが起こっていないと言っているわけではありません-それは明らかに、あなたの組織の「アジャイル」ロールアウトの一部としてラベル付けされていますが、これはアジャイルとは別の問題ですIMO）。

それは、アジャイルのかなりひねくれた実装のように聞こえます。アジャイルは、もしあれば、マイクロ管理を増やすべきではなく、減らすべきです。チームはコミットメントを行い、プロセスの一部は、経営陣がチームがそれを達成することを信頼することです。毎日のスクラムは、開発者が互いに通信する方法であり、時間をどのように過ごしたかではなく、自分が何をしたかを通知する方法です（これは私がいくつかの場所で見た間違いです）。推定プロセスでさえ、推定から明示的な時間管理を削除する必要があります。これは、ストーリーにかかる時間ではなく、相対的な複雑さを推定する必要があるためです（別のよくある間違い）。開発者が費やす時間を制御することはマイクロ管理の特徴であり、プロセスから時間を取り除くことはアジャイルの中核となる理念の1つです。

あなたが記述する環境は、園芸品種の擬似アジャイルでたらめのように聞こえます。

アジャイルになる前にアジャイルに関与しました。2000年ごろ私はコーディングで燃え尽きていましたが、Extreme Programmingについて聞いて、試してみて、気に入りました。開発者として、堅実なソフトウェアを作成することが最も重要であるというコンテキストを与えてくれました。私はそれが好きだった。

私が他の場所で詳細に説明している今日の問題は、最近「アジャイルを採用している」人々のほとんどが、それが不快になれば何も改善することに興味がないということです。したがって、彼らにとって、「アジャイル」は開発者を同じ古い方法で打ち負かすための新しい棒にすぎません。たとえば、開発を遅らせているでたらめをすべて排除しながら、生産性を根本的に高める方法とは対照的です。

たった今。私は会社を始めたばかりで、多くのXPに加えて、アジャイルの世界で習得した他の多くのトリックを使用します。しかし、まさにあなたのような話のために、私は最近アジャイルの採用について聞いたときはいつもひるむ。

あなたの質問に直接答えるために：アジャイルは新しいマイクロマネジメントであってはなりません。それは、実際の仕事をしている人々がたわごとを成し遂げるために力を与えることであるべきです。しかし、あなたの場合、アジャイルは彼らが自分の悪い本能にふける間あなたに言っている最新の嘘のように聞こえます。本当にごめんなさい。

これは機敏ではありません。

まず、スクラムはアジャイルではありません。率直に言って、スクラムはでたらめです。私はエクストリームプログラミングの家で育ちました（文字通り-ケントベックを父のソファに座らせて、テストについて話してくれました）、スクラムはそうではないことをすぐに伝えることができます。スクラムはプロジェクト管理ツールであり、開発プロジェクトの定義されたリズムです。しかし、開発自体については何も言うことはなく、要件、計画、顧客との関係についてはほとんど言うことはありません。XPは、これらすべてについて多くのことを述べています。アジャイルと呼ばれる他の方法論には、会話に追加するものが必要です。スクラムの支持者は、それをプロセスとしてではなく、プロセスのラッパーとして説明しています。賢い男は、ラッパーは良いものを手に入れるためにあなたが取り外して捨てるものだと指摘したことがあります。

さて、スクラム暴言！

第二に、アジャイルプロセスの基本であると信じているXPの基礎原則は、それが開発者に集中しているということです。これは、開発者が行う必要のある仕事を行う力を開発者に与える方法であり、頻繁にやめられます。アジャイルチームは、民主主義または独裁として構成されている場合がありますが、リーダーは開発者です。プロジェクトマネージャーなどの役割-重要な役割-がありますが、それはチームのリーダーシップではありません。「スクラムマスター」と呼ばれるマネージャーがいることは、周りに人をボスしていることは、チームがアジャイルを行っていないことの確かな兆候です。

第三にあるべきだと思う。ありません。

スクラムはアジャイルのろくでなしの子です。すべてのアジャイル方法論の中で最もウォーターフォール型であり、それがマネージャーの間で最も人気がある理由です。

すべてのアジャイルメソッドは、邪魔にならずに作業コードを生成することです。もう一度読んでください。そしてまた。

「アジャイルルール」に関係なく、その目標を邪魔するものはすべて悪いです。ルールが邪魔になる場合は、f * *ルールを変更してください！それがアジャイルな方法であり、それが関連性と効果をもたらすものです。

これの最良の例は、Alistair Cockburn（アジャイルマニフェストの創始者の一人）によって与えられます：

「ワークステーションとホワイトボードのある部屋に4〜6人を置き、ユーザーにアクセスします。実行中のテスト済みのソフトウェアを1〜2か月ごとにユーザーに配信し、それ以外の場合はそのままにしておきます。

それがあなたが持っている人の質のために働くなら、それはあなたが必要とするすべてです。スクラムマスターや「アジャイル」方法論は必要ありません。毎日のスクラムに座って作業できる場合は、f * * *を実行します。自分を立たせることは、自分自身で考える能力の哀れな廃止に過ぎません。

あなたがしている種類のアジャイルへの反応があります。そのこれ。印刷して、誰もいないときにどこかに固定し、自分で発見できるようにします。

現在のスクラムマスターは、管理者が支払った数日間のアジャイルトレーニングクラスを受けたマネージャーで、現在このアジャイルチームをリードしています。

それはあなたの問題だ。経営陣はアジャイルを望んでおり、それが何であるかを本当に知らず、チームにそれを課しています。これは、開発者の生産性を大幅に低下させたい場合にやるべきことです;）

新しいプロセスの提案は開発者から提供される必要があります。または、少なくとも経営陣の考えであれば、レビューと承認を受けます。

いずれにせよ、開発者が拒否した場合、実装しないでください！または、あなたが説明する災害になります。

「アジャイル」と他のすべての「管理方法」は、人々にミクロ管理を強制するために頻繁に悪用されます。OTOH貧弱な仕上がりを守るために乱用されることもあります。

「私たちはアジャイル」は、計画の欠如、設計、機能、品質、リリースサイクルについての思考の欠如について私が耳にする最も頻繁な言い訳です。これは通常、開発者と管理職からのものです。これは、中間管理職、建築家、営業担当者などから、頻繁に使用される締め切りや機能リストの変更、締め切りや機能リストの大幅な変更、人員へのより大きな残業の強制（もちろん、期限や機能リストの変更によって確実に行われる）などのために、最も頻繁に使用される言い訳でもあります。

もちろん、この2つはしばしば直接矛盾しており、同じプロジェクトで発生する可能性があります。

あなたの元の質問に答えるために、アジャイルは新しいマイクロ管理です、私はノーと言います。

まず、これ（アジャイルマニフェスト）を読んでください。共同開発者と話さないことはリストされていません。

実際、「個人と相互作用」は、共同開発者と話をしないことの正反対です。

アジャイルは新しい自己管理でなければなりません。 アジャイルが正しく実践されている場合、多くの決定は、タスクが特定されるとバックログに追加される合理的に範囲を定めたユーザーストーリーを作成する顧客と開発者によって行われます。

毎日のスクラムは、管理ではなくコミュニケーションに関するものです。 優先度と負荷分散についていくつかの議論がありますが、スクラムで管理されている人がスクラムマスターであることを願っています。開発者として、私は出席し、私がしたこと、私がやろうとしていること、そして私が必要とする支援を言います。その後、スクラムマスターは行動に移り、私の進歩の障害をクリアする必要があります。

アジャイルチームは、日々の作業が階層的に管理されていると感じてはなりません。 階層組織のトップにいる誰かが遠くから意思決定を行う場合、意思決定の分散化の時が来ました！一部の人々や一部の組織にとって、これはあまりにも大きな橋渡しになるかもしれません。以下が組織に当てはまらない場合：

アジャイルマニフェストを生きる

「ソフトウェアを開発し、他の人がそれを実行できるようにすることで、ソフトウェアを開発するより良い方法を発見しています。

「新しいボスに会う、古いボスと同じ」を避けてください。 可能な限りチーム内からアジャイルを発信します。これは、アジャイルを使用したトライアルプロジェクトに参加する意欲のある連合を選ぶことで起こることがあります。優れたチームワークの実績があるボランティアまたは招待されたメンバーからアジャイルチームを形成できる場合、彼らはそれを解決できます。社内または非常にアクセスしやすい顧客向けに、短いプロジェクトで小さなチームを使用します。

変更を受け入れます。おそらくあなたはいくらかの訓練を受けることができますが、多分あなたの予算はきつくてお金はそこにありません。他の機会も改善を提供できます。読んで、チームのメンバーにアジャイルについてできることを学んでもらい、お互いに教えます。アジャイルの採用をモデル化し、リードする資格のある新規または既存のスタッフを見つけることができるかもしれません。

アジャイルチームは、一般に理解されている目標に向かって取り組むサッカーチームのようなものです。私は数年前からアジャイルチームの一員であり、キーはすべての利害関係者間での効果的かつ効率的なコミュニケーションです。マネージャー/スクラムマスターはチームの単なるファシリテーターであり、従来の管理/マイクロ管理はチームの精神を殺します。

私が働いたチームでは、メンバーの仲間意識を高めるために、勤務時間後にチームゲームをプレイすることをお勧めします。ここでそれらの考えを集めました。

あなたの質問に答えるには：いいえ。アジャイルはマイクロマネジメントの一種ではありません。しかし、他のツールと同様、人々はそれを誤って使用する可能性があります。アジャイルは、適切に実装され、人々がそれと一貫していれば素晴らしいものです。

「開発者がスクラムマスター以外に話をしていない」トピックに関する私の考え：

以前はそれがルールだった場所で働いていました。ただし、このルールは、タスクを完了するように人々に依頼することにより関連していました。たとえば、開発者テスターに​​ランダムにアクセスして、今後数時間以内にテストを依頼することはできません。緊急の場合（または将来のスプリントのためにバックログにプッシュする必要がある場合）、その作業がスプリントにどのように適合するかをチームメンバーと話し合うことができるように、スクラムマスターと話す必要があります。

その場合、特定の開発者が過労にならないように、または特定の開発者が計画を立てられないほどの緊急タスクを実行するのに忙しいので、「開発者が互いに話していない」という概念を理解しました。完了しました。

それ以外の場合、開発者は互いに話し合う必要があります。常に。問題をより迅速に処理し、チームとしてより近くなり、より迅速に提供するのに役立ちます。

別の視点を提供するためだけに、私は開発者が「話しすぎた」と人々が考える環境にもいました。座った後、実際には「開発者は自分の仕事を遂行するのに十分独立していません。すべてが非常に断片化されているため、開発者は小さなタスクを完了するために他の3人に行く必要があります」とわかりました。

そのため、マネージャーがアジャイルに移行することを決定したとき、彼らは情報を適切な場所にもたらし、組織内の断片化の多くを阻止することを期待していました。一部の人々は、アジャイルが実装された後、開発者がまだお互いに行き来していることに失望しました。しかし、彼らが気付いていなかったのは、それがますます少なくなっているということです。でも時間がかかりました。それで、もしそれがあなたの組織で起こっているのであれば、人々は一晩で物事を修正するアジャイルを期待しているかもしれません。それはちょうどそれが動作する方法ではありません。

原作者のスミス・ジェーンズは経験を与えたかもしれません。しかし、これらはアジャイルプロジェクトで見つけた典型的な問題です。

1. ほとんどの組織、開発者はアジャイル/スクラムの複数のプロジェクトで作業することになっています。スプリントは決してこの事実とは見なされません。スクラムマスターは、スプリントの終わりにストーリーを完成させるべきだと想定します。スクラムマスターは、開発者ではなく、1つのプロジェクトのみに専念する場合があります。これは、ディストラクションです。または電話を許可します。
2. Sprintが計画されているアジャイルプロジェクトを見ましたが、ストーリーはSprintに組み込まれていますが、スプリントの途中または途中ではありません。開発者が依存関係を解決できず、要件やストーリーがナレーションされていないことがわかりました.....ほとんどのアジャイルプロジェクトで悪用されています。
3. テスト：TTD ..はい、非常に良い..しかし、ほとんどのアジャイルプロジェクトがTTDに完全に依存しているのを見ました...機能テストまたは人的テストに許可された範囲も時間もありません。機能テストの重要性を知らない、または理解しない。あなたのコードは、ビジネスのニーズを満たしていない場合、完璧に機能しているかもしれません..それは役に立たない..これは、ビジネスが先に十分に参加していない場合、または参加している場合に発生します... ..最後に、開発者は非難されます、あなたは機能を提供しませんでした。または、それは最後の最後の変更で終わるでしょう...あなたのスクラムマスターが完了していない物語のせいにしたくないので余分な長い時間

ここでの虐待...ビジネスへの参加率が低いか、完全に知識のない参加者か、スプリントの途中で中退したビジネスマン。

1. すべてのプロジェクトがアジャイルに適しているわけではありません...ほとんどのマネージャーやスクラムマスターはこれを知りません。.メンテナンスプロジェクト..最初は欠陥がスプリントで受け入れられ、8時間以内に行われると想定されるかもしれません。4時間を費やした後、これはJava /別の製品であることがわかりました...（最近、プロジェクト内でQuartz Schedulerに関連する欠陥に対処しました）この欠陥は、製品/パッケージのアップグレードにつながる可能性があります。資金調達、新しいバージョン、またはアップグレードは、内部エンジニアリングなどによって承認される必要があります。5.再検討：ほんの一握りのアジャイルプロジェクトのみがこのステップを実行します。
2. ペアリング..多くの開発者は、ペアリングを同僚を悪用する場として扱います。他の設計、コーディング慣行を批判します。評価者はチームワークとして扱い、お互いから学びます。

アジャイルは間違いなく優れた方法論です。組織が完全に従わないか、訓練されていない場合を除きます。...それは虐待されます。

アジャイルは変装したマイクロマネジメントです。アジャイルにはイニシアチブや創造性のための場所はありません。それはプログラミングから楽しさを取り除き、技術の観点から手がかりがなくても、無能なマネージャーがコントロールを維持できるようにします。