「メイン」機能のバックログと並行した「バイトサイズ」タスクのバックログ？

高度にサイロ化された「一匹狼」の開発部門構造で2年以上働いた後、アジャイルスクラムを採用しています。すごい。私はアジャイルが好きです。開発者として、無数の利害関係者が昨日プロジェクトを終えた後、プロジェクトをスローダウンすることなく、集中して忙しく生産的になります。

しかし、現在の「モデル」と対比してSCRUMに移行する側面が1つあり、開発部門以外の人は少しでも好きになれないと思います。それが、「待機中」に小さな変更を行う現在の能力です。私たちの開発の大部分は、社内での消費のみを目的としており、ほぼ全員が同じ建物内にいます。そのため、他の部門のリーダーまたはマネージャーが特定のアプリケーションの「コードベースの所有者」に来て、小さなものを要求することは長年にわたって一般的な慣習でした（それほど小さくはありませんが、これらの「ドライブバイ」に基づいた週プロジェクト）。私たちの上司でさえ、彼に持ち込まれたものをこのように中継することがあります。非常に頻繁に、その時点で問題のコードベースで作業している場合、ソースファイルをポップアップ表示するだけで、

基本的なアジャイルSCRUM方法論では、これらの調整は、欠陥（以前に消費したストーリーで指定された要件を満たしていない）または新しい小さなストーリー（記載されているすべての要件を満たしましたが、それらの要件は不完全、曖昧、または不正確でした） 、またはユーザーが新機能を見た後に配信後に変更されました）。どちらにしても、大半はないがほとんどゼロで、1-ポインタとなり、比較的低い優先度（システムは、現在の状態で使用可能ですが、それは次のようになりそうならば...ずっとクーラー）であることが、彼らがそうなって、バックログをトップダウンで操作するときにスプリントに持ち込まれます。

この可能性は、他の部門によるアジャイルプロセスへの積極的な反対の源として開発者会議で提起されました。これはIMOにとって有効な懸念事項です。POの背後にある利害関係者は、すべてが同じ視点を持っているわけではないため、最も重要なことについて常に同意するわけではありませんが、最終的な決定を下すのは通常マネージャーだけです。製品バックログに表示されます。

その後、暫定的に「キャンディジャー」と呼ばれる解決策が提案されました（別の用語は「グレービーボート」でした）。さまざまな部門の「リトルガイ」によって要求された小さな調整。既存のストーリーの欠陥ではなく、チーム内のコンセンサスまたは称賛により、開発者の1日の半分以下で済むと推定されます。エンドユーザーの意見では、ユーザーエクスペリエンスに対する即時の重要なプラスの影響が、プライマリバックログと並行してリストに追加されます。それらは「ストーリー」として識別されますが、優先順位付けの対象となる「大きな」ストーリーの主要なバックログとは別に保持されます。スプリントの通常の進行中にいつでも、これらの調整のいずれかを行うことができるシステムの領域で作業している場合、微調整を簡単にすることで、スプリントに微調整を加え、より大きなストーリーと一緒にコーディングできます。これをする大きなストーリーやその他のコミットされた作業の完了を危険にさらしてはなりません。POはこのリストにもアクセスでき、微調整を含む基本機能に触れる今後のユーザーストーリーに取り組んでいる場合、要件としてストーリーに組み込むことができます。その他。これにより、微調整がより早く実行される可能性が高くなると考えられていました。

これにより、スクラムマスターによる「ええと」のトレーニングが行われ、私たちの間に反応が生じました。バックログが1つあります。2つのバックログは、どの＃1アイテムが本当に最も重要であるか、どのリストのアイテムが実際の速度を決定するか、2つのバックログのうちどちらが実際に属するかという問題を紹介しますどちらか一方に勝手に）。「プロセスを機能させる」と私たちは言いました。変更がエンドユーザーにとって本当に重要な場合、彼らは部門長が時間/お金の決定を行うのに十分な騒ぎをし、バックログのトップに対する開発チームの意識にぶつかるでしょう。

私は床に質問を投げかけると思った：あなたの意見では、「一口サイズ」の物語の平行リストは、小さく、有用であるが最終的には優先度の低い変更をより速くすることに価値があるか、それとも全体的に良い決定ですか？それらをメインのバックログに組み込み、スプリントへの組み込みを基本プロセスで管理するにはどうすればよいですか？

うまくいけば、あなたがあなたの道を見つけるのを助けるいくつかのポイントについて話します：

1. 「SCRUM」はアジャイルであることについてです。常識が必要です。変更が数分の変更である場合、そのためのバックログは必要ないと思います。2時間を超える場合は、考え直すべきだと思います。「勝ちやすい」ものすべてを行うべきではありません。SCRUMでは、優先順位に従って作業します。POは、追加によって得られるものとそれにかかる労力に関する情報を取得する必要があると思います。その後、POはそれが重要かどうかを決定できます。SCRUMに移行すると、多くの質問が出てくることがあり、開発者はしばしば「しかし、それは数時間しかかかりません」と言うでしょう。だから何？数時間は時間であり、短いものすべてを含める必要はありません。
2. 私はかつて「エンジニアリングバックログ」があるプロジェクトで働いていました。このバックログには、製品を改善するために開発者が提案した項目が含まれていました。これらのアイテムには明示的なユーザー値はありませんでした（ただし、暗黙的なユーザー値はありました）。例：コード内のコンポーネントのリファクタリング。変更、努力、および利益について説明しました（この場合、ユーザーに何も提示することはできません。しかし、そのようなリファクタリングが新しい機能をより迅速に開発する場合、それは間違いなくユーザーにとっての利益です）。私たちのPOは、バージョン中に、各スプリントの10％（平均）をそのようなアイテムに投資することを決定しました。各スプリントの前に、POが今後のスプリントのバックログについて決定したときに、彼は10％のエンジンバックログアイテムがあることを確認しました。したがって、2つのバージョンバックログ-> 1つのスプリントバックログ。
3. バッファー -SCRUMで働き始めたとき、ソフトウェアエンジニアとして不確実性の世界にいることを人々はしばしば忘れます。たとえば、1日の仕事を8時間ではなく6時間と数えることもできます。たとえば、15日間のスプリントがあるとしましょう。つまり、会議に時間がかかり、時間がかかりすぎたものに30時間余分にかかるとします。覚えるには小さすぎるが、2日目の仕事の一部であるもの。
4. 集中し続ける-最後になりましたが、SCRUMでは集中し続けることが重要です。そのようなタスクに投資するための総労力と優先順位を決定し、この時間と労力を忘れずに投資してください。「ささいなこと」が小さいからという理由だけで作業するために漂流しないでください。決定を支援するPOがあり、常識があります。
5. アジャイルにとどまる -そして、最後に、問題にアプローチするためのさまざまな方法を試してみることを忘れないでください。途中で改善します。

幸運を ：）

AgileやSCRUMなどのプログラミングフレームワークは、開発に規律と構造を適用するように設計されています。しかし、規律と構造は楽しさと創造性の反意語のようです。通常、規律を確立し、維持するために一生懸命働く必要があります。これらの対立する概念のバランスを見つけることは非常に困難です。したがって、フレームワークはこのトピックを避ける傾向があります。

私の最後のプロジェクトで、開発者は頭をリフレッシュしたりクリアしたりするのに毎日少し時間が必要であることがわかりました。彼らは、内で何でもできる予算内の時間（0.5時間/週）を与えられました理由（職場で何かに適用される可能性がある）。物事をしつけておくために、彼らは自分たちの活動を文書化するように求められたので、成果などの功績が認められるようになりました。

ところで、私たちは私たちのプロジェクトを「プロジェクトのクールさ」と呼び、その会社の多くの良いアイデアと改善の源になりました。

メインのバックログに小さなストーリーを残しておく必要があります。

私はスクラムを使用していませんが、あなたが説明しているものと同様の問題に直面しています。優先順位付けと効率の課題に直面しているようです。

あなたの「古い方法」の下では、開発者のオフィスを訪れた人は誰でも暗黙のうちに自分のタスクを現在の「最優先事項」にする権限を与えられているようです。これにはいくつかの利点があります。リクエスターは、彼らが応答されているように感じ、リクエスターと開発者の両方が「迅速な勝利」を得る。

欠点は、これらのタスクを頻繁に挿入すると、製品所有者と合意した最優先タスクが遅くなったり、脱線したりする傾向があることです。（サイドノート、多くの場合、誰もがこれらの「迅速な」修正に必要な時間を過小評価しています。）

私の経験では、優先度の低いタスクを絞り込もうとすると、優先順位付けの利点が損なわれます。開発者として、優先順位付けは、製品所有者が私に働きかけたいと思っていることに取り組んでいるということを証明します。プロダクトオーナーは、「持っておくべき」リクエストで折り畳みの余分な作業とリスク（わずかですが）を引き受けるかどうかを決定する必要があります。

多くの場合、利害関係者に優先順位を付けるように頼むと、「これを絞るだけでいいですか？」と尋ねられます。暗黙の希望は、現在の最高の優先順位に影響を与えることなく、新しいタスクを魔法のように完了することです。

私によく起こることは、利害関係者がLargeImportantProjectとSmallLessImportantTaskを要求することです。ジレンマは、SmallLessImportantTaskがLargeImportantProjectが完了するのを待つ（またはロードブロッキングがある）ことですか？トレードオフがあり、私の経験では、製品の所有者が決定する必要がありました。（製品の所有者が決定しない場合、開発チームは推測する必要があります。）

スクラム（およびプロジェクト管理全般）の1つの目標は、最も優先度の高いタスクの障害を回避することです。あなたがより効率的になると、余分な「素敵な」仕事を絞る余地が少なくなります。

効率は恐ろしい場合がありますが、2つの重要な方法でコストを上回るメリットを目にしました。

1. 効率が上がると、チームの能力を高めて、価値のある作業を完了できます。これには、「必要な」要求が含まれます。
2. リクエストが本当に「必要なもの」である場合、より重要なビジネス上の優先事項が対処されるまでリクエストが待機することはおそらく完全に合法です。

私の考えでは; 問題は、バックログでタスクが優先される方法です。たとえば、「優先度」では、重要度と完了までの時間の両方を考慮することができます。それほど重要ではないが、10分で完了することができるものは、実装に数週間かかるより重要なものよりも高い優先度を持つことができます。

私は今しばらくアジャイルで働いています。私が言えるのはこれだけです-方法論とそれに組み込まれているすべてを主張することが絶対に間違っている状況があります。敏AG性が必要です。特定の状況に合わせて方法論を調整することは、IMOの必須事項です。

上記のAviと同じように、「SCRUM」とはアジャイルであることです。常識が必要です。変更が数分の変更である場合、そのためのバックログは必要ないと思います。

変更に時間がかかる場合、それはそれほど「無害」ではないことを意味し、十分に文書化する必要があります。

あなたの最初の質問とその後の説明に基づいて、これは私があなたの痛み点が

• 絶えず変化する要件
• 開発者がアプリケーションの他の領域に集中できない、つまり 私たちはアプリケーションのある部分のヒーローですが、他の部分には触れません。
• 採用されているアーキテクチャ、ソリューション、フレームワークへのさまざまなアプローチ
• 要件収集プロセスが機能していないようです

スクラムは、最初に正しく順守された場合、これらの問題の多くを修正し、さらに重要なこととして、解決すべき他の問題を前面に出します。

-絶えず変化する要件

すべてが正しく供給され、適切に優先順位付けされる単一のバックログがあることは、開発の最中にチームが要件変更の矢面に耐えてはならないことを意味するはずです。非常に動的な環境の場合、1週間または2週間の短いスプリントで、優先順位の変更を比較的短時間で容易に行えるようにする必要があります。

-開発者がアプリケーションの他の領域に集中できない、つまり 私たちはアプリケーションのある部分のヒーローですが、他の部分には触れません。

スクラムチームは、チーム内で知識を共有し、アプリケーションの他の部分で作業するという課題を探している特定の意欲を持って、協力して互いにサポートし、アプリケーションの知識が共有されるようにします。ペアプログラミングのようないくつかのプラクティスは、人々が慣れていないコードで作業するという恐怖を克服し、その知識を学び共有するのに役立ちます。これは、アプリケーションの知識がチーム間で配布され、人々がアプリケーションの任意の領域で快適に作業する前に、数回のスプリントが必要になる場合があります。また、人々がボードのタスクを引き出せるようにする、つまり、自分が働きたいことを自分で選択できるようにすることで、これを促進できます。

-採用されているアーキテクチャ、ソリューション、フレームワークへのさまざまなアプローチ

スクラムはコミュニケーションを促進し、チームワークと意思決定を促進し、さらに何が起こっているかをより明確に可視化します。これは、フレームワーク、アーキテクチャソリューションなどの使用に関する組織の決定を容易にし、スクラムオブスクラムメカニズムの使用は、組織全体にそれを浸透させるのに役立ちます。

-要件収集プロセス

繰り返しますが、規則を厳密に遵守している場合、要件が指定された要件をクリアしておらず、チームが要件を満たすために必要なものを理解して見積もることができる場合は、スプリントに持ち込むべきではありません。優先度が高く、明確に定義されている別の要件を考えてみてください。そうすれば、それを実現できることがわかるでしょう。要件収集プロセスをすぐに修正することはできませんが、そのプロセスを修正するために必要な変更を強制します。

最初の質問に答えるために、いいえ、2つの別個のバックログがあってはなりません。開発者と組織が最も優先度の高いアイテムに最初に取り組んでいるのは、いつでも誰にとっても最高の利益です。優先順位は、主にビジネス価値に基づいている必要があり、小さな調整やリクエストの多くがビジネス価値を高める可能性が非常に高いです。製品の所有者にそれを決めさせてください。

私は7年以上にわたってスクラムマスターであり、さまざまなチームや企業へのスクラムの導入を支援してきました。私の謙虚な意見と私の観察から、スクラムが初めて組織に導入された場合、本に従ってください。逸脱しないでください。スクラムは、慣行とプロセスに固執できる規律を必要とします。特定の状況に合わせて例外を作成するのは簡単すぎ、早すぎると、それがもたらす利益と価値の低下につながります。基本をやる、本当に上手くやる。基本を実行し、それらが存在する理由を理解する専門家になり、組織内でより適切に対応し、継続的な改善を推進するためにプロセスを変更します。

これが「アジャイル」であると言う非常に有効なケースがありますので、プロセスを変更する必要がありますが、プロセスを理解し、変更を議論する自主的で自己組織的なチームには大きな違いがありますアジャイルやスクラムの道を歩き始めたばかりのチームとは対照的に、プロセス。クロールする前に実行しようとしているようなものです...