薄いスクラムは優れたアジャイルよりも優れています

ボレーは50人の将校と760人の私人を刈り取りました。 フランス人は震え、てて逃げた。 「ここで私たちの物事はうまくいきませんでした。」フランスの公式派遣はこの戦いの瞬間を説明しています。

ケリーJ.火薬。 錬金術から大砲まで。



スクラムチームの編成には、常に多くの困難が伴います。 ほとんどすべての人が、ワークフローの順序を変更し、必要なスクラムイベントの一部を実行し始めます。 しかし、少数派はこれらの正式な変更から目に見える利益を得て、実際に作業プロセスを変更し始めています。 その結果、チームはスクラムについて次のような意見を持っています。「 集会に時間を浪費しています。 スクラムが機能しません。 何かを変更する必要があります 。」



どういうわけか状況を救おうとするスクラム活動家は、スクラムもフレームワークであることを思い出します。 新しい戦略が発表されました。「 私たちはスクラムだけでなく、アジャイルでもあります！ 私たちはベストプラクティスを使用します。スクラムからは最高のもののみを使用します 。これは私たちの状況に特に適しており、他のすべては不要でオプションです 。 そして、もしそうなら-「 私たちはよくやったし、すべてを正しくやっている 」。









残念ながら、そのような「スクラム救助」は行き止まりです。 簡単な道を歩み、複雑なスクラム要素を取り除き、問題を個別に検索して解決しようとせず、偶然出てきた記事からトリックをコピーして、何らかのプロセスを構築できます。 しかし、スクラムではありません。 スクラムガイド、エンドノート：「 スクラムの役割、アーティファクト、イベント、およびルールは不変であり、スクラムの一部のみを実装することは可能ですが、結果はスクラムではありません 」



スクラムは実際にはフレームワークですが、開発という言葉が通常理解されるという意味ではありません。 スクラムは、フレームワーク、基盤、ワークフローの基礎です。 すべてのスクラム要素は、互いに補完し、サポートするように設計されています。 ただし、それらは複製されません。 スクラムには安全域がありません。 したがって、Scrum Guideに記載されているものはすべて実装に必須であり、Scrumから何もスローすることはできません。 しかし、拡張することは可能であり、必要です。



スクラムガイドはワークフローを一般的な用語で定義します。各チームには独自の詳細があり、万人向けの普遍的な必須ソリューションは存在せず、存在できないからです。 各チームは、スクラム作業を具体的に整理するための最良の方法を見つける必要があります。 分散型のチームは、Skypeを介してデイリーを実行できます。また、1か所で作業している場合は、太陽が常に降り、雨が降っていない場合は、作業室に集まったり、会議室や通りに行くことができます。



会社レベルでのスクラム値の採用を条件として、スクラムはどのチームにも完全に実装できます。 スクラムの作業を開始すると、チームは大きな進歩を遂げることが保証されます。



Scrum：The Art of Doing the Twice the Work in Half Timeで 、Scrum Jeff Sutherlandはチームワークのリターンを2倍にすることを約束します。 実際、もし彼が誇張していれば、それほど多くはありません。 おそらく、あなたはすぐに大きな改善を期待すべきではありません。 私たちは知性のある人であり、ごくわずかなシステム化でさえすぐに壮大な結果をもたらすような嘆かわしい状態になることはめったにありません。 しかし、進歩は起こり、改善の規模は肉眼で見えるようになります。 そして、それはすべて、以前は静かだった開発者が作業の干渉について話し始めるという事実と、彼らが彼らの意見に耳を傾け始めるという事実から始まります。



実践では、最も困難なことは、既に「スクラムの作業」を開始しているチームにスクラムを確立することですが、実際にはプロセスをランダムに構築することが示されています。



偏見、失敗したテクニック、スクラムの一般的な仕組みに対する不十分な理解に基づいて、チームは行き詰まりに陥ります。 しかし、この状況でさえ絶望的ではありません。 そのようなチームからのいくつかの助けが必要になる可能性が高いですが。 チームは、何を正しく行っているのか、どこで間違っているのか、何が欠けているのかを把握できます。 しかし、最初にそのようなミスを避けたチームよりも時間がかかります。



スクラムには多くのエラーや誤解がありますが、いくつかは非常に一般的であるため、批判なしに誰もが受け入れ、 カーゴカルトになり始めます。 自分でトラブルに巻き込まれないように、それらのいくつかを整理する価値があります。

スクラム：バグに取り組む

チームについて



あなたはしばしば次のことを聞くことができます：



「 スクラムチームは開発者のみで構成され、各開発者は必要なすべての作業を実行できる必要があります。 これらはどこで入手できますか？ デザイナー、開発者、レイアウトデザイナー、テスターのみがいます。 その場合、スクラムチームは引き続き失敗し、以前と同じように作業します。



しかし、実際には、スクラムガイドは次のように述べています。「 開発チームは機能横断的であり、製品の増分を作成するのに必要なチームとしてのスキルをすべて備えています 」 はい、チームは普遍的でなければなりませんが、一般的には普遍的でなければなりません。 JavaScriptの開発者、QA、およびデザイナーが開発をリリースする必要がある場合は、全員がチームに所属する必要があります。 それ以外の場合、「カートは移動しません。」



同時に、チームは作業の結果に対して完全に責任を負います。 スクラムガイド：「 個々の開発チームメンバーは、専門的なスキルと重点分野を持っている場合がありますが、説明責任は開発チーム全体に属します。」 これらは空の言葉ではありません。 デザイナーのイノケンティが優れたデザインを描いたが、チームがそれを実装して解き放つことができなかった場合、これはチーム全体、特にチームの各メンバーの失敗です。 イノセントは、JavaScriptとQAの動作が遅いと非難する代わりに、次の時点でチームが結果を達成できるように、自分の作品の何かを変更できるかもしれないと考えるべきです。



さらに、すべてのスクラムチームメンバーには、開発者という1つのポジションがあります。 スクラムガイド：「 スクラムは、開発者以外の開発チームメンバーのタイトルを認識しません。その人が行っている作業に関係なく、 このルールには例外はありません 」。



まず、これはチームの生産性を向上させるための鍵です。 たとえば、Innokentyは設計に特化しており、この種の作業で最も効果的であるという事実にもかかわらず、この特定の開発段階が現時点でボトルネックになっている場合、テストでチームを支援することができます。 詳細については、エリヤフゴールドラットの著書The Goal（原文のThe Goal）を参照してください。



第二に、すべてのチームメンバーがすべての問題を対等な立場で議論できるようにします。 アイデア、評価、問題-誰もが自分の意見を表明する権利を持っています。 たとえば、イノセントには、赤の背景にあるフォントの赤の色は見栄えの悪いソリューションであるというタチアナの発言を無視する権利がありません。 タチアナはテストに特化しており、問題を見て、発言する権利があります。彼女はQAであるため、聞くことを拒否することはできません。 開発チームでは誰もが平等であり、これは本当に重要です。 このアプローチはスクラムに固有のものではありません;この原則の重要性についての詳細は、ジェフリーロスフェーダーの「 ドライビングホンダ 」にあります。



成功するスクラムチームの基盤を形成するのは、相互支援と相互尊重です。



レビューについて



「 ユーザーをデモに招待する必要があり、Webアプリケーションを構築しており、ユーザーはどこか遠くにいます。 たぶん、日当たりの良いカリフォルニアでは、スクラムチームはユーザーをデモに招待できますが、霜、熊、入れ子人形の国ではありません 。



スクラムにはデモがありません。 それにもかかわらず、これは多くの人が正確にデモを実行することを妨げません。 たとえば、プロジェクタを備えた1つの部屋でワークアウトする200人を集め、デモンストレーションで5時間互いに苦しめます。 エンタープライズ。 エピック。 無駄です。



スクラムにはレビューがあります。 そして、レビューは、行われた作業、達成された結果、および利害関係者との将来の計画に関する議論を意味します。 コミュニケーションとフィードバックはレビューの重要な要素です。レビューに招待された人は全員、チームや他の利害関係者と意見を交わし、意見を述べる機会を持つべきです。 したがって、レビューへの招待者の数を制限する必要があります。そうしないと、通常の議論は不可能になります。 最も価値のある人々をレビューに招待することは、プロダクトオーナーの責任です。 スクラムガイド：「 参加者には、スクラムチームとプロダクトオーナーから招待された主要な利害関係者が含まれます。」



利害関係者には、事業主や顧客だけでなく、チームに作業結果の定性的評価を提供でき、全体的な成功に関心がある会社の他の従業員も含まれます。 テクニカルサポート、アナリスト、開発専門家、部門長、他のチームの製品所有者、および他の従業員の代表者は、それぞれの役職や活動の種類に関係なく使用できます。 何らかの理由で彼らの意見がチームにとって価値があることが重要です。 最後に、はい、エンドユーザー、それが理にかなっている場合。



レビューの詳細については、Kenneth Rubinの著書「 Scrum Basics 」を参照してください。



回顧について



「 私たちは数回、回顧展を実施しようとしましたが、話すことはあまりありませんでした。 一般に、私たちのチームには問題はないので、これは余分な集会であり、時間の無駄です。 数時間余分に働きましょう 。」



回顧が必要です。 チームの作業の問題を​​見つけて修正することを学ぶことによってのみ、チームの生産性を高めることができます。 良い回顧展を実施することを学ぶことは非常に困難です。 本は役に立ちません。 実践的な経験が必要です。



チームには、チームに内部から回顧を行うことを教える強力なスクラムマスター、または外部からチームを支援できる経験豊富なマネージャーの誰かが必要です。



横から作業する場合は、チームを適切な方向に向けるだけで、既成のソリューションを提供するのではなく、非常に注意する必要があります。 そうしないと、チームは決して独立せず、「後見」を取り除いた後、すぐに元の場所に戻ります。 さらに、チームは、到着した意思決定を常によく理解し、外部からの意思決定よりも速く、より効率的にそれらを実装しています。



レビュープロセスの改善において最初の成功を達成した後、努力を倍増しなければなりません。 現在問題がないように見える場合、これはすべてが非常に悪いことの明確な兆候です。 常に問題があります。 回顧は改善の継続的で無限のプロセスであるカイゼンです。



スクラムマスターについて



「 すべてのチームのスクラムマスターは無駄です。 そして、それらをどこで入手できますか？ 私たちは空席を開き、半年間、私たちは1人だけを雇いましたが、それはほとんど経験がありませんでした。 彼にとって特別なことは何もありません。四半期ごとにレビューを実施します。チームの毎日のスタンドアップは組織化されており、通常は問題ありません。 もちろん、彼はxBoxを使って部屋で過ごす時間が長すぎますが、プロジェクトパートナーは彼に満足しています。上級開発者が月末にチームレポートを計画および収集するのを手伝っていると言います。 一般に、1つで十分であり、空室を閉じることができますが、これを探すのは無意味です 。



実際、スクラムマスター、特に良いマスターを雇うことはほとんど不可能です-悪いマスターを雇うのは誰ですか？ しかし、これは必要ありません。 チームでこの役割を果たせる開発者を見つけることが重要です。 彼にそのような機会を与えるために、彼が現在行っている負荷のかなりの部分を彼から取り除いた。 そして最も重要なことは、学習を開始することです。



はい、スクラムマスターを学ぶ必要があります。 この役割を果たすには、それ自体では現れないスキルが必要です。 「マスター」をトレーニングに送ることができます。これは難しくありませんが、結果は控えめです。 さまざまなチームの「マスター」をトレーニングして、定期的に会議を開催し、直面している問題と見つけた解決策について話し合うことがより重要です。 「マスター」が興味のあるトピックに関する社内スクラムセミナーを準備し、実施し始める場合にも役立ちます。



スクラムウィザードは、 スクラムガイドで多くの有用なものを見つけることができます。



仕事の調整について



「 スクラムは、小さな、独立した、独立したチーム専用です。 また、30人の開発者がいますが、1つのアプリケーションを開発するテスターは数えていません。 私たちは共通のコードと共通のベースを使用し、どのような独立性がありますか。 相互作用する必要がある6つのチームに分けましたが、スクラムはこれを意味するものではありません。 したがって、生産性の向上は待つ価値がありません。 少なくとも、プロダクトマネージャーは特定の開発者ごとに交渉する必要がなくなりました 。」



はい、共通の製品に取り組んでいる複数のスクラムチームの共同作業が定期的に必要であり、これは正常です。



スクラムには、デモがないように、プロダクトマネージャーも他のマネージャーもいません。 ただし、開発はスクラム内で調整できます。



複雑な技術的努力を必要としない製品の変更は、製品所有者チーム間で簡単に合意し、高い優先度で計画できます。



複雑な技術的作業、アプリケーションアーキテクチャの整合性の確保、「自転車の建設」の回避は、アプリケーションの技術専門家のレビューと計画への定期的な招待によって確保されます。 スクラムガイド：「 開発チームは、技術的またはドメインアドバイスを提供するために、[スプリントプランニング]に参加する他の人を招待することもできます 。」 このために、会社はチーム外のアプリケーションアーキテクトの専用の役割を持っているか、特定のチームで働いているが製品開発の問題全体で積極的に相互作用する経験豊富で資格のある開発者である場合があります。



計画とDoDについて



「 チーム全体の計画はナンセンスです。 時間の無駄。 前回、デザイナーは1時間交渉しました。ボタンの色は何色で、それを聞いていますか？ 1日を計画し、タスクの半分しか完了していません。この時間を仕事に費やした方が良いでしょう。 一般的に、2週間の作業を計画するのは無意味です。明日、緊急に修正する必要があるバグがあり、計画全体がバラバラになるからです。 また、スプリント計画は変更できないため、重要ではないバグは一切修正しません。 DoD？ これは何ですか 」



スクラムチーム全体が本当に計画に関与する必要があります。 これは重要です。 このようにして、プロセス中に「破損した電話」をプレイしないように、全員がスプリントでチームが何をどのように行うかを確実に知ることができます。 また、すべての観点からすべてのコメントをすぐに考慮することができます。



ただし、チームは、計画に割り当てられた時間を使用して、問題を議論するために必要な構成でさまざまなタスクを有用に並行して実行することを学ぶ必要があります。



計画中のチームの完全な構成は、評価前のバックログの初期分析中、スプリントの目標を形成し、それを達成するためのアクションプランを作成する際に必要です。



スプリントの目的とスプリントで実行されるタスクのリストは、しばしば混同されます。 「私たちの目標は、スプリントで行われたすべてのタスクを実行することです」という文言まで。 これは間違いです。



目標は、今後の作業から予想される品質結果を決定する必要があり、そのような目標は1つでなければなりません。 スプリント中に目標を変更しないでください。 スクラムガイド：「 スプリントゴールを危険にさらすような変更は行われていません 。」 目標を設定することにより、チームは実装するものとその方法を選択する戦術的な自由を得ることができますが、これは多くの場合非常に重要です。 スクラムガイド：「 Sprint Goalは、開発チームにSprint内に実装された機能に関する柔軟性を与えます。」 これは、リソースが不足している場合に価値の低いタスクの実装を放棄する機会であるだけでなく、良いアイデアや機会があればより多くのことを行う機会でもあります。



スプリントで計画されている作業のリストが変更される可能性があります。 スクラムガイド：「 学習範囲が明確になり、製品オーナーと開発チームの間で詳細が学ばれるように再交渉される 場合があります」 スプリント内のスプリントバックログの 。 " スプリントの変更は正常で予想されるものです。 チームが元の計画に従ってスプリント全体を変更することなくスプリント全体を実行する場合、それは疑いなく反対です。



多くの場合、チームは「完了」（DoD）の定義（完了した作業の基準）を「忘れ」ます。 それは当然のことであり、行われた手段が行われたように思われるが、ここでは理解できない。



完了した作業に関する明確で共有された基準がないと、チームは常に計画を逃します。 残っているものは何ですか？ 抗議とリリース...”



また、実行された作業の基準は、スプリントの結果を分析するために重要です。作業を完了するために何が行われなかったかを正確に理解することは、回顧の優れたトピックを提供し、そのような問題を解決するための特定の手順を策定することができます。



スクラムは、このテーマに関する無駄のない生産から多くを借りています。



ここでの固定スプリント持続時間は、ビート時間に対応しています。 計画プロセスでは、スプリントで何をすべきかをチームに伝えるのではなく、プロダクトオーナーがチームができる範囲でジョブを選択する可能なオプションを提供する場合、プルシステムを実装します。



DoDコンセプトは、スプリントの終わりまでに開始されたすべての作業を最後まで完了する必要があるため、リーンで区別される損失の最大のタイプである進行中の作業の損失を排除します。 スクラムガイド：「 スプリントの最後に、新しい増分を完了しなければなりません 。」



これらの技術はすべて連携して、チームの生産性を向上させるだけでなく、より価値のある作業に焦点を合わせ、優先順位をすばやく変更します。



Jeffrey Likerの本Tao Toyotaで生産とリーン製造の損失の種類について詳しく読むことができ、Sutherlandの本Scrumの章全体を読むことができます。 上記の革新的なプロジェクト管理方法 」。 ユーザーストーリーに基づくストーリーテリングテクニックの1つは、 スクラムベーシックの Kenneth Rubinによって十分に開示されています。



スクラムポーカーについて



「 スクラムポーカーは役に立ちません。 開発者はタスクに潜む2時間を費やし、何らかの評価を行います。 そして、結果は何ですか？ スプリントで実際の2倍のタスクを実行するたびに 。」



スクラムポーカーのアイデアは非常に広く普及しているため、多くの人はスクラムポーカーはスクラムの不可欠な部分であり、スクラムなしでは行き先がないと考えています。 そうではありません。 スクラムポーカーは、スクラムボードを使用したり、 ユーザーストーリーの形で作業をスケジュールしたりするのと同じように、独自の長所と短所を持つテクニックの1つにすぎません。



スクラムポーカーが機能する場合-まあ。 チームが定期的に「ポーカー」を使用したスプリントの推定に大きな間違いを犯した場合、この特定の方法はこのチームには適していません。



お金のためにプレイし始める価値があるかもしれません。 そしておそらく、個人的な開発者の評価は平均よりもうまく機能するでしょう。



実践では、タスクが十分に分解されていれば、評価に大きな困難はないことが示されています。 最終的に、スプリントで選択されたすべてのタスクの合計スコアがチームができることと一致することが重要であり、個々のタスクが何らかのエラーで評価されるという事実は本当に重要ではありません。



スクラム全般について



「 スクラムは、理想的な温室条件でのみ機能する純粋に理論的なアプローチであり、実際のスクラムは適用できません。 一般に、スクラムは昨日でしたが、今ではすべてをアジャイルで行う必要があります！ 」



見ると、スクラムはそれほど怖くありません。 また、有能で高品質の実装には非常に手頃な価格です。



スクラムとアジャイルを混同しないでください。これらの概念は代替ではなく、反対したり、互いに置き換えたりしないでください。



概して、アジャイルは確かに合理的ですが、本格的なワークフローを構築するには不十分な一連の戦術です。 アジャイルプロセスには多くのオプションがありますが、それらの中に良いものは多くありません。



スクラムは、実用的な価値を証明した原則と戦術に基づいて考え抜かれたワークフローです。 ところで、スクラムはアジャイルの前に登場し、スクラムの作者はアジャイルマニフェストに関与しています。



はい、スクラムは簡単に提供されます。



C'est la vie。



- ドミトリー・マモノフ



開発部

マスターのマージ部門、

gitの作業部門、

シニアBashコンソールオペレーター