スクラムが優れたプログラマーを破壊するというのは本当ですか、それとも誤用されているからですか？

最近、stackexchange.comの質問が私たちの注意を引きました。この質問は、プログラマーの仕事に対するスクラムの影響を理解することを目的としていました。質問の著者であるユーザーQiulangは、かなり大胆なトピックを取り上げています。「Scrumは優れた開発者を平均的なプログラマーに変えます。出来ますか？"。



スクラムフレームワークの主なアイデアは、プロジェクトのライフサイクルのさまざまな段階で作業をより迅速に実行するための開発プロセスを整理することです。しかし、このアプローチは常に開発者を正しい行動に向かわせるのでしょうか？上記の質問の議論に参加した多くのユーザーStack Overflowでは、開発者が手抜きをしたり、チケットに割り当てられた高得点を強調しすぎたり、マネージャーの前で優秀な従業員のふりをしたりするという同様のことを経験しました。これらの危険をどのように回避できますか？ 問題の質問はworkplace.stackexchange.comからsoftwareengineering.stackexchange.comに移動しました。これは、プログラマーがスクラムとその有効性を取り巻く考慮事項を、ソフトウェア開発サイクルの管理を超えるほど深刻なものと見なしていることを示唆しています。彼らは、このプロジェクト管理方法が全体的な作業環境に与える影響を感じています。

Scrumは悪い開発慣行の原因ですか、それともこの問題の単なる言い訳ですか？

多くの論争は、チームや個々の開発者に対するスクラムの影響と、それを使用する人々に課す制限についての憶測を引き起こしました。多くの人がスクラムをチームの失敗のせいにしていますが、これは帰属エラーであり、開発チームの問題の根源ははるかに深いと信じている人もいます。



スクラムの支持者は、悪い管理を問題の根源と見なしています。これがユーザーLlewellynの言うことです、要約すると、「経営陣は基本的に開発者を無視します。所定の結果を達成するために満たすべき一定の期限があります。仕事は同じ目標を達成することに焦点を合わせたチームによってではなく、誰もが自分自身だけを気にする人々のグループによって行われます。事前に計画を立てて、既成概念にとらわれずに考えることはお勧めしません。そのような状況では、結果として、プログラマーは状況に屈し、彼に割り当てられたタスクの単純な実行で救いを見つけます。私はそのような状況で働いてきました。しかし、それをスクラムのせいにしないでください。」



ユーザーDJClayworthは、多くのコメントの感情を表明し、プレッシャーにさらされていると考えるプログラマーは、どの開発管理方法でもパフォーマンスが低下すると述べました。



この問題についての反対意見は、ユーザーのマーティン・マートによって最もよく表現されました。マーティン・マートは、非常に多くの人々がこの問題について発言する必要性を感じているという事実が、スクラムを引き起こす欲求不満を物語っているという事実に聴衆の注意を引きました。

スクラムを使用する際の一般的な問題は何ですか？

いくつかの一般的なスクラムの落とし穴がコメントに現れました。これは、フレームワークが誤用されているため、または実際にはスクラム固有の問題であるために表示されます。ここに私たちの注意を引いたこの種のほぼ12の問題があります。

▍1。毎日の会議はマネージャー向けです

スクラムに対する最初の批判は、毎日の会議（スタンドアップ）中に望ましくない傾向が生じるという事実に関連しています。このアイデアを支持する議論の1つは、スタンドアップはイベントの状態に低下する可能性があるということです。イベントの参加者は、生産性について言うことだけを行います。特にマネージャーがそのようなイベントに出席している場合。そのため、ユーザーのMatthew Gaiser（彼はすでに私たちのために書いていますが、偶然彼の解説に出くわしました）は、マネージャーに現在の状況を知らせることを目的としたスタンドアップイベントを呼び出しました（更新管理）。彼は、そのようなイベントでの開発者のプレゼンテーションは、マネージャーが自分たちが取り組んでいることを観察することを奨励するだけであり、それは何の利益ももたらさないと信じています。これは、チームメンバーのそれぞれが独自のモードで作業する分散チームの場合にさらに当てはまります。

▍2。タスクの完了が大きな役割を果たします

コメントで浮かび上がったもう1つのアイデアは、大きなタスクを小さなタスクに分割し、それらのタスクの進行状況を監視する開発方法論は、意図的かどうかにかかわらず、作業を評価するための新しいアプローチにつながるというものです。いくつかの指標を適用し始めたばかりの場合、これらの指標に従ってパフォーマンスが評価される人々の行動に影響を及ぼします。



多くのコメント提供者は、これは開発者が現在のスプリントで実行する必要があることを完了するために「手抜き」できることを意味すると言います。ユーザーガイザーが指摘した問題他のユーザーは、作業中の別のチケットで、スプリント中に「準備完了」のカテゴリに転送されます。これは「ブラックボックス」です。この「ブラックボックス」の中に何が入っていても、作業速度の評価結果には影響しません。User Gaiserは、QA部門を通過した低品質の実装と、完全にテストおよび設計された実装は、互いに違いがないと書いています。その結果、クローズされたチケットの数を考慮することは、労働生産性の信頼できない指標であることが判明しました。

▍3。チームとして働いていない非常に生産的な開発者

別のスレッドでは、優れたソロプログラマーと優れたチームの間の矛盾について議論しました。全員がスクラム手法に従うと、一部の開発者は非常に生産的になる可能性がありますが、その場合、「チーム」は忘れられる可能性があります。User Gaiserは、適切なインセンティブがなければ、自己組織化は達成不可能な目標であると述べています。「チームメンバーは、適切と思われる、または指示に従って問題を解決します。それがチームの構築に役立たない場合、多くのことが満たされないままになり、チームメンバーは単に混乱して前進します。」



「さらに、各開発者が問題を解決するための独自の方法を選択できるようになると、コードのデバッグがより困難になる」と彼は続けます。

▍4。難しいタスクは後で延期されます

ガイザーは、同じように、生産性の幻想を批判し続けています。彼は、スクラムを適用するとき、主な焦点はチケットを「準備完了」状態にすることにあると言います。同時にタスクについて深く考えることは、特に生産的ではないようです。したがって、開発者は簡単なタスクを引き受け、より複雑なタスクを回避する傾向があります。ここでも、ユーザーGaiserの言葉：「Scrumは、開発者が解決に少し時間がかかる簡単なタスクを実行することを奨励します。これにより、開発者は一貫して高いパフォーマンスを示すことができます。」その結果、毎日のタスクの選択と毎日の作業レポートが、完了するのに1日かかるタスクの選択を後押ししていることがわかりました。

▍5。製品の機能はコードの品質よりも重要です

同じガイザーは、スクラムフレームワークを使用すると、製品の品質が低下すると考えています。「開発者がどれだけ優れているかは、通常、信頼できるコードを開発する能力によって決まります。スクラムは、製品の所有者がプログラミングを理解してコードを確認しない限り、プロジェクトのこの特性を大幅に評価します。」彼はここで、チケットの「準備」は、コードの品質をチェックした後ではなく、対応する機能が実装された後にのみ決定されることが多いことを強調しています。

▍6。同僚と仕事の問題について話し合う時間がない

開発のスピードがチームの有効性の唯一の指標である場合、それはチームメンバーがお互いにいくつかの問題について話し合ったり、他の人の意見を得たり、誰かのために彼らのアイデアをテストしたりする時間がなくなったことを意味しますそれらについて話します。そしてそれこそがチームをチームにするものです。ここでも、ユーザーGaiserの言葉は次のとおりです。「優れた開発者は他の開発者と相談し、彼らの意見に代わるものを探すことがよくあります。しかし、そのようなクラスはチケットを閉じるのに必要な時間がかかり、これは開発速度を遅くします。」

▍7。最近特定されたバグは順番を待たなければなりません

別の悪いスクラムの動作は、「バグはスプリントの後に発見され、新しいタスクと見なされる」ことです。現在のスプリントに追加のタスクを含めることができないため、これにより開発者は低品質のコードをリリースするようになります。

▍8。チケット駆動型アーキテクチャ

チケットシステムは、開発者が自分で選択したタスクに基づいているだけではありません。User Gaiserはまた、開発者がチケットを表示順に、互いに独立して作業するため、Scrumを誤って使用すると、プロジェクトのアーキテクチャが混乱する可能性があると述べています。その結果、「アーキテクチャはすぐにチケットの反映になります」。

▍9。絶対にすべてに影響を与える開発管理方法論

ディスカッションを読むと、コメントに注意を払うことができます。コメントの作成者は、すべての問題の根本はスクラムルールの厳密な遵守の欠如にあると述べています。しかし、おそらくガイザーからの最も強力な反スクラムの主張は、フレームワークが他のすべてを引き継ぐということです。これは強力なチームを破壊する可能性があります。 「[スクラム]は他の開発管理メカニズムを歪めたり壊したりします。このフレームワークは、儀式を実行するだけで均一に行われるという普及した現象になり、これらの儀式を実行すると成功の幻想が生まれます。」



Scrumの使用によって引き起こされる可能性のある問題のかなり長いリストについて説明しましたが、おそらく、このフレームワークの使用によってのみより顕著になります。しかし、私たちが調査している議論では、スクラムのルールに従うことで、開発者が平和で調和して生きることができる方法について、同じくらい多くのアイデアを見つけることができます。

スクラムを最大限に活用するには？

多くの肯定的な評価を受けたガイザーのコメントに対する反応の多くは、彼が話していたのはスクラムではなかったというものでした。ユーザーのStephenByrneがこれについて書いたものは次のとおりです。「これはいくつかの貴重な洞察を備えた良い答えだと思いますが、ここで説明されていることは間違いなくスクラムではないという他の多くのコメントに同意する必要があります。スクラムを装って見られます。」しかし、多くの人はスクラムを公然と嫌っていたか、スクラムの使用中に問題が発生した場合、このフレームワークが単に正しく使用されていないことを意味するというガイザーユーザーに同意しました。



スクラムを正しく使用する方法は？

▍1。毎日の会議は、毎日新しいチケットを受け取ることと同じではありません

多くの人が、毎日の会議は開発者に毎日チケットを閉じることを強いると言いました。ただし、DJClayworthが指摘しているように、タスクに優先順位を付けることなく実行することはできません。また、優先順位が自然に設定されていない場合は、このタスクをスクラムマスターが引き継ぐ必要があります。「スプリント内のタスクに優先順位を付ける必要があります。大きなタスクには高い優先順位を付ける必要があるため、スプリントの初日に誰かが難しいタスクを引き受ける必要があります。いずれにせよ、2日目までに誰も大規模で複雑なタスクを引き受けていない場合、スクラムマスターは次のように言う必要があります。「データベースの圧縮タスクを誰も引き受けていないようです。そして、これは大きな仕事です。スプリントを完了する場合は、今すぐこのタスクに取り掛かる必要があります。」

▍2. ,

スプリントで解決されるすべてのタスクは、小さな部分に分割する必要があります。これは否定できません。しかし、スクラムフレームワークは、開発者が結果を示すメトリックに取りつかれるべきだと言っているわけではありません。 Scrumは、開発者を互いに対立させることを示唆していません。 Gaiserユーザーは、個々のプログラマーポイントの考慮を完全に放棄することを提案します。彼は、多くのマネージャーがスクラムのルールを再検討する必要があるかもしれないと指摘します。 "。



ユーザーDJClayworth個々のチケットに関連付けられたメトリックを意図的に無視することは、優れたスクラムマスターのタスクの一部である必要があることに同意します。「チームがチームとしての目標を確実に達成することに注意を向ける必要があります。スクラムマスターは、この行動方針に固執し、チームの各メンバーが宣伝したユーザーストーリーの数に基づく議論や指標を避ける必要があります。」

▍3。大きな目標に向けて小さな一歩を踏み出す必要がありますが、このアプローチでは、これらの目標を忘れてはなりません。

大きな問題を小さな断片に分割するための別のアイデアは次のとおりです。「パズルの小さな断片に取り組んでいる場合、それはパズル全体を忘れる必要があるという意味ではありません。」



ユーザーLlewellynは、スクラムを使用することは、高品質のソフトウェア開発の原則を完全に無視する言い訳にはならないことを指摘しています。「プロジェクトがどこに向かっているのかをよく理解する必要があります。この知識は、プロジェクトのアーキテクチャを計画するために使用でき、現在のスプリント内でも計画に従事します。」



Scrumは、プログラマーが仕事をする必要性から解放されるわけではなく、すべての知識とすべての経験をそれに投資します。したがって、Llewellynの呼びかけは、コメントの読者の1人であるプログラマーに向けられます。「あなたは会議に参加していました。バックログを見ることができます。プロジェクトの全体的なビジョンが組織内にあることがわかります。あなたは遠い未来から何かに長い時間を費やす必要がないように努めます。しかし、現在の問題を解決するのに適しており、将来問題なくすでに計画されている追加の機会を作成できるようになる、拡張可能なモジュラーシステムの基盤を築くことに問題はありません。」

▍4。「完了」の意味を決定する必要があります

私たちが議論していた議論で提起されたトピックの1つは、完了の定義（DoD）基準、およびこれらの基準を定義することで、個々のプログラマーが特定の品質基準を順守し、期待されるものを常に把握するのにどのように役立つかに関するものでした。ここで最も差し迫った質問は、誰がいつこれらの基準を作成していたかということでした。 「いつ」ということになると、それは通常、基準をできるだけ早く開発すること、またはスプリント計画中に基準をどのように開発するかについてでした。



誰がDoDを作成するかという質問への回答は、ユーザーSpoonerNZによって別の質問への回答の形で書かれました。ソフトウェアエンジニアリングのWebサイト。 「準備基準はチームによって作成されますが、このプロセスではスクラムマスターの存在が必要になる場合があります。これは、チームに明確な開発基準がない場合に、品質に関する制限を設定するために必要です。たとえば、チームがコードレビューやユニットテストをいじりたくない場合は、高品質の開発を保証するために、これらすべてがScrumMasterによってDoDに追加されます。理想的な状況では、提供されているものの長所を理解したチームは喜んでそれを受け入れますが、現実の世界は必ずしも理想的ではありません。」



DoDを遵守しながら、誰が作業する必要がありますか？自然な（そしてやりがいのある）目標は、DoDで概説されている規定が1つのチームに適用され、そのチームのすべてのメンバーによってサポートされるようにすることです。しかし、DoDの影響力を複数のチームに拡大するのには十分な理由があります。または組織全体ですら。これがユーザーのAlanLarimerが書いたものです：「製品​​に対して広く認識されているDoD定義がないことは、作業の品質と透明性に悪影響を及ぼします。DoDの組織レベルは最小限で、技術的で、場合によっては組織固有である必要があります。これにより、準備基準の普遍的な適用が可能になります。組織はコーディングの標準を提案できます。組織は、各製品のアセンブリを作成および保守するためのリソースを提供して、自動アセンブリ作成を必要とする場合があります。DoDのどの部分も、組織によって作成されたか、個々の開発者によって作成されたかにかかわらず、準備基準に価値のあるものをもたらす必要があります。」

▍5。管理者はサイレントオブザーバーの役割を果たす必要があります

このセクションの見出しにあるものはすでに公式のスクラムマニュアルに記されていますが、議論の分析は、悲しいことに、マネージャーが出席する毎日の会議でこのルールに違反することが多いことを示しています。このため、プログラマーは、チケット作業に計画よりも時間がかかる理由を説明する必要があると感じています。会議に参加しているのがプログラマーだけの場合、そのような説明はほとんど必要ありません。スクラムのマニュアルには次のように書かれています。「デイリースクラムは開発チームの内部会議です。他の誰かがそこにいる場合、スクラムマスターは彼らが会議に干渉しないことを確認します。」

▍6。人はプロセスよりも重要でなければなりません

スクラムルールを適用する方法のガイダンスについては、ユーザーのフランクホプキンスが書いた言葉を読んで、「プロセスよりも人の方が重要である」という1つの古典的な原則を思い出させてください。ここで彼は次のように付け加えました。「優れたチームはそのプロセスを定義する必要があります。厳密に定義されたプロセスは優れたチームの形成に貢献しません。」



別のユーザーであるメリトンは、スクラムの使用は個々のプログラマーに依存していると指摘しました。「スクラムは、開発者が互いに独立して作業することを提供していません。 Scrumは、開発チームが自己組織化すること、つまり、チームがメンバーの相互作用について決定を下すことを規定しています。」



ユーザーnvoigtノートスクラムのチームは、定義された使命を持ってプロジェクトに参加するため、自己組織化します。「スクラムフレームワークは、あなたがチームであるという事実に基づいています。チームでは、チケットが特定のプログラマーによって昨日閉じられたかどうかは関係ありません。チームで働く人は誰でも目標（つまりDoD）を理解し、チームの他のメンバーと一緒にそれを達成しようと努力します。」

▍7。スクラムのように機能するチームを構築しますが、スクラムがチームを作成することを期待しないでください

ユーザーnvoigtスポーツの比喩を適用しました。「11人が印刷されたサッカーマニュアルを受け取ったと想像してください。毎日午前10時頃に会議室5で15分ずつ練習する必要があると言われました。結果は良いサッカーチームになると思いますか？これらの11人が優秀なプロのサッカー選手だったらどうでしょうか。とにかくコマンドは機能しませんか？はい、そうではありません。フットボールチームがそのように作成されていないというだけです。他のチームスポーツと同様に、スクラムにはこのフレームワークを使用する人がチームになる必要があります。ユーザーストーリーでカバーしたポイント数や達成した目標数を示すことで、それぞれが自分でポイントを獲得したいだけのグループの場合、このグループは、メンバーが隣り合ってではなく、一緒にプレイするチームに常に負けます。友達、またはお互いに対して。」

結果

nvoigt ユーザーは、スクラムが「すべての人やチームに完全に適しているわけではない」ことを認めようとしています。そして、ここで議論している問題に対するコミュニティの関心が示しているように、スクラムが開発するためにプッシュする可能性のある一連のルールを適用すると、構築したいものからかけ離れた作業環境につながる可能性があります。



この資料の結果をユーザーSethRの言葉で要約したいと思います。..。彼は、機敏な儀式から奇跡を期待する必要はないと言います。開発チームの欠点を修正するために、まるで魔法のように助けを求めている人々は、あまりにも多くのことを望んでいます。これが彼の状況の見方です。「フィードバックをスピードアップすることがすべてです。その結果、チームは自己レビューを行い、最良の結果を達成するための作業方法について決定を下す機会があります。スクラムは、より良い製品を作成するのに役立ちませんが、セルフテストに真剣に取り組む場合は、より良いチームを構築するのに役立ちます。これは、今度は、より良い製品の開発につながります。」



多くの人がこのフレームワークを民主主義と比較しています。では、おそらくスクラムは、他のすべての人を除いて、開発管理の最悪の形態ですか？



あるいは、公式ガイドが言うように、理解しやすいが完全に習得するのが難しいフレームワークかもしれません。



この記事のタイトルにある質問にどのように答えますか？