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


52

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

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

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

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

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


7
There’s a great story of a manager of a Coca-Cola plant whose numbers were far better than his peers. When asked what his “secret” was, he said simply that rather than take a best practice and modify it to meet what the plant did, he instead modified the plant to match the best practice.なぜあなたがそれをするのか理解するまで、あなたはアジャイルをしていません。
誰も

彼らがより良いコードを書いて、より多くを学び、より少ない問題を抱えるので、彼らが協力することがより楽しいことを彼らに示してください。

詳細はプログラミングに固有のものですが、変更を管理するという一般的な職場の問題であり、workplace.seで確認することをお勧めします。
マッテンツ14年

参考までに、以下の回答に加えて、覚えておくべきもう1つのことは、アジャイルはFacebookやWhatsAppを出荷できないという意味ではないということです。これは、出荷方法が異なることを意味しますが、個人は大きなピースを所有できます。たとえば、あるケースでは、私は大規模な展開システムを所有しており、船のマイルストーンは2週間ごとでした。出荷とプロセスは、機能の設計、開発、リリースなどに影響を与えません(もちろん、メカニズムを除きます)。
オメルイクバル14年

回答:


22

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

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

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

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

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


ご回答有難うございます。少なくとも1つのケースでは、できる限り最後の提案に引き寄せられると思います。私たちは、一人の人によるオフサイドのプロジェクトが、私たちが開発したコミュニティの所有権の多くを脱線させないことを考えなければなりませんが、それは価値があるようです。
クリス

4
あなたが少数の人々とそれをするつもりなら、それが実際にプロジェクト作業をしている他の人の士気にどのように影響するかに注意を払ってください。彼らはあなたが不平を言う人々に特別な利点または優遇を与えていると感じるかもしれません。
maple_shaft

また、数人のメンバーが先駆者として活動している場合でも、全員が互いに関与し、コミュニケーションを保つように細心の注意を払ってください。例:全員が毎日の会議や計画会議に参加します。トレイルブレイザーは、作業の概要を説明し、定期的に結果をデモする必要があります(アジャイルチームよりも頻度は低いかもしれませんが、2週間または1か月に1回)行き止まりを追求し続ける)。免責事項:私はまさにこのような人であり、本当にうまくいくと思います。
rwong

1
一方、会社の開発労働力が主に先駆者で構成されており、アジャイル開発スタイルに適応しないことはコンセンサスである場合、この労働力はアジャイル開発プラクティスを採用するのが非常に難しいでしょう。他のアプローチを模索する必要があります。先駆者は実験を好むので、製品化のニーズに対応するために新規採用者を雇用する必要があります。そのため、会社はR&Dを収益化できます。
rwong

44

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

正しい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


私たちが何か間違ったことをしていることは間違いありません。アジャイルは、正しい方法を適用する必要がある一連のルールとは見なされません。私たちは、かつて持っていた特定の制約を捨てる決定を下し、チームを結成し、仕事をさせ、仕事の境界を与え、それをやらせるために彼らに任せておくために、私たちの力であらゆることをしました。もちろん、対処しなければならない制約があります。たとえば、他のチームが依存している資料を作成するチーム。可能な限り、この種の問題をチームが解決できるようにします。...
クリス

いつかペンを置いて「はい、移行が完了しました。今はこのように動作しています」と言うことは期待していません。開発者が仕事を楽しむのに苦労するすべての場合、彼らは今や仕事をもっと楽しむ他の人に囲まれています。チームは自分で問題を解決する権限を持ち、自己組織化して、最善と思われる方法で整理します。人々がこれにどのように反応するかを見るのは驚くべきことです。「我々はアジャイルになれない!それは我々が何とかして何とかして何とかして何とか何とかして整理しなければならないことを意味するだろう、そしてそれはコストがかかるだろう!」「そうですか、それでいいです。」...
クリス

1
@クリス:「チーム内の個人は、以前のように報われることはもうありません」。正しい。それは物事が変わったからです。私(長い見知らぬ人)への長い説明は、実際の問題を抱えている実際の人々との長い詳細な議論ほど役に立たないかもしれないと考えたいかもしれません。「プロセスとツールに対する個人と相互作用」。彼らと話してください。彼らは何が好きではないのですか?修正したいものを修正します。「アジャイル」を廃止したい場合は、アジャイルを廃止して、厳しいスケジュールを作成させます。スケジュールの変更を許可し続けます。
-S.ロット

1
@クリス:「彼らはそれが修正される必要があるとは思わない。彼らはもはやその中に自分の場所を見ないかもしれない」。それは矛盾しています。確かに2つの平行した独白のように聞こえます。彼らは深刻な問題を抱えており、経営陣は彼らの苦情が全体的な組織の目標に合わないことを伝えています。アジャイルマニフェストのどの部分も、いずれの当事者によっても読まれたり理解されたりしていないように思えます。彼らは本当に「相互作用」していません。不満を抱いている人は、修正を提案することはできません。そのため、彼らはそれが修正できることを知りません。
-S.ロット

1
「不快で非生産的な方法で人々を働かせるとは言いません」すべての方法論から私が恥ずかしがる理由の1つは、特にそれらが流行している点まで人気が出てきたときに、正確に、それらを実装する人にほとんど常に発生するクッキーカッターメンタリティです。
ちょうど私の正しい意見

23

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

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

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

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

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

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

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

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

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


3
コメント:コメントは明確な説明を求めるためのものであり、詳細な議論のためのものではありません。解決策がある場合は、答えを残してください。ソリューションが既に投稿されている場合は、投票してください。他の人とこの質問について話し合いたい場合は、チャットを使用してください。詳細については、FAQを参照してください

8

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

それは...ですか:

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

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

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

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

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

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

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

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


4

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

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

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

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

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

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

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


2

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

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


2

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

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


こんにちは-私の意図は、他のチームによってハッキングされたコードを見ることとは関係ありませんでした。「あなたは私のコードに何をしましたか!! Aargh!」を見てきました。数回、滝とアジャイルで、しかしそれは別の問題です。それは、自分が仕事を取り、それを完成させるために独立して仕事をすることができないと感じる人々についてです。
クリス

1
ここで行われている議論によって私の答えは多少抑えられたかもしれませんが、これらが現在所有権の欠如を感じている有能な人々であれば、所有権を持つことができる何かに焦点を変えるのを助けることはまだ有効だと思いますチームへの主要な貢献者でもあります。
ジョエルC

2

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

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

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

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

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

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

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

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

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

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

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

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

ちょうど2セントです。


1
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つの質問に近づいていくと、ほとんどの人が従わなくなります。

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


3
-1-非常に生産的な人々はアジャイルアプローチを気にしないので、孤独なレンジャーであると仮定するため。「自分の可能性に生きる」または「チャレンジを楽しむ」というフレーズを聞いたことがありますか。おそらく彼らはアジャイルアプローチを実践している間にそれを見逃しているでしょう。
ダンク

私はそうは思いませんでした。私の鐘は、ローンレンジャーの定義である「他者との最小限の相互作用のみ」によってトリガーされました。ローンレンジャーは、そういう風に気に入っているので、時々そうです。彼らのための場所はありますが、その場所はアジャイル(「プロセス上の相互作用」のこと)チームではありません。ローンレンジャーズは、プログラミングからすべての楽しみを奪う政治、PMの「実践」、および官僚主義を嫌うため、時々そのようになります。その場合、アジャイルがしようとする方法で環境を変更すると、チームで楽しむためにローンレンジャーから環境を変更します。
Soronthar

0

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

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

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

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

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

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


また、チームは、ジョーがチームに対して「部分的にしか利用できない」ことを考慮すると、チームにスキル不足があるかどうかを自問する必要があります。
rwong

-1

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

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

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

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


昔の時代の会社のドレスコードを思い出します。マーケティングスタッフは、マーケットロイドが顧客に開発エリアを見せたいと思うことがあるため、開発者はドレスコードを用意する必要があると主張しました。助けてくれた上司は、開発者のドレスコードを考え出しました。同社はハッカーによって実行されたとき、それは....助け
JUST MY正しい意見

難しい問題に取り組むために時間と集中力を必要とする人は内向的だと思いますか?難しいことに取り組むために集中する必要があり、気を散らされたくないということはありえないでしょうか?
ジョルジオ14年

このような「アジャイルチームの専門家」のパフォーマンス評価の基準を強調する独自の回答を作成する準備をしています。チーム全体の全体的な(特別な領域の)知識を高めます」。
rwong 14年

@rwong:そのためにアジャイルである必要はないと思います:あらゆる種類の開発プロセスを使用するチームは、チームメンバー間の知識のより良い分配から利益を得ることができます。
ジョルジオ14年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.