チームでSCRUMを使用するよりも、より形式的で軽量なプロセスを使用する必要があるのはなぜですか？

SCRUMまたはその派生物は、おそらくソフトウェア開発を管理するための良い方法であることを理解していると言って、質問を始めたいと思います。すべての大企業と私のマネージャーがそれを使用している、または使用しているようであり、私はそのすべての経験について本当に議論することはできません。しかし、私は「理由」とすべての読書を理解するのに苦労しています。職場での公式のSCRUMトレーニングでさえ、私のために仕事をしていません。それはすべてレトリックです。そこで私は答えを求めてここに来ました。

これまで、私は4〜5人のメンバーからなるチームで非常に効果的かつ完全に自己組織化し、トレーニング、方法論、または特別なソフトウェアを必要とせずに開発してきました。キューブでのディスカッション、アドホックミーティング、1対1のコードレビューのみ。私は現在、SCRUMが進むべき道であり、それに付随するすべてのものであると言われている職場の立場にいます。彼らが私にSCRUMを説明するとき、私はこのようなものを読みます：

• プロセスとツールを介した個人と相互作用
• 包括的なドキュメントよりも機能するソフトウェア
• 契約交渉を介した顧客コラボレーション
• 計画に従うことによる変化への対応

それは素晴らしいことですが、それはすべて私にとって常識のように思えます。なぜこれが成文化される必要があったのですか？そして、私は方法論が変化への対応に役立つと言われています。どのような具体的なSCRUMの側面により、以前はアドホック会議、キューブディスカッション、および開発者計画会議で達成できなかったほど柔軟に対応できますか？彼らは、2週間ごとに作業成果物、またはスプリントを用意する必要性を説明しています。私の特定のプロジェクトでは、「クライアント」は存在せず、ソフトウェアは1年以上は完成しません。その間は、毎月またはそれ以下で上級管理職にデモを行うだけでしょう。では、なぜ隔週ごとに成果物が明示的に必要なのでしょうか？チーム全体が次のスプリントのストーリーとタスクをレイアウトするスプリント計画会議の重要性を強調しています。これは、私が過去に開催した即席の計画会議と同じです。なぜ隔週月曜日に発生しなければならないのか、そして、なぜチーム全体が関与しなければならないのですか？私はすべてのメンバーが製品を「所有する」という概念を理解していますが、実際には、各ストーリーをタスクに分割するのに実際に貢献できるのはごく少数の個人のみであり、他のメンバーはただ見過ごしています。

繰り返しますが、私は大多数の人々がこのプロセスの背後にいることを理解しています。理由を理解したいだけです。私の問題は、これらのことをすでに実践していて、それらを不必要に成文化することを好まないことですか？または、これらの手法が不適切に行われているため、これらの手法の利点をまだ見ていませんか？任意の実数この上、個人情報やアドバイスが、私が受信に使用しています熱弁は対照的に、非常に高く評価されるだろう。

あなたの質問に答えるには2つの側面があると思いますが、厳密に定義されたプロセスなしでほとんど仕事をすることができ、それでも製品を提供できるほど賢く有能であると思われる人々と一緒に働くことをお祝いすることから始めましょう。残念ながら、これはすべてのソフトウェアチームに当てはまるわけではないため、スクラムに関する問題の1つは、あなたと同僚が実際にプロセスをダンプして効率を上げる必要がないことかもしれません。あなたはすでに効果的かもしれません。

他のチームではなく、より厳密に定義されたプロセスと、物事を成し遂げるためのいくつかのガイドラインが必要です。これは、これらのチームの愚かさや能力の低さを意味するものではなく、チームとしての自己組織化や規律との連携に問題があるかもしれません。これは、人々がほとんど一人で仕事をする場所からチームとして一緒に働く場所に来るときの簡単な学習体験でもあります。スクラムは、理解して従うのに十分簡単であると同時に、チームにそれを開始するように圧力をかけるのに十分効果的ないくつかのガイドラインを提供するため、そこに到達するのに役立ちます。

スクラムはソフトウェア開発の実行方法について何も述べていないため、チームに自分で決定する自由も与えられます（例えば、スプリントの終わり）。

したがって、チームは1つの問題です。もう1つの問題は、管理と管理の信頼です。ここで、スクラムは透明であり、利害関係者が定義されたサイクルでチームの進捗を確認できるため、良いかもしれません。だから、「私たちは進歩を遂げているわけではありません。残念ながら、今のところ何も表示できませんが、私たちは時間通りに完了します」と信じています。これは本当のことかもしれませんが、実際に進捗が実際に起こっていることを確認できる定期的なデモを管理者が行うことは安心できます。

スクラムは特効薬ではありません。さまざまな理由で一部のチームでは機能しない場合があります。一部のチームでは自己組織化が機能しない場合があります。多分あなたにとってはそれは別の方法であり、すでに生産的で組織化されたチームに投げかけられたプロセスのようです。

疑わしい場合は、試してみてください。それが機能せず、チームの大部分がそのように機能することを好まない場合は、実行しないでください。ただし、2〜3か月（最初の数スプリントはとにかく扱いにくいため、詳細を調整する時間が必要なので2〜3か月間）確認し、再評価します。

議論の余地があるかもしれませんが、スクラムはアジャイルに対する経営者の不安を軽減するか、すでに成果の低いチームで使用するのに最適です。もしあなたのチームが成功し、目標を達成し、お金を稼ぎ、そして幸せなら、スクラムはあなたが何も買わないでしょう。なぜならあなたがする活動の良いバランスをひっくり返すだけだからです（そしてあなたのチームを成功させます）。スクラムは特効薬ではありません。私の経験では、見積もりとコミュニケーションがまずいチームにしか役立ちません。効果的なコミュニケーションの環境で現実的な見積もりを行うチームは、スクラムのプロセスオーバーヘッドによってのみ妨げられます。

信じられないかもしれませんが、スクラムが登場する前に優れたソフトウェアチームが存在していました。スクラムは、悪いものが良くなるのを助けます。

ここでの回答のほとんどは、少し間接的ですが、その理由をすでに列挙しています。アンの答えは、彼女が透明性に触れたときに特に光ります。つまり、マネージャーが何が起こっているかを見ることができます。そして、シュルツの答えは、人々が怠けているという事実を隠すことができないという話をしたときにも触れています。

だから、他の人がすでに言っていることをもっと直接的な言葉で言いたい。SCRUMの主な目標はソフトウェア開発を管理することではなく、SCRUMの主な目標はソフトウェア開発を測定することだ。

他のシステムは以前に試行し、人々はソフトウェア開発を試行および測定するために数え切れないほどのメトリックを提案しましたが、失敗しました。SCRUMは問題を解決し、測定の負担を管理者から開発者自身に移します。論理は単純です。自分で仕事をする人よりも、何かをするのにかかる時間を見積もる方がいいのでしょうか？

さて、これに関する問題は、プログラマーが楽観的すぎることで知られていることです。プログラマーに何かをするのにどれくらい時間がかかるかを尋ねると、彼は通常、タスクが実際にどれほど難しいかを過小評価します。SCRUMは、これを制御するツールを提供します。

• 毎日の会議で進捗状況を測定し、プロジェクトの全体像を把握します
• 推定は時間を取り除くために時間/日ではなく「ポイント」で行われます
• ポイントの速度を視覚化するバーンダウンチャートとトータス/ノウサギチャート
• ワークロードの全体像を把握するためのボード上のストーリーとタスク
• 進捗を測定できるように、締め切りとして機能するスプリントと反復
• 詐欺の誘惑を避けるためのスクラムマスター、オーナー、チームメンバーの特定の役割

等

上記のすべてが主に2つのことを行うことに気付くでしょう。

1. 彼らは仕事を測定します。実行する作業、実行中の作業、または完了した作業のいずれか。
2. 彼らは、より楽観的でより現実的な見積もりを得るために、過度に楽観的なプログラマーの問題を避けるために非常に一生懸命に努力しています。

SCRUMをより長く実装すればするほど、推定がより正確になります。実際、個人的には、スプリント+バックログ+バーンダウンチャートを実行するだけで、ほとんどのプログラマーが何かをするのにどれくらいの時間がかかるかについて悪い見積もりをするのに十分だと考えています。

個人的には、SCRUMの目的は、上級管理職がリーンなプロセスに遅れることができない、または遅れることのない古い組織を満足させることだと思います。SCRUMを多用する部門で約1年間、建築家（チキン）として働いています。私の以前の経歴は、シリコンバレーの新興企業で、そのほとんどは、よりリーンでアドホックで、非常に反復的な（場合によっては毎週または毎日のプッシュ）機能集中プロセスを使用していました。SCRUMは、少なくともプロセスの観点からはやり過ぎだと（少なくとも、開発者の観点からすると、ある意味でウォーターフォールよりも重い）実装されています。逸脱しているのは、製品所有者が実際にIT組織の要件アナリストにより近いということです。結果として、彼らはビジネスから来る情報を鈍らせ、さらに悪いことに、ビジネスを開発チームに責任を負わせないままにする傾向があります（これには、ユーザーストーリーの定期的な連続注入が必要です）。それにもかかわらず、私の将来のスタートアップでは、SCRUMを使用しません。おそらく管理が追加のオーバーヘッドを必要とする状況でのみ使用します。

私は純粋主義者の観点から話をしません。スクラムが言っていることといくらか似た方法でそれを実行できると思います。ただし、主なポイントは、ショーを実行する能力です。1か月間休暇を取るとどうなりますか？

スクラムは、あなたがやってきたことすべてを合理化し、それにいくつかの定義された側面を置くためのメカニズムであると考えています。あなたが不在の場合、他の誰かがそれを複製し、他のプロジェクトにも複製することができます。ただし、スクラムは特効薬ではありません。私はスクラムを使用し始めたばかりの人（多くの人が流行しているため）を見て、その本質を理解していないためにひどくbadられました。

PS：スクラムは、スプリントの長さを2週間にすることを義務付けていません。1か月（ケース）になる場合があります。

最初に質問に対する私のコメントをご覧ください。

SCRUMはアジャイルなソフトウェア開発パラダイムです。そのため、それ自体がアジャイルです。古典的なモデルに従う必要があるとは想定していません。そして、実際に誰かがそうするかどうかは疑問です。以前はいくつかの組織で働いていましたが、すべてのチームがニーズに合わせて調整していました。パブリック製品/ライブラリ/ APIのリリースに関しては、顧客/消費者がいないことは珍しくありません。持っていなかった。私の場合、私たちのGMは1つとして行動しましたが、IMOは何も持っていないようなものでした。

2週間のスプリントを持つのは難しいです。とても厳しい。3週間の方が優れていますが、プロセスチームに精通しており、熟知しているためです。4週間または1か月でした。これにより、最初から話すように「落ち着く」ための十分な時間が与えられ、テスト全体を通して、最後に自信を持てるようになりました。私はそれが好きで、少なくとも3週間は固執します。

私が協力していた他のチームには、バックログ以外はありませんでした。彼らは集まり、状況と次のことを報告し、それで終わりです。すべてが完了すると、彼らは別のバックログを思い付くでしょう。彼らはそれがスクラムではないことを知っていましたが、彼らにとってはうまくいきました。それが重要なことです。

軽量ですか？間違いなくそうです。しかし、それはスクラムではありません。私がSCRUMで気に入っているのは、規律を促進することです。人々は毎日何かを届けるというプレッシャーを感じています。誰もが他の人が何をするかを知っており、彼は失敗します。それを隠そうとしても（嘘を読んで）、他のプロセスよりもずっと早く明らかになります。そのため、そのチームのように分岐して簡素化するときは、適切な人員でそれを行う必要があります。さもなければ、解散して、すぐに意味のないステータスミーティングに落ちて、全員が滞在して「ここで何をするのか、どうすればいいのか知っている」と考えるだけです。

それは私の2セントです。開発のような自分のSCRUMを実行します。作業を計画し、タスクに分割し、それらを見積もり、進捗を観察します。物事の上にいることが本当に助けになります。アウトソーシングしたプロジェクトにSCRUMからいくつかのことを適用しましたが、うまくいきました。

ただ...敏stay性を保つ;-)

スクラムを無視することをお勧めします。数年後には新しい流行が起こり、あなたは冷笑的ではなくなり、それを心から受け入れることができます。実際、すぐにエキスパートになることができます。その後、本を書いて会議で話すことで、たくさんのお金を稼ぐことができます。

多くのことは周期的であるため、この新しい流行はRUPに似た重いプロセスである可能性が高いです。あなたが見るであろうことは、誰もが軽量のアジャイルプロセスに従っているということであり、これらはプロジェクトの失敗のせいにされます。したがって、当然のことながら、論理的なソリューションは、事前の計画と設計がさらに必要です。

でも真剣に、スクラムは必要ないと思う。スクラムには、他の競合するアジャイルプロセスよりも優れているものはありません。また、それは物事の多くの愚かな名前を持っています。

それは素晴らしいことですが、それはすべて私にとって常識のように思えます。なぜこれが成文化される必要があったのですか？

スクラムは通常、より古く、よりヘビーな方法論と比較されます。方法論は、より多くのドキュメント、より多くのサインオフ、およびより多くの計画を事前に実施することにより、フィードバックのないウォーターフォールを機能させようとしました。アジャイルマニフェスト（あなたが引用している）は、これらのアイデアの反転でした。

そして、私は方法論が変化への対応に役立つと言われています。SCRUMのどのような特定の側面により、以前はアドホック会議、キューブディスカッション、開発者計画会議で達成できなかったほど柔軟に対応できますか？

すでにアジャイルな構造を持っているようですね。すでに変化にうまく対応しているのであれば、明らかに助けは必要ありません。一部のプロセスは手順に非常に隠れているため、バグを修正するには完全な分析と機能設計フェーズが必要であり、早ければ来年までプロジェクトに参加できません。

彼らは、2週間ごと、またはスプリントごとに作業成果物を用意する必要があることを説明します。私の特定のプロジェクトでは、「クライアント」は存在せず、ソフトウェアは1年以上は完成しません。その間は、毎月またはそれ以下で上級管理職にデモするだけでしょう。では、なぜ隔週ごとに成果物が明示的に必要なのでしょうか？

オリジナルスクラムは、1か月間のスプリントを規定しています。スプリントの短縮には、アジャイルマチスモへの厄介な傾向があります。（「ええ、まあ私たちのスプリントはたった一日です...」）顧客/クライアントは、プロジェクトがうまくいくか、もっと仕事が必要だと言う権限を持っている人です。毎月上級管理職にデモを行っている場合、彼らはおそらくあなたの顧客であり、おそらくあなたはすでにスクラムに非常に近いでしょう。

あなたのチームが何をしているかの説明に基づいて、スクラムはおそらくそれほど違いはありません。スクラム用語を使用すると、何が起こっているかを部外者に説明する方が簡単になるため、標準化からいくらかの価値が得られるかもしれません。また、スクラムはシールドとして使用できます。たとえば、スクラムは、技術的な決定はチームが行う必要があることを規定しています。この原則を指摘することは、他の方法では販売するのが難しい技術的価値を得るための良い方法です（ペアプログラミングなど）。

スクラムは基本的に、チームが実装できるインターフェイスです。そうすれば、チーム外の人とコミュニケーションをとる方法について良い考えを持ち、彼らはあなたとコミュニケーションをとる方法について良い考えを持っています。チームがこれを必要とするかどうかを知ることができるのはあなただけです。

職場ではスクラムを使用していません。アジャイルとリーンで設立された多くの点で類似した方法論を使用します。このプロセスは、リードを含む3〜5人の規模のチームで使用しました。違いはありますが、スクラムがあなたの状況に役立つかどうかを理解するのに役立つと思います。

方法論を明らかにする

各スプリントの後処理/レビューでプロセスをレビューするため、プロセスを明確にします。まとめ/レビューの一部は、私たちにとって役に立たないプラクティスを特定することです。また、私たちにとって役立つと思われる慣行についても議論し、十分な合意があれば試してみます。方法論を体系化せずにこれを行うことはできません。

サインオフ

これが私たちのプロセスの主力です。これは、私たちが書くことが必要なものであることを保証します。特定の機能が得られたら、顧客に行きます。顧客はあなたが書いたものを使用する人です。場合によっては、顧客を代理する顧客（製品管理など）と顧客をプロキシする必要があります。これらは私たちの手順であり、最後の手順が完了するまで機能は実行されません。

• ボード、トラッカーなどから機能を取得します。
• 何かを書く前に、顧客と話をして、彼らが探しているものを理解します。
• 機能を実装します。
• 顧客に機能の機能を最終フォームで示す顧客に機能の完了をサインオフさせる。

垂直スライス

すべての開発は垂直スライスで行います。これにより、完成した機能やその他の理由でサインオフする機能がサポートされます。

• 統合の問題を各機能に組み込むことで償却します。プロジェクト終了時のクランチ時間をなくすのに役立ちます。
• 相互依存関係の多くを排除するため、機能を簡単に切り取ることができます。
• 方向を変える必要がある場合、開発を中断できます。
• 反復リリースを行い、顧客に早期に機能を提供できます。

受け入れTDD

ユニットテストフレームワークを活用して、tddを受け入れます。これには多くの利点があります。

• 大規模な再構築には、多くのテストの再作業時間がかかりません。
• お客様の機能を保証します。
• コードの統合について説明します。
• Vertical Slice開発プラクティスをサポートします。

ビルドは常にリリース可能です

プッシュするたびに、コードはリリース可能になります。機能が不完全であっても、何も壊れてはいけません。すべてのテストを実行し、以前のすべての機能が存在する必要があります。これは実際に私たちの垂直スライス開発の延長です。そのため、同じ利点の多くを共有しています。

• 相互依存関係の多くを排除するため、機能を簡単に切り取ることができます。
• 方向を変える必要がある場合、開発を中断できます。
• 反復リリースを行い、顧客に早期に機能を提供できます。

継続的インテグレーション

すべてのプッシュは、CIビルドサーバーを介してビルドを生成します。ビルドサーバーはコードをチェックアウトし、テストスイート全体を実行し、コードにタグを付け、展開用にパッケージ化します。ビルドは常にリリース可能であるというポリシーを強化します。

カードのポイント推定

すべてのバグ、機能、およびタスクは「カード」になります。カードは、顧客にとってメリットのある最小の論理的な作業単位です。規模に応じてこれらを指摘します。最大ポイント値を超えるか、さらに細分化されたもの。ポイント値が大きいほど、完了までの時間のずれが大きくなる可能性があるため、大きなカードをさらに分割します。カードに十分なあいまいさがある場合、スケールの次のポイント値に切り上げられます。各カードは、完全と見なされる前にサインオフする必要があります。適切な推定により、速度を計算する機能がサポートされます。

速度

1週間のスプリントがあります。毎週金曜日、作業計画を立て、来週の作業に優先順位を付けます。速度に基づいて、1週間以内にどれだけの「作業」を達成できるかがわかります。速度は、1週間以内に完了した合計ポイントの平均と中央値です。標準偏差の増加は、悪い評価（常に良くなるように努めています）、または中断の増加（私はマネージャーに話します）について分析されます。速度は、プロジェクトの正確な完了日を推定するためにも使用できますが、これは作業中の唯一のプロジェクトの場合のみです。

漸進的な改善と設計

また、コードを見つけたときよりも少なくとも少し良い状態のままにするポリシーがあります。カードの最初にあるコードをリファクタリング/再設計します。目標は、漸進的な開発で普及する可能性がある有機的な成長を説明することです。また、通常どおりに最後にリファクタリングします。

ほとんどの場合、これらは私たちが従う規則であり、私たちが従う理由です。

あなたは非常に経験豊富で高機能なチームにいるように思えます。おめでとう、スクラム/アジャイルは基本的に、チームがこれまでずっと直観してきたことを形式化しています。

あなたの（全体の）会社にとっての利点は、開発チームのメンバー間ではなく、開発チームとビジネス部門の間の「共通の基盤」としてスクラムを採用することだと思います。

スクラムスプリントはタイムボックス化されていますが、チームは2週間から1か月までの推奨事項を選択できます。それよりも少なく、レビューや回顧が多すぎると、1年以内に方向を変えるビジネスの能力が妨げられる可能性があります。1か月のスイートスポットを見つけたようですので、そのためにプッシュしてください。

スクラムのパラメーターを調整する余裕はたくさんありますが、まだスクラムを正しい方法で行っていることをビジネスに説明できると確信しています。利点の1つは、ビジネスの途中で会えば、彼らの関与が前向きなサポートをもたらす可能性があることです。