発券されていない仕事、どれくらい多すぎますか？
私たちは、バックログとそのバックログの優先順位付けを担当する製品所有者とスクラムチームで作業します。最近、発券されていない作業のトピックが浮上しました。アプリケーションの1つの開発者は、重要だと考える発券されていない作業を行っています。通常、これは技術的な負債ですが、より優れたライブラリへの移行などの場合もあります。
開発者からの議論は、これらは一般的に小さなものであり、アジャイルチームでは、彼らは自分の判断を行使してスプリント作業にそれらを合わせることができるはずであるということでした。例えば。 CIシステムが構築およびデプロイされるのを待っている場合、コードを整理することができます。チケットを上げる作業は、実際に作業を行うよりも時間がかかります。実行中の作業は自動テストによってテストされるため、チームのQAメンバーに追加の負担はありません。
これに対する議論は、開発者はどの作業が優先事項であるかについての意見を他の利害関係者よりも重要であり、POを通過しないためバックログの他の作業と比較できるということです。また、開発者に時間があれば、次のストーリーを詳しく説明するほうが生産的である場合もあります。スプリントに登場するストーリーの状態は以前にレトロで提起されていたため、より詳細な説明はこれを助けることができるだけです。また、このサイズに該当するサイズのセルフポリシングが伸び始め、未発券の作業により多くの時間が費やされる可能性があるという懸念もあります。
私は議論の両側をある程度見ることができますが、チケットがどれだけ小さくてもスプリント計画を実行する必要があります。
技術的負債を返済することに価値のない会社で働いているなら、あなたはチケットのない仕事をするしかありません。
利害関係者は通常、この種の作業について意思決定する資格がありません。
チケット見積もりプロセスの一部として、発券されていない作業を含めます。
いくつかの安全が重要な業界では、製品に組み込まれるすべてのコードに対して承認が必要です。ほとんどの人はそのような状況にありません、そしてそうである人々はその状態を受け入れます。
通常の状況では、チケットのない作業を許可しない場合、基本的にはエンジニア、特に上級エンジニアの経験を無駄にしています。彼らは顧客体験を向上させることについては知っていますが、顧客が求めることを決して知らないでしょう。彼らは提案された解決策よりも優れているあなたの述べられた目標を達成する方法を知っています。彼らは、開発者のエクスペリエンスを改善し、開発者の生産性と満足度を高め、間接的に顧客の要求をドアから迅速に排除することについて知っています。逆に、彼らは顧客を怒らせる可能性があることを知っており、十分な寛容度が与えられれば、問題が発生する前にそれを防ぐことができます。
開発者にその仕事の説明責任をどのように維持しますか？ tellingすべてについて製品の所有者（最初に常に質問するわけではない場合でも）。これにより、時間をかけすぎた場合に、製品の所有者が優先的に電話をかけることができます。私たちのPOはすべてのスタンドアップに参加するので、彼が1日以上、通常は半日以下で、私たちが取り組んでいる未発券のアイテムを知らずに行くことはありません。何かが2時間以上かかると思われる場合は、最初に製品の所有者が実行します。
これが効率的である理由の1つは、決定に関与する人が多いほど、時間がかかるためです。開発者は1時間で何かを行うことができます。あるいは、説明、分析、および優先順位付けに数十時間かかる可能性のあるチケットを作成することができます。監視があり、ビジネスの優先順位を押しのけない限り、実際にお金を節約しています。
どれほど小さなチケットが発行され、スプリントプランニングが行われるかは関係なく、すべての場合、開発者がいつ行うかではなく、小さい場合に実行する必要がありますか？
確かに答えがノーであるポイントがありますよね？ IDEを開くためのチケットを追加したり、チェックイン前にコードをフォーマットしたり、他の人のコードをコードレビューしたりすることは意味がありません。これらの小さなことはすべて既存のチケットの一部であると主張することもできますが、作業しているものに関連するテクノロジーの負債を片付けることも同様です。
人々が忘れる最大のことは、プロセスがあなたに提供するためにそこにあるということです、その逆ではありません。
チケットを作成することのコスト（可視性、一貫性など）がコスト（作成するまでの時間、コンテキストの切り替え、バックログへのノイズ、他に何もしないことの機会コスト）よりも価値がある場合は、それを実行します。これらの優先順位付けがコストよりも価値がある場合は、それを実行します。
少し区別してみましょう。チケットのない作業にはさまざまなタイプがあります。
プロジェクトとはまったく無関係なことをする。別のチーム、管理者、管理会議の誰かを助ける
特定の仕事によって暗示される。例えば。誰もセキュリティについて言及していませんが、仕様をせがむのではなく、デフォルトを追加しているだけです
金メッキ。例えば。もちろん、これらのボタンのアニメーションが必要です！
CV主導の開発。例えば。 $ {最新のもの}にリファクタリングしました！いずれ良くなるだろう
シャドウIT。たとえば、私はDB管理者のデファクトであるため、自分の仕事ではありませんが、XのDBバックアップを実行しました。
明らかに、チケットなしで人々にしてもらいたい人もいれば、そうしない人もいます。
理想的には、すべての開発者の時間を考慮し、プロジェクトに焦点を当てたいが、これを実現するために作業を行わなければならない。それらのPDPミーティングに時間を割り当て、DBAを雇い、難しいものの完全な仕様を提供し、必要なものと望まないものを正確に指定します
これを適切に行うことは、開発者からプロジェクトマネージャーへの大量の作業のアンロードです。しかし、それができれば、速度は急上昇します。
試合開始
発券システムがあります。ルールです。今クリエイティブになります。
1）去る。
ボールをプレーしたくない場合。
たぶん原則的に、あるいは多分それはあまりにも困難です。
他の場所に住むことができるのに、そこにいて文句を言うな。
2）ルールに従ってプレイする。
上層部が求めていることを正確に行うために時間をかけてください。
嫌なことを言わないでください。率直かつ専門的です。もし彼らがあなたを押し越そうとするなら、あなたは単にルールを指摘し、彼らの下ではそれは起こりえないと言います。アプローチの利点と利点を指摘し、変更するよう丁寧に依頼します。
それで、彼らがあなたが物語を手入れすることを望むならば。行くとグルーミング。見積もりは最終的には大きくなるでしょう。そして彼らは文句を言うでしょう。未チケットの作業が実行されておらず、今後のプロジェクト作業のみに指示されているため、チケットの問題が発生していないことを指摘するだけです。見積もりを下げたい場合。彼らはコード債務を発券し、それをスケジュールする必要があります。
彼らが作品にチケットが発行され、優先順位付けのために提出されることを要求した場合、これは私たちをもたらします。行くとチケット。その時間を費やして、すべての問題を特定します。チケットの数はどんどん増え、不満を言うでしょう。すべてのコード債務関連の作業が特定されており、これらは多くの重要な作業の事前要求者であることを指摘します。彼らはプロジェクトの作業を押し進めます。その仕事をするのに必要な各ハックとクラッジにチケットを発行します。
結局、彼らはチケットを閉じるだけで、殺到するチケットに対処しようとします。あなたが利害関係者としてあなたが彼らのチケットを閉じる能力も持っていない限り、これは規則に違反していることを指摘してください。
再びそれについて意地悪しないでください。これらはルールであり、あなたはそれに応じて行動しています。特定の利点を持つこの代替システムを好むでしょう。
妥協点でそれらを売りなさい。チームは小さな変更を実行しますが、その代わりに、チケットにコミット、実行者、所要時間、意図、簡単な説明を記入します。
- 「小さな」変更を追跡することを約束する
- あなたをうまく識別するために行うこと、あなたはあなたの仕事に対する謝辞に値する
- 米粒を数えるのが好きだからね.
- 意味的なグループ化は常に次のように優れているためです。依存関係の更新、コードのクリーンアップ、コードのリファクタリング、デッドコード、コードカバレッジ。
- ビジネスマンはコードを読み取ることができず、SCMにアクセスできないため、説明。
彼らがお祝いの言葉を変えることに同意した場合：あなたはあなたのビジネスがそれに俊敏なエッジを維持するのを助けました。
3.ルールを破る。
とにかくそれをしてください。
会社の文化に対して破壊的であること。これは反乱です！古いシステムのチェーンを捨てます。
システムが処理することになっていることに最終的に遭遇したときに不平を言わないでください。
あなたはそれを壊し、あなたはそれを修正しますそしてそれに代わって支払う。
あなたの後に来る人は、対処するための血まみれの混乱、またはのどかな楽園を持っているかもしれません。可能性は何だと思いますか？
また、ドアから出る途中でプロフェッショナリズムの似顔絵を切ってください。
私のルールは次のとおりです。1.チケットとコードレビューなしでは何も起こりません。ずっと。 2.開発者は自分が何をしているか知っています。彼らが仕事が必要だと思うなら、それは必要です。
つまり、何が起こるかということです。変更を加え、ストーリーポイントの数をできるだけ少なくしてチケットを作成し、それを自分に割り当て、現在のスプリントに追加し、ブランチを作成し（これらすべてを任意の順序で）、プルリクエストを作成します。 。次に、他の誰かがレビューしてマージします。少し練習すれば、変更とコードレビュー以外のビットを5分未満で実行できます。
あなたが彼らが何をしているかを知らない開発者であり、役に立たない仕事をするなら、あなたの変更はレビューを通過せず、そしてこれが十分に頻繁に起こるなら、あなたはそれをやめます。
これに対する議論は、開発者はどの作業が優先事項であるかについての意見を他の利害関係者よりも重要であると効果的に述べており、POを通過しないためバックログの他の作業と比較できるということです。
これは本当の議論なのでしょうか？
口調は、開発者が独立した意見を形成することである程度の傲慢さに苦しんでいることを示唆していますが、開発者が実行する必要がある作業について意見を形成することはまったく驚くことではありません（整合性を維持するための一般的な責任の一部として）システム、または彼らが設定されているタスクの一部として必然的に伴う）、および多くの状況で彼らの意見が最も重要である可能性があること。
どのような規模の予期せぬ、または計画外の作業が手続きを必要とするかについての賢明なガイドラインを試し、同意することがより適切です。ここでは30分、ソフトウェアでは1時間もありません。
からアジャイル推定と計画マイク・コーンによる：
推定範囲内の有効な数値として0を含めることを検討してください。チームが実際に作業を行わない多くのユーザーストーリーや機能に遭遇することはほとんどありませんが、0を含めると役立つことがよくあります。これには2つの理由があります。まず、すべてのフィーチャを10倍の範囲内に収めたい場合、小さなフィーチャにゼロ以外の値を割り当てると、最大のフィーチャのサイズが制限されます。次に、作業が本当に1よりも0に近い場合、チームは機能の完了が速度計算に寄与することを望まない場合があります。チームがこのイテレーションで本当に些細なことで1ポイントを獲得した場合、次のイテレーションでは速度が1低下するか、それほど重要ではない作業を行うことでそのポイントを獲得する必要があります。
チームが推定スケールに0を含めることを選択した場合、プロジェクトに関係するすべての人（特に製品の所有者）は13×0≠0であることを理解する必要があります。 0ポイントのストーリーは無料のランチに相当することを理解してください。ただし、1回の繰り返しで獲得できる無料のランチの数には制限があることも理解しています。 0を使用する代わりに、非常に小さなストーリーをグループ化して、それらを1つの単位として推定することもできます。
したがって、はい、すべてのタスクを見積もる場合は、本当に無料ではないことを知っている「景品」を含めます。チケットの作成にタスク自体よりも長い時間がかかるタスクを経験したことはほとんどありません。チケットの作成が困難または長いプロセスになることはほとんどありません。開発者が提供している追加の価値を製品所有者が確認できるように、それらのチケットを作成してください！それらがなければ、彼らは目に見えない仕事をしています。
アジャイルについて覚えておくべき重要なことは、アジャイルであることです！厳格に使用しようとすると、アジャイルではなくなります。
もう1つ覚えておかなければならないのは、「無料」タスクを見積もったが、スプリントの終わりまでにそれを実行できなかった場合、未完了の「無料」タスクの数が少ない限り、速度に影響を与えないことです。
どれだけ小さなチケットが発行され、スプリントプランニングが行われるかは関係なく、すべて、開発者がそれをいつ行うかではなく、小さい場合に実行する必要がありますか？
ほとんどはい。
これは一般に、作業の重要度、会社/ビジネス/チームの規模、各参加者/利害関係者/従業員の責任の所在などによって異なります。ただし、チケットを作成しないと、時間を逃します。 はい、あなたはその権利を読みます、あなたミス時間（ない失う）あなたが考慮しないでください。
チームを編成し、何かの見積もりを出すように呼ばれたとします。経験が豊富であっても、通常は常に過去のデータに依存する必要があります。また、データギャップがある場合は、補間する必要があります。そして、あなたはあなたの推定の正確さを低下させます。簡単な話ですが、事前に計画している場合、スケジューリング/推定手法の効率性や要求の厳しさに応じて（たとえば this を参照）、観察を「除外」する余裕がない場合があります。最も正確な見積もりを可能にするために、正確にどのくらい多くの場合正確にが費やされたかを知る必要があります。
いずれかのアプリケーションの開発者が、重要だと考える発券されていない作業を行っています。
最小の努力の原則 はそれが良いことだと言っています...実際、それは素晴らしいことです。これは、開発者が標準レベルとコード品質を一定レベルに保つことに専念していることを示しています。
チケットを上げる作業は、実際に作業を行うよりも時間がかかります
はい。 10年前のコンピュータの起動も、ポケット計算機を使用して20個の値を合計するよりも時間がかかりました。 間違った解決策：ポケット電卓を使い続けます。 rightソリューション：コンピュータの起動を速くする。 currentプロセスがtoo効率的でないからといって、生産性を高める証拠をスキップしたくないのです。プロセスをmore効率的にします。どうやって？わかりません方法を見つける。別のチケットタイプ「Tech-debt repayment ticket」を作成します。それを完全に自動化し、ボタンをクリックするだけの労力と同等の努力をします。可能であれば、あらゆる理由で1つのボタンを作成します。あるいは、誰もが買い足して利用できる「技術債務返済時間」を導入し、必要に応じて割り当てることができます。
従業員の出席監視システム（カードスワイプマシンなど）について考えます。あなたのジレンマは、彼らの仕事をマークするプロセスがかなり面倒なので、彼らが仕事をするためにそこにいることを時々知らせていない人々と一緒にうまくいくことができるかどうかを考えることと同じです。それが給与時間になると、誰もが振り返って、欠落データの価値を知っています。
一般に、データ/情報の可用性は最も重要なものであり、収集の瞬間には思い浮かばないこともあります。これは、雇用主の保護、従業員の保護、生産性の向上などを行う可能性があります。一般に、データを追加するだけで生産性を失うことはありません。つまり、余分な情報が害を及ぼすことはめったにありません。
もちろん、この組織全体の考え方は、比較的小規模な開発チームにとってそれほど重要ではない可能性があり、開発者にそのようなタイプの「プレッシャー」を課したくない場合もあります。ただし、すべての作業を監視することが重要である理由をいつでも説明できます（ネタバレ：不足している場合に、より適切な見積もりを作成して利用可能な時間を管理できるようにするため）。いずれにせよ、もちろんあなたの走行距離は変わるかもしれません、それゆえあなたの質問への主な答えはほぼはいでした。