最初から最後まで個人的に大きなチャンクを独自に所有したい開発者にアジャイルを楽しいものにする方法

スクラムを使用した滝からアジャイルへの移行のほぼ中間です。テクノロジー/規律サイロの大規模なチームから、部門を超えた小規模なチームに変更しました。

予想どおり、アジャイルへの変更はすべての人に適しているわけではありません。アジャイルに慣れるのに苦労している開発者は少数です。私は本当に彼らを引き付け、挑戦し続け、最終的には毎日仕事に来ることを楽しみたいです。これらは賢く、幸せで、やる気のある人であり、私は個人的レベルと職業的レベルの両方で尊敬しています。

基本的な問題は次のとおりです。一部の開発者は、主に難しい作業をし、設計を熟考し、潜在的な問題を熟考し、次に他の人との最小限の相互作用のみで問題を部分的に解決する喜びに動機付けられます期間。彼らは通常、高品質のタイムリーな方法で作業を完了します。それらの作業は保守可能であり、アーキテクチャ全体に適合しています。作業に対する相互作用と共有責任を重視する職域を超えたチームに移行し、短い間隔で作業機能を提供することで、チーム全体がその困難な問題を克服するように進化します。多くの人がこれを前向きな変化だと感じています。最初から最後まで問題を抱えて独立してそれを所有するのが好きな人は、そのような仕事の機会を失います。

これは、人々が変化に対して開かれているという問題ではありません。確かに、変化を嫌う少数の人々を見てきましたが、私が懸念しているケースでは、個人は良いパフォーマンスをし、真に変化に対してオープンであり、努力をし、チームの残りの部分がどうであるかを確認します変化し、彼らはそれに適合したいと思う。それは誰かが困難であるか妨害者であるか、または最もジューシーな仕事を買いだめしたいというケースではない。彼らは以前のように仕事に喜びを見いだせません。

これにぶつからない唯一の場所になることはできないと思います。他の人はこれにどのようにアプローチしましたか？あなたが個人的に大きな仕事の塊を端から端まで所有することによって動機付けられている開発者であり、あなたが別の働き方に適応した場合、それはあなたのために何をしましたか？

私は、アジャイルが方法論として本当に意味をなさないという珍しい区別をするのに十分幸運なソフトウェアショップは非常に少ないと言うでしょう。チーム全体が、ビジネスの側面と会社やお互いの寿命を深く理解している真に優れたソフトウェア開発者で構成されており、ビジネス要件とクライアントのニーズが通常常に類似しており、リリースすると、アジャイルがおそらく実際にHURTできるようなまれな環境で作業することができます。

混andとし、絶えず変化するビジネス要件と顧客のニーズ、進化するまたは変化するプロジェクトリソース、厳しいまたは変化する締め切りの中で最も効果的なアプローチになるように設計されています。このような環境は、プロジェクト中のチームの変更に対して脆弱であり、要件の変更に対して脆弱であり、日付の変更に対して非常に脆弱であるため、典型的なウォーターフォール開発に特定の運命をもたらします。

仕事に喜びを感じなくなったあなたの貴重なチームメンバーを感じています。彼らは仕事に夢中になっている非常に才能のある人々かもしれませんが、結局のところ、彼らの最善の制御外の多くの要因がプロジェクトを殺す可能性があります。機能開発に取り組む最善の方法は、個々の態度と表現を失い、チームアプローチの観点から考えることです。

あなたはこれが彼らのために機能しないことがわかった場合、あなたはそれらのための特別な使用を見つけることができます。彼らが非常に才能があり、経験がある場合は、アーキテクチャの役割、高レベルの設計、アプローチのレイアウト、新しいテクノロジーの実験、ベストプラクティスの進化に興味があるかどうかを確認してください。これらの人々に設計文書の管理とレビューを依頼してください。

それでもうまくいかない場合は、別のブランチでの非常に複雑な技術的リファクタリング、非常に複雑なプロトタイプと概念実証、または場合によっては実行する必要があるがうまく適合しないその他の先駆的な作業で別々に作業する必要があります単一のプロジェクトまたはリリースの範囲。

彼らは以前のように仕事に喜びを見いだせません。

正しい。

それはあなたがそれを間違っているという大きな症状です。

アジャイルは、人々に悪い新しい秩序を課すべきではありません。

アジャイルでは、チームが最も効果的な方法で自己組織化できるようにする必要があります。

自己組織化とは、経営陣が奇妙なルールを課さないことを意味します。悪いスケジュールを課すことも、不必要な相互作用を課すこともありません。

一部の開発者は、主に困難な作業を引き受け、設計を熟考し、潜在的な問題を熟考し、その後、長時間にわたって他者との最小限の相互作用のみで問題を解決する喜びに動機付けられます

なぜ彼らはこれを続けることができないのですか？

なぜそれらを変更するのですか？

アジャイル宣言を数回読んでください。

アジャイルマニフェストは言う

プロセスとツールを介した個人と相互作用

人々を不快で非生産的な方法で働かせることはありません。

人々にあまり価値のない「相互作用」を強いるのであれば、行き過ぎです。

包括的なドキュメントよりも機能するソフトウェア。

彼らはこれをやっていますか？次に、それらを放っておきます。

契約交渉に関する顧客コラボレーション。

すでにこれをやっていますか？その後、変更しないでください。

計画に従うことによる変化への対応。

これらの人々がすでに変化に対応できる場所はどこですか？もしそうなら、彼らはすでにアジャイルでした。変更する必要はありませんでした。

私の会社は同じ移行を試みました（そして、長年の試みの後もまだ試みています）。この移行中に、アジャイル開発とさまざまな方法/側面/懸念/技術について多くのことを読みました。私が強く同意することの1つは、純粋なアジャイル開発は、チーム全体が上級の高品質の人々で構成される場合に最適であるということです（または、少なくとも同じレベルのすべての人々）。

前回のリリースでは、「アジャイル」チームに所属していた私たちは、いたるところにスキルレベルのある多くの開発者を抱えており、同じプロジェクトに全員を参加させようとしました。それは災害でした。私たちは仕事よりも話し合いや議論をし、最終的にチームが生み出したものは平均的な仕事でした（平均を取ることについてはPeoplewareまたはMythical Man Monthを読んでください）。設計パターンを忘れ、低結合やコードを小さなクラスとメソッドに分割することを忘れてください。a）すべてのチームメンバーが（少なくともタイムリーに）説明できず、理解できなかったため、およびb）アジャイルであったため、この反復を開始したものは何でも、まったく理解できない他の人次の反復で継続します。個人的に、

私は、C ++テンプレートで何もできなかったり、私たちの生活をもっと楽にしてくれるクールな（しかしやや複雑な）低レベルフレームワークライブラリを書くことができないという事実を絶対に嫌っていました。チームの他の誰もSTLヘッダーファイルを読み取ることができない場合でも、そのようなことをどのように行うことができますが、私たち全員が一度に1つのことを行うことになっています。アジャイルが強調しているように見えるので、プロジェクト全体が機能ごとに強引に機能することになりました。

同時に、私の会社には、一緒に仕事をして、すべてのコードを共有したいと思っている人はほとんどいません。

しかし今、あなたは選択に直面しています。A）高品質のコードを作成する優秀なシニア開発者をすべて自分のチームに入れ、残りを別のチームに入れます。またはB）チームのバランスを取り、良いチームとそうでないチームを配置しようとします。（A）の問題は、あなたのチームの1つが非常にパフォーマンスが低下し、善良な人から優れたスキル/習慣を身につけないことです。（B）では、（純粋なアジャイル環境での）善良な人たちはフラストレーションを感じ、履歴書の作成を開始します。私のものは最新です。

それで、あなたは何をしますか？

これが正しい解決策かどうかはわかりません。約1年ほどでもう一度質問してください。しかし、「純粋なアジャイル」の代わりにチームを結成したが、どの人がより影響力があるかを明確に特定し（設計、コードレビュー...）、その人がそれを理解し、追加の責任に対して報いることを確認したらどうでしょう。チームメンバーが一緒に作業を開始するときに、良い習慣/実践を取り入れている人を特定し、それらをあなたの良い人と同じレベルに高めます。1つまたは2つのリリースを一緒に使用することで、他の人が何を考えているか、どのように機能するかを学ぶことができれば、同じコードで同時に作業できるようになります。しかし、それが起こるまで、あなたが人々をプロジェクトに放り込むだけなら、それはフラストレーションに他なりません（もう一度、私の意見です）。

私の考えのいくつかは、私がソフトウェアで専門的に始めた方法に基づいています。私が生協だったとき、私はメンターだった男と仕事をしました。彼は、コーディング倫理から優れたデザイン、あなたが書いていない数千行のコードを読むことまで、すべてを教えてくれました。当初、私たちは同じレベルには近づきませんでした。アジャイルなチームに配置され、お互いのコードに取り組むことができると言われたら笑えるでしょう。しかし、時間の経過とともに（数年）、私たちは非常によく考え始めました。私は彼のコードを一目で理解でき、彼はこれまでに見たことのないコードをナビゲートすることにまったく問題はなかった（そして驚いた）と何度も言った。これには何年もかかりましたが、一晩で起こったことではありません。過去数年間にアジャイル環境で災害が発生した後、

これは本当に答えではありませんが、私の経験/観察を要約しています。私はこれについて他の人が何を言うかを見たいです。

アジャイルとは何ですか？

それは...ですか：

• ルール設定者が意図したものを達成するために従う必要がある一連のルール

• あなたの特定の長所、要件、制限内で物事を成し遂げるためのベスト推測のアプローチ？

アジャイルが最初であり、常にスクラムルールを順守し、それを正しく行っているかどうかを常に心配している場合は、このリンクが少しあなたを啓発するでしょう。

2番目のことをもっと考えるなら、おめでとうございます-アジャイルを「取得」します。アジャイルの方法論は、物事を成し遂げる方法の提案にすぎません。選択したアジャイルメソッドのいずれかの側面が自分にとって適切でないと感じた場合、その使用をやめる、変更する、または他の方法でアジャイルにする義務がありますそれについて。重要なことは、あなたが何かを達成することであり、人為的な制約によって抑制されていないことです-誰もがこれまでにない完全に文書化されたダイアグラムをPMが煩わせる昔の滝の時代から私たち全員が知っていて愛しているものだけではありません「それがプロセスが行うことを言っている」という理由だけでなく、あなたが使用しているものの制約からも読んでください。毎日のスクラムがその制約のように感じたら、点滅させないでください！ルールがそう言うので盲目的にそれらを持っていることは、古い方法よりも機敏ではありません。

ガロンのコーラとピザ用のハッチだけの部屋に閉じ込められて物事を成し遂げる人がいるなら、その事実を利用してください。ほとんど自己完結型のシステムの一部を提供し、ロックします。完了したら、その作業をシステムの残りの部分と統合する（または、必要に応じて他の誰かにそれを実行させる）必要があります。

アリステア・コックバーンはこれを彼の方法で説明しました。「レベル3の開業医」がいる場合、完全に有効なアジャイルメソッドは次のとおりです。

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

人々が混ざっているので、建設的に一緒に仕事をする方法を考え出す必要があります。つまり、1サイズのすべてに適合するアプローチは、おそらくあまり効率的ではありません。したがって、共通の目標が強調されていることを確認しながら、タスクを分割する必要があります。それらの人をコードに送り込むことは問題ありませんが、彼らは自分のスタッフがチームの残りの仕事の不可欠な部分であり、それを達成できなかったことは彼らが生み出しているものの失敗であることに気付かなければなりません。彼らがそれを理解すると（つまり、彼らは自分が感じていることを何でもすることができず、使い物にならないものを届けることはできません）、あなたの仕事は完了です。

アジャイルはすべての人のためではなく、アジャイルはすべてのプロジェクトのためではありません。同時に、アジャイルは非常に広義の用語であり、スクラムはアジャイルプロセスの実装の1つにすぎません。おそらく、よく知られた手順で標準化されたプロセスをセットアップしようとする最も制約の多い実装と言えます。

考慮すべきもう1つの領域は、アジャイルの目的は何ですか？開発者の作業方法についてアジャイルですか？おそらく-いくつかの方法論は確かにその方向に向かっています。しかし、アジャイル自体は開発以外の領域をカバーしています。アジャイルは、プロセス全体、インタラクションの動作方法、最も重要な機能を備えた動作中の製品を時間通りに配信する方法、リソースを制御する方法、現在のプロジェクトの場所を確認する方法、等

開発プロセスの変更を試みない方法論があります-スクラムはそうではありません。すべてのアジャイル手法は、継続的な改善を重視しています。プロセスのいくつかの非効率的なステップを検出し、それを改善/変更しようとします-それがアジャイルな方法です。他の人気のあるアジャイル手法-Kanbanを確認してください。

あなた/あなたの会社はスクラムを使用することを決定しました。そして、それは一部の人々がスクラムを好まないで去るという事実につながる可能性があります。開発者ごとに個別に対処する必要があります。それぞれについて話をし、彼らが再び仕事を楽しんでくれるような興味を見つけてみるべきです。

彼らはメンターの役割を持つことができ、他の人に教え、反復的に作業するときにコードをリファクタリングしてより良いアーキテクチャにする方法を示すことができます。プロジェクト全体でグローバルアーキテクチャブループリントの使用を形成できます。また、概念実証に取り組み、顧客が要件の実現可能性について考えるために問い合わせを行うときにRFI（情報の要求）に参加することもできます。彼らは、スキルの低い開発者とペアで作業し、複雑なタスクを一緒に行うことができます。彼らの主な価値は、スキルを使用し、他の人が学習できるようにすることです。

スクラムとアジャイルは世界的に確かに何らかの形で個人を抑え、チームに優先順位を付けます-チームは個人ではなくアプリケーションを提供します。このアイデアは、全員が同じスキルセットと経験を持っているチームが決していないという事実に基づいています。

スクラムへの移行が成功する場合、全体的なプロセスが改善され、納期が短縮され、品質が改善され、顧客がより満足することがわかります。彼らは、開発されたアプリケーション自体が彼らよりもはるかに悪いと信じることができますが、それはポイントです-顧客は今まで書かれた最高のコードを望んでいません。顧客は、要件を満たす最小/最安/最速の開発作業コードを求めています。それに対してブルートフォースで十分な場合は、それで十分です。これは高度なスキルを持つ開発者に問題を引き起こす可能性がありますが、アジャイルの失敗ではなく、ビジネスの要求と完璧主義が相反する場所です。

主要な問題のいくつかを取り上げ、優れた開発者に引き渡すと、チーム全体に利益をもたらします。誰もがその後、最新の状態になり、その過程で何かを学ぶことができます。この方法でアプリケーション全体をビルドしないでください。

コードを最小公分母にウォーターダウンしないでください。あなたは経験の浅い人をより良い開発者に追いつきます。

「アジャイル」とは何かについて多くの議論があり、アジャイルプロセスについての個人的な感情、経験、不安がここで共有されていますが、質問に対する実際の答えは実際には見ていません。元の質問は、純粋なアートフォームのレベルで書いたコードを見て、汗と血を注ぎ込み、他の誰かにハッキングされて「破損した」トップ開発者のモチベーションを維持する方法でした。アジャイルであろうとなかろうと、これはある時点で発生することに注意してください。サポートする典型的なハンドオフが存在する代わりに、他の人と同時にコードで作業しているので、より目立つようになります。彼らはそれらの変更が行われているのを見ないでしょう。

ここで鍵となるのは、これらの開発者の責任を拡大し、彼らがより大きな視点に焦点を変更できるようにすることです。ソフトウェアアーキテクト、チームリード、シニアソフトウェアエンジニアなどの新しいタイトルを意味するのかもしれません。次に、これは一度に1つのプロジェクトだけでなく、複数のプロジェクトに大きな影響を与える機会であることを示します。所有権の感覚はまだそこにありますが、彼らの焦点はもはや単一の素晴らしいプロジェクトを提供することではなく、すべての基準を設定するのを助けることにあるべきですプロジェクト。すばらしいものを作りたいという強い願望に彼らがキーインするのを助けてください。しかし、あなたの会社のソフトウェアエンジニアリングプラクティスと他の開発者を構築することに焦点を移してください。同僚がコードを細かくハッキングするという考えにうんざりするのではなく、これは彼らが次のレベルにステップアップし、チームメイトをメンターし、彼らをレベルに引き上げるチャンスです。

私は、他の回答では対処されていないいくつかの側面を説明しようとしますが、IMOは重要です。

基本的な問題は次のとおりです。一部の開発者は、主に難しい作業をして、設計を考え、潜在的な問題を考え、次に問題を部分的に解決し、他の人との最小限の相互作用のみで、期間。彼らは通常、高品質のタイムリーな方法で作業を完了します。それらの作業は保守可能であり、全体的なアーキテクチャに適合しています。

この種の開発者は、アジャイルな環境に適応するのが難しいと感じるかもしれず、彼らの態度は、しばしばエゴや昔ながらのことに関連する「変化への不本意」として却下されます。

しばしば無視されるのは、複雑な問題を解決するために多くの情報を処理する必要があり、これには多くの分析、思考、試行、ソリューションのスケッチ、破棄、別の試行が必要になる場合があることです。このような複雑な問題には、完成したソリューションが得られるまで数時間から数週間の集中的な作業が必要になる場合があります。

1つのアプローチは、開発者が問題の仕様を取得して自分の部屋に行き、2/3週間後にソリューションを取り戻すことです。開発者はいつでも（必要な場合）、チームの他のメンバーまたは利害関係者（特定の問題に関する質問をする）とのやり取りを開始できますが、ほとんどの作業はタスクを割り当てられた開発者が行います。

アジャイルシナリオでは何が起こりますか？チームは、迅速な分析（グルーミング）の後、問題を小さなチャンク（ユーザーストーリー）に分割します。ユーザーストーリーは互いに独立していることが望まれますが、多くの場合はそうではありません。複雑な問題を本当に独立したチャンクに分割するには、通常、数日間作業した後に得られる知識が必要になります。言い換えると、複雑な問題を小さな独立した部分に分割できる場合、それは基本的にすでに解決済みであり、勤勉な仕事しか残っていないことを意味します。たとえば3週間の作業が必要な問題の場合、これはおそらくスプリントの最初の数時間にグルーミングを行った後ではなく、2週間目に当てはまります。

そのため、スプリントが計画された後、チームは互いに依存関係がある可能性のあるさまざまな問題の塊に取り組みます。これは、同じように良いかもしれないが、お互いに異なる異なるソリューションを統合しようとする多くの通信オーバーヘッドを生成します。基本的に、試行錯誤の作業は、関係するすべてのチームメンバーに分散され、追加の通信オーバーヘッドが発生します（二次的に増加します）。これらの問題のいくつかは、特にポイント7のPaul Grahamによるこの記事で非常によく説明されていると思います。

もちろん、チームメンバー間で作業を共有すると、プロジェクトを離れる1人のチームメンバーに関連するリスクが軽減されます。一方、コードに関する知識は、他の方法、たとえばコードレビューを使用したり、同僚に技術的なプレゼンテーションを行ったりすることで伝達できます。この点で、私はすべての状況に有効な特効薬があるとは思わない：共有コードの所有権とペアプログラミングが唯一の選択肢ではない。

さらに、「より短い間隔での作業機能の配信」により、ワークフローが中断されます。機能のチャンクがスプリントの終わりまでに完了することができる「ログインページにキャンセルボタンを追加する」の場合、これは問題ないかもしれませんが、複雑なタスクで作業している場合、そのような中断は望ましくありません： 100 kmの速さで車を運転し、5分ごとに停止して、どれだけ遠くまで到達したかを確認します。これはあなたを遅くするだけです。

もちろん、頻繁にチェックポイントを設定することは、プロジェクトをより予測可能にすることを意味しますが、場合によっては、中断が非常にイライラすることがあります。

ですから、質問で述べられている態度は、変化に対するエゴや抵抗にのみ関係しているとは思いません。また、一部の開発者は、上記の問題解決のアプローチをより効果的であると考える場合があります。これにより、開発者は、解決している問題および作成しているコードをよりよく理解できるようになります。そのような開発者に別の方法で作業を強いることは、生産性を低下させることになります。

また、チームの一部のメンバーが特定の困難な問題について単独で作業することは、アジャイルな価値観に反するとは思いません。結局のところ、チームは自己組織化し、長年にわたって最も効果的であることがわかったプロセスを使用する必要があります。

ちょうど2セントです。

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

彼らは「ローンレンジャー」のようですね。標準的なスクラムでは、これらの人々はチームに適合できません（「相互作用」ビットを見逃します）。

彼らが「ローン・レンジャー」でなければ、希望があります。スクラムを適切に実行している場合、それらは（スプリントプランニング中に）作業する機能の設計の一部である必要があります。これは、他の人とやり取りするのに必要な唯一の時間です。その1つの機能に関連するすべてのストーリーを「割り当てる」こともできます。

スプリント中、彼らは毎日のスクラムによってのみ「おしゃべり」されます...あなたが彼らが彼らの時間のわずか15分であること、そしてすべてが実行されていることを保証するためだけに（言葉ではなく行動によって）それらを証明できるまでスムーズに。3つの質問に近づいていくと、ほとんどの人が従わなくなります。

私たちのチームには、パフォーマンスを向上させるための特別なグループがあります。スプリントの開始時に、行われる変更について話をするだけで、回顧展の終わりには、あまり見かけません。スクラムオブスクラムチームに報告する独自の「スクラムリーダー」がいます。私はあなたが言うことができます、彼らは楽しんでいます。

Joe（ヒーロー開発者）が少し柔軟であれば、問題は発生しません。

上記のように、チームを自己組織化させます：ジョーに自分で噛ませることでいくつかの問題に取り組むのが最善であれば、オープンマインドの自己組織化チームが自分でその結論に達することを期待します。

スクラムが課すいくつかの制約内に残る唯一の課題：

1. 一定の間隔で機能を提供する：ジョーに何ヶ月も問題をかみ砕いて、最後まで何も見せない場合、ジョーは実に機敏ではありません：彼は製品所有者を人質に取っており、再仕様する機会を許可していません製品のその部分。このプラクティスでは、彼が遅れて走るリスクもあり、誰もそれに気づいていない。（しかし、そうではないあなたの説明によると）。対処法：Joeに依頼し、POと一緒に座って、ユーザーストーリーを分割し、中間成果物について、できれば（必ずしもそうではないが）ユーザーの価値に同意するのは多すぎるでしょうか？

2. 製品所有者が設定した優先順位を尊重する：コードの一部が専門家によって所有されている場合、製品の進化は、商業上の優先順位ではなく、各専門家の可用性によって決定される状況になる危険があります。重要度の低い機能に取り組んでいるのに対し、上位3つの機能は「Joeだけができる」ために停止しています。それは良くないね。その瞬間、チームは（一時的に）習慣を変え、ジョーの仕事をより多くのチームメンバーに分割する必要があります。

つまり、主人公の開発者であるジョーが、各スプリントの進捗状況を示す方法にPOに同意した場合、チームは特定のストーリーを彼に割り当て、彼を放っておくことができます。しかし、POがJoeに対してあまりにも多くの作業を行い、チーム（またはその逆）に十分でない場合、JoとチームはPOではなく適応する必要があります。

アジャイルチームのルールは、チームに合わせてカスタマイズする必要があります。これは本当に個人的なカスタマイズです。たとえば、私はルールが次のようなチームで働いていました。

Davidはコードを単独で作成する場合を除き、すべてのコードはペアで作成する必要があります。

Davidはシニア開発者/アーキテクトであり、主に他の人が自分のコードで使用するツールの開発に携わりました。彼は自分が書いたコードを非常に所有していました。それは保守可能でテスト済みであり、チームの誰もが彼がおそらく最高のコーダーであり、特定のフレームワークを構築し、チームに完全なものとして提示することでチームに最高のサービスを提供できることを知っていました。

私は庭の多様な内向者には答えがありませんが、例外的な内向者には、利益を得るためにチームは喜んで異なるルールを取ります。