scrum - スクラムプロセスは、最終的にチームメンバーをそれぞれのスキルから引き離しますか?

Question

私の組織は、より多くの「アジャイル」手法の導入を試みてきました。私たちはしばらくスクラムのアプローチを試してきましたが、ほとんどのチームは多かれ少なかれそれに適応しています。全体としては気に入っていますが、方法論の潜在的に重大な影響が 1 つあります。チームは一貫して機能とバックログ項目に焦点を合わせており、テスターは開発プロセス全体とより統合されているため、スキルセットがぼやけ、人々は自分の能力に対する敬意が薄れていると感じています。

当社の開発者の中には、サーバー側の技術と重量データプロビジョニングの最適化に優れている人もいます。また、キャリアの多くを GUI テクノロジの学習に投資し、ユーザーとアプリケーションの使いやすさについての基本的な理解を深めた人もいます。どちらのスキルセットも優れていますが、確かに異なります。

これはスクラムプロセスの必然的な結果ですか? チームの全員が (私が理解しているように) 次の機能/要件、バックログ項目、または目前のテスト目標を満たすことに貢献しているため、根底にある哲学は「誰でもできる」ということのようです。私の経験では、これは単に真実ではありません。ほとんどのエンジニア (開発者、テスターなど) は、何年にもわたって磨いてきた特定のスキルセットを持っています。私の考えでは、スクラムの方法論は、以前は彼らが尊重されていた能力そのものを過小評価する傾向があります。

明確にするための例を次に示します。

サーバー側のデータプロビジョニングで技術の突然の変更が発生し、スプリントの to-do リストのすべての項目がこの新しい変更に基づいている場合、GUI 開発者 (おそらく、その変更に慣れる時間がなかった)新技術）はスプリントに貢献できないかもしれません。少なくとも、彼らは成長するために時間を投資する必要があり、そうすると彼らのコードは経験不足のために疑わしいものになります.

「役割のサイロ化」を思いとどまらせるために迅速な開発が必要であることは理解していますが、これは 1 つの基本的な現実を軽視しているわけではありません。それは、人々は必要性、興味、経験に応じてスキルを開発するということです。人は、自分の立場が「プラグアビリティ」の 1 つであることを認識すると、やる気が低下するようです (たとえば、この特定のタスクを実行するために誰でも「プラグイン」できる)。スクラムはこれにどのように対処しますか? そうでない場合、スクラム方法論を採用するときに誰かがこれに対処しましたか?

score 16 · Accepted Answer

短い答えは、断固としたNOです！スクラムは、専門化に必要なスキルを曖昧にしたり、弱めたりしません。スクラムは一般化を促進しません。

長い答えは、スクラムで最も重要なことは作業を「完了」させることです。チームは、(個々の「スター」の集まりとは対照的に) チームとして、仕事を成し遂げるために必要に応じて協力します。必要なものは何でも - 彼らは望んでいます (スクラムは、自己管理と自己動機付けのチームに関するものですよね?)。

これが意味することは、スクラムチームは、主に専門分野 (DBA、グラフィックデザイン、さらにはテクニカルライター) を行う複数のスペシャリストで構成される可能性があるということです。チームは全体として、要件を満たすために必要なすべてのスキルを備えている必要があります。これは、各チームメンバーが前述のすべてのスキルを備えている必要があると言っているのと同じではありません。

そうは言っても、多くの場合、メンバー自身が、スペシャリスト以外のメンバーが専門分野とは異なるスキルを少なくとも十分に備えていることを望んでいます。別のポスターでは、Scott Ambler の「General Specialist」について言及されています。これは、ある種類の仕事が多すぎる場合や専門家が不在の場合にチームを助け、メンバーが自分の専門以外の経験を本当に積みたい場合に役立ちます。

チームは自己組織化されているため、何らかの理由でスペシャリストがスプリントの途中で自分の専門分野で行う作業がないことに気付いた場合、それに対処する最善の方法は、スペシャリストに何をしたいのかを単純に尋ねることです。行う。チームに決めさせてください。スペシャリストは、適切な他の領域を支援するか、次のスプリントの POC を実行するか、長い間忘れられていた技術的負債を修正して防御を「強化」するか、または作業中のメンバーの靴を磨くことができます。

うん。これが長い答えかどうかはわかりません。しかし、それは間違いなく長い答えでした。:-)

score 12 · Accepted Answer

スクラムのポイントは、開発者が自己組織化することです。私がいる場所ではスクラムを使用しており、仕事は人の焦点によって受動的に分類されます。チャートやリストでわざとそうしているわけではありません。私たちは皆、誰が何を最も得意としているか、または彼らの主/副次的な焦点が何であるかを知っています。「主要な」人が助けを必要とする場合、彼らはその人に二次的な焦点を当てて助けを求めます。私たちは、特定の焦点が何であれ必ずしも一致しているとは限らない多くのタスクを受け取りますが、その場合、誰に助けを求めるかは常にわかります.

あなたの例では、3人のサーバー担当者と5人のGUI担当者がいたとしたら、そのスプリントですべての作業を完了すると予想されるかどうかはわかりません（サーバー担当者と他の人からの助けがなかった場合）足りる）。スプリントの本来の仕組みは、開発者が優先順位を付けたリストから、その 30 日間の時間枠で達成できると思われるものを選ぶことです。それが、GUI 担当者が支援するために 2 日間のサーバー側トレーニングを必要とすることを意味する場合、それが意味することです。代わりに実行できるリストの上位にも同時発生するものがない限り。スプリントのタスクは、疑似締め切りとして経営陣によって指示されることは想定されていません。

Safari アカウントをお持ちの場合は、スクラムを発明した人物の 1 人による、主にケーススタディの興味深い本があります。

score 3 · Accepted Answer

私は約 18 か月間スクラムマスターとして働いており、2 つの異なるチームで働いてきました。私は当初、あなたが提起した潜在的な問題を経験することを期待していましたが、そうではありませんでした. 私が一般的に観察しているのは、人々が自分自身に適切な役割、つまり楽しんで成功できる役割を見つけるにつれて、チームがスペシャリストとゼネラリストの混合物に進化するということです. これが職場での自己組織化です。私たちのスペシャリストが何もせずに座っていたというケースは一度もありません。

これが発生した場合は、Sprint Retrospective で問題として取り上げられ、チームが状況を改善する方法について話し合うことを期待しています. 最も明白な (そして残忍な) 結論は、チームの構成を変更することです。

score 2 · Accepted Answer

Scott Ambler は、 http: //www.agilemodeling.com/essays/generalizingSpecialists.htm でこの問題を非常に徹底的に扱っていると思います...

ジェネラライズスペシャリストという彼の概念は、まさに共同所有権 / スクラムチームが求めているものであり、私には完全に理にかなっています。

実生活で達成するのは難しいですが;-)

score 2 · Accepted Answer

スキルセットがぼやける理由がわかりません。アジャイルの世界にはかなりの混乱があります。スクラムはプロジェクト管理プロセスであり、ソフトウェア開発プロセスではありません。エンジニアは、TDD やエクストリームプログラミングなどの独自の方法論に従って、アジャイルに独自の部分を追加する必要があります。

スクラムでは何もなくなりません。

PM は今でもドキュメントを作成しているアーキテクトはコンポーネントを設計しています。唯一のことは、いくつかの主要な決定をより責任ある時点まで遅らせるだけです。開発者は引き続きSOLID 原則などのベストプラクティスに従って、機能が変更されたときに一貫した方法でリファクタリングできるようにする必要があります。

score 1 · Accepted Answer

スクラムの最も良い点は、まさにスキルが少しぼやけているという事実です! 重要なのは、チーム全体に専門知識を広め、人々が快適な領域の外で作業できるようにすることで、サイロ化を何としてでも回避することです。

明らかに、これは万人向けではありません。一部の開発者は自分の狭い専門分野に満足しており、そのような人々は資産よりもスクラムプロセスの妨げになります。それとはるかに生産的です。

スクラムの主な利点の 1 つは、チーム全体がプロジェクトに実際に関与し、投資するようになることです。チーム独自の特別なタスクに取り組んでから地平線に向かうのではありません。ほとんどの人にとって、これはコンベヤーベルト (ウォーターフォールプロセスのアプローチ) よりもはるかにやりがいのある作業方法であると私は主張します。

したがって、サイロ化された専門家に頼るのではなく、スキルを組み合わせて人々を集めて厄介な問題を解決することを大胆に受け入れることをお勧めします。やる気のある人々で構成されるチームの結果は、驚くべきものになる可能性があります。

score 1 · Accepted Answer

なんらかの理由 (「技術の突然の変更」であろうとなかろうと) で、スプリントでシステムに必要な作業量が利用可能な作業量よりも多いことがわかった場合は、スケジューリングに問題があります。

解決策の 1 つは、あなたが示唆するように、他の分野からプログラマーを連れてきて、ミックスに投入することです。これがどれだけうまく機能するかは、その人のスキルと問題領域の違いに依存しますが、プログラマーを必要に応じて外に出すことができる一般的なユニットとして扱うことは、一般的にソフトウェア開発の成功戦略ではありません。

ただし、これはまだスケジュールの問題です。

score 0 · Accepted Answer

突然の変化に対処することはアジャイルの一部であり、これは、一部の人々が離れて新しいスキルを習得しなければならないことを意味する場合があります。もちろん、これはスクラム固有のものというよりも、一般的なアジャイル哲学の範囲内です。極端なケースとして、顧客や企業が何か新しいものを導入して世界を変えようと決心し、その結果、人々が勢いを増すというその後の苦痛に対処しなければならない場合がありますが、これが彼らの望みであり、開発者が却下された場合は、選択肢は2つだけです：（塊を取り、大きな変化を処理するようにしてください）または（やめてそこから抜け出してください）。

何かに特化した人が物事をより速く行うことができる場合もありますが、それが専門家であるチームの 1 人だけであり、その分野で十分な作業がある場合、これは必ずしもあまり意味がありません。スプリント全体で10人。専門家でない人はその仕事をせずに、一人の人にできる限りやり遂げさせてはいけませんか? 私はそうは思いませんが、できることをまだやり遂げようとしている何かが得意ではない人には、何か言わなければなりません。

score 0 · Accepted Answer

これは、よりバランスの取れた開発者につながり、特定の分野の専門家が専門知識を提供し続けることを可能にします。

私は（まだ）スクラムをあまり使用していませんが、あなたの説明からすると、これらのタイプのチームは、全体としてよりバランスの取れたチーム/組織につながります-そして、それはどのチームの目標であってもなりません?

scrum - スクラム プロセスは、最終的にチーム メンバーをそれぞれのスキルから引き離しますか?

9 に答える 9

Related

Reference

scrum - スクラムプロセスは、最終的にチームメンバーをそれぞれのスキルから引き離しますか?