project-management - スクラムをメンテナンスとレガシーコードの改善にどのように適用しますか？

Question

タイトルが示すように...新しいコードで機能せず、ある程度推定できるものにスクラムプロセスを適用するにはどうすればよいですか？

まだ何かを計画したいときに、メンテナンスおよび緊急修正（修正に5分から2週間かかる場合があります）タイプの環境にスクラムプロセスを適用するにはどうすればよいですか？

基本的に、計画外のタスクやスクラムプロセスで見積もることが非常に難しいタスクを克服するにはどうすればよいですか？それとも、この環境に間違ったプロセスを適用しているだけですか？

score 22 · Accepted Answer

基本的に、予定外のタスクや見積もりが非常に難しいタスクをスクラムプロセスで克服するにはどうすればよいでしょうか。または、この環境に間違ったプロセスを適用しているだけですか?

この環境に対して間違ったプロセスを使用しています。必要なのは、計画済み/見積もり済みの SCRUM 開発プロセスとは別のスタック/キュー管理プロセスです。

その理由は単純で、次の 2 点です。

投稿で言及されているように、特にレガシーシステムが関係している場合、メンテナンスタスクを見積もることは非常に難しいことがよくあります。一般的なメンテナンスタスクとレガシーシステムでは、具体的には「中途半端な」問題が発生したり、長い「テール」が発生したりする傾向があり、単純に見える 1 つの修正で、別のコンポーネントへの変更が少し難しくなり、操作のオーバーホールが必要になる場合があります。いくつかのサブシステムの、順番に...あなたはポイントを取得します。
メンテナンスタスクを処理する場合、見積もりを完了するまでに、問題の解決も完了していることがよくあります。これにより、見積もりのプロセスが計画ツールとして冗長になります。メンテナンスタスクのために問題の解決から見積もりを分割することを主張する人は、単に不必要なオーバーヘッドを追加しているだけです。

簡単に言えば、待ち行列システムが必要です。次のコンポーネントがあります。

注意が必要であると識別されたタスクの「プール」。新しく調達されたアイテムは常にプールに入れられるべきであり、決してキューに入れられるべきではありません。
これらのタスクをプールからキューに移動するプロセス。通常、ビジネス/技術知識の組み合わせが必要です。
キューのサービスを担当する開発者がその前から簡単に選択できるように、明確に順序付けされたタスクのキュー。
キュー内で項目を移動する方法 (優先度の再設定)。重要/緊急アイテムの「キューをジャンプ」できるようにします。
キューのサービスを中断せずに完了したアイテムを配信する方法。通常、メンテナンス項目を提供するオーバーヘッドは開発作業よりも大幅に低いため、これは重要です。メンテナンスチームが、ビルドチームやテストチームがバグ修正を提供するたびに OK を出すのを 1 日も待っているのは望ましくありません。

キュー管理には他にもニュアンスがありますが、これらを適切に配置することで、正しい道を歩むことができます。

score 11 · Accepted Answer

環境にこれほど多くのチャーンがある場合、キーはより短い反復になります。チームが毎日反復を行っていると聞いたことがあります。また、制限が固定されたキュー（通常は2つまたは3つのアイテムなど、非常に低い）があり、それらが完了するまでアイテムを追加できないかんばんタイプのスタイルに移行することもできます。

私がやろうとしていることは、毎日のスタンドアップ、バックログの優先順位付け、および「完了、完了」を使用して1週間の反復を試すことです。次に、5〜6週間後に再評価して、何が改善されるかを確認します。プロセスをそのまま試すことを恐れないでください。一度試したら、環境に合わせて調整することを恐れないでください。

最近Yahoo!のスクラム開発リストに投稿された5分でのアジャイルサポートと運用というPDFもありました。

score 5 · Accepted Answer

バックログ項目は新しいコードでなければならないとは誰も言いませんでした。メンテナンス作業は、バグ修正、機能強化、データ修正のいずれであっても、製品バックログに入れ、見積もり、優先順位を付けることができます。これは実際、スクラムを使用する最大の利点の 1 つです。何かがバグ修正なのか機能強化なのかについてユーザーと議論する必要はもうありません。

Waterfall では、バグは開発者の責任であるという暗黙の了解があります。どういうわけか、彼らは新しいコードや機能の開発に影響を与えることなくそれらを修正しようとしています。したがって、ユーザーにとっては「無料」ですが、開発者にとっては非常に不便です。

スクラムでは、すべての作業に時間がかかることを認識しています。「無料」はありません。したがって、開発者は何かがバグであることを自由に受け入れますが、それでも製品バックログに入ります。次に、新しい機能を追加するよりもバグを修正することが重要かどうかを判断するのは顧客次第です。あなたが一緒に暮らすことができるいくつかのバグがあります。

score 2 · Accepted Answer

タイトルが示すように...新しいコードでは機能せず、ある程度推定できるものにスクラムプロセスを適用するにはどうすればよいですか?

それどころか、チームはメンテナンス段階でスクラムを採用する方が簡単だと感じていると聞いています..変更が小さく（大規模な設計変更がないため）、見積もりが容易だからです。新しい変更要求は製品バックログに追加され、開発者によって見積もられ、製品所有者によって優先順位が付けられます。

メンテナンスや緊急修正 (修正に 5 分から 2 週間かかる場合があります) の種類の環境にスクラムプロセスを適用するにはどうすればよいですか?

活動の消火タイプをほのめかしている場合は、そのような活動の反復作業クォータの一部を保持してください。過去の傾向/活動に基づいて、たとえば、反復ごとに 10 ストーリーポイントの速度があると言うことができるはずです。 (4 人のチームで 5 日間の反復)。私たちはそれぞれ、週に約 1 日を緊急事態への対応に費やしています。したがって、次のイテレーションが現実的であるためには、バックログ項目の 8 ポイントだけを選択する必要があります。緊急の問題がない場合は、優先順位の高いバックログから次に上位の項目を取り上げます。
CoryFoy は、応答の中でカンバンポストイットを使用した、より動的でリアルタイムなアプローチについて言及しています。

基本的に、予定外のタスクや見積もりが非常に難しいタスクをスクラムプロセスで克服するにはどうすればよいでしょうか。または、この環境に間違ったプロセスを適用しているだけですか?

AFAIR スクラムは見積もりテクニックを義務付けていません..チームが最も快適に使用できるものを使用してください..工数/ストーリーポイント/など.見積もりを改善する唯一の方法は、練習と経験であると私は信じています. 同じグループの人々が一緒に座って新しいタスクを見積もるほど、彼らの見積もりはより良くなります。メンテナンスのような環境では、システムが多かれ少なかれグループに知られているため、見積もりが容易になると思います。そうでない場合は、スパイクをスケジュールまたは使用して、より明確にします。

ここで象を食べようとしているように感じます..次の一口をお勧めします

score 1 · Accepted Answer

ストーリーのないすべての「バグ修正」を新しいコードとして扱います。それらを見積もり、通常どおりに機能させます。それらを新しいストーリーとして扱うことで、ストーリーとテストのライブラリを構築します。そうして初めて、アプリケーションの動作を固定し始めることができます。

MichaelFeathersによるレガシーコードの効果的な操作をご覧ください。抜粋へのリンクは次のとおりです。http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

-ジェイソン

score 1 · Accepted Answer

あなたは緊急事態のためのプロセスをどのように使うかについて尋ねます。ユーザーが同時に接続している本番環境でコードをハッキングする必要がある場合は、「緊急」という言葉を予約してください。そうでなければ、利害関係者はその言葉を乱用し、彼らが本当に速くしたいものに緊急事態を呼ぶ可能性があります。プロセスの欠如は、制御不能を意味するものではありません。誰かが緊急事態を宣言する責任を負わなければならず、誰か（ベストプラクティスは他の誰か）が通常のプロセス外の変更を承認してから責任を負う必要があります。

それ以外に、各イテレーションを使用していくつかの修正と改善を完了するという提案は、おそらく最善の方法です。

score 1 · Accepted Answer

これは、アプリケーションのライフサイクルに大きく依存します。もちろん、これがすぐに再試行される「サンセット」アプリケーションである場合、焦点は最優先のバグの修正にのみなります。

製品が「成熟」していて、ロードマップがあり、進化し続けている場合は、修正と機能強化を行う必要があります。デザインをクリーンに保ち、リファクタリングによって進化させるための多くの推進力があります。これは、定期的なマイナーリリースとメジャーリリースを意味する場合があります[eFixes-緊急修正/ホットフィックスを除く]。エンハンスメントと修正がストーリーボードに組み込まれ、Sprintのバックログの一部になる可能性があるため、アジャイルを心から喜ばせることができます。リスト全体が製品バックログになります。

結論：リファクタリングを行い、アプリケーションの設計をクリーンに保ちたい場合（プログラマーは、バグ修正のみに焦点を当てている場合、ショートカットを使用する傾向があります）、「生きている」アプリケーションでのみ発生する可能性があります。進化して更新されたもの。そしてアジャイルは自然なフィット感です。

修正（チューリング完全;）またはSunsetアプリケーションしかない場合でも、それらをすべてスプリントにロールインして、各スプリントの本番環境にロールインできると便利です。修正が修正されたときに修正を本番環境にロールインする必要がある場合、スクラムを適用することははるかに困難です。

score 1 · Accepted Answer

すべての修正と改善を個別のストーリーとして扱い、それに応じて見積もります。私の個人的な見解では、修正に 10 ～ 15 分もかからないものはすぐに実行する必要があります。時間がかかるものについては、現在の「修正と改善」の反復サイクルの一部になります。通常の要件を見積もる場合と同様に、チームとして最善の推測を行います。より多くの情報が明らかになり、見積もりがオフになると、イテレーションと今後のスプリントが調整されます。

多くの場合、修正と改善に反復サイクルを適用するのは難しく、システムが本来の機能を妨げ、「ビジネス」がそれらをできるだけ早く稼働させるよう圧力をかけます。この時点で、1 ～ 2 週間などの非常に短いイテレーションサイクルに移行する方がうまくいく可能性があります。

score 1 · Accepted Answer

スプリント/イテレーションがもたらす価値を確認することを強くお勧めします。優先順位を付ける必要があるタスクが十分にある場合や、利害関係者がいつ何かを実行するかを大まかに知る必要がある場合に、それらを適用することは理にかなっています。

この場合、次の 3 つのアプローチを組み合わせることを強くお勧めします。

次の繰り返しのためにできるだけ多くの着信タスクをスケジュールします
昨日の天気を使用して、すぐに処理する必要があるタスクを処理するために計画する必要があるバッファーの量を計画します
少なくとも次の反復の開始まで待機できるタスクの数を最大化するために、非常に短いスプリントを使用する

実際、これはすべてのアジャイル/スクラムプロジェクトに当てはまります。イテレーション 2 から、既存の稼働中のシステムに追加するメンテナンスモードにあるからです。

反復が十分な価値を提供しない場合は、代わりにかんばん/キューイングシステムを検討することをお勧めします。基本的に、タスクが終了したら、優先度の高いタスクキューから次のタスクを取得します。

score 1 · Accepted Answer

このコンテキストでスクラムを適用しました。

成功の鍵のいくつか。
1. 企業内の全員がスクラムのアイデアを購入する (これは成功に不可欠
です) 2. 約 2 週間のスプリント (プロセスを理解するために 1 週間のうち 2 ～ 3 回の最初のスプリント)
3. いかなる状況下でもポイントを追加することはできません現在のスプリントへ 4. 実際の緊急事態が発生した場合は、スプリントを停止し、ふりかえりを行い、新しいスプリントを開始します。
5. ふりかえりの時間を取る (最後のスプリントについて共有し、それを分析する時間
)。それは軍隊の士気にとって良いことであり、最終的には緊急事態を減らすのに邪魔になるでしょう.
7. TIME BOXEDデイリースタンドアップミーティング

見積もりについては、通常、見積もりをすればするほど正確になります。スクラムの良い点は、各プログラマーが自分のタスクを選択し、それが現実的ではないと思う場合に新しい見積もりを設定できることです。それでも見積もりに問題がある場合は、チームに解決策を見つけてもらいましょう。チームの成果に驚かれることでしょう。

2週間の修正のために。元の推定値である場合は、小さく切ります。より楽観的な見積もり (たとえば 2 ～ 3 日) を行った場合は、スタンドアップミーティングで問題がブロッカーとして浮上するはずです。他の誰かがそれを修正する方法についてアイデアを持っているかもしれません。解決策を見つけるために、ペアプログラミングを行うことを決定できます。バグを別のプログラマーに説明するだけでも、デバッグに大いに役立つ場合があります。スプリントの他のタスクの後に遅らせることもできます。アイデアは、完全に機能するタスクを提供することです。完全に修正して実証する時間がない場合は、たとえ 90% 完了していても (そうです! 私たちはそれが何を意味するかを知っています)、スプリントでそれが完了していないと見なします。次のスプリントでは、正しい時間見積もりで対処できるようになります。

最後に、私が理解したところでは、スクラムはプロセスを改善するための「ツール」を持つことです。簡単なことから始めます。小さな反復を行います。各反復では、FIX TARGETがあります無限のバグリストの代わりに完了する。計画のリストからタスクを選択するため (タスクを割り当てられるのではなく)、それを提供することにもっと熱心になります。スタンドアップミーティングでは、TODOリストを持って毎日ペアに会います... 前日に行った婚約を尊重したい. イテレーションでは、時間をかけてお互いに話し合い、何がうまくいっているのか、何を改善すべきなのかを特定します。また、それを改善し、機能していることを継続するための行動を起こします。私が言ったことであっても、何も変更することを恐れないでください ;) / スクラム自体の基本でさえも. 本当の鍵は、チームが満足して生産的になるために必要なものにスクラムを適応させることです. 1回の繰り返しでは表示されませんが、多くの場合....

score 1 · Accepted Answer

私の意見では、「実際の」リリースの頻度によって異なります。私たちの特定のケースでは、毎年 1 つのメジャーリリースがあり、その年の間にいくつかのマイナーリリースがあります。

これは、スプリントが完了しても、すぐに運用サーバーにデプロイされないことを意味します。ほとんどの場合、完全な「プロジェクト」が完了する前に、いくつかのスプリントが行われます。もちろん、スプリントのデモを行い、スプリントをテストサーバーにデプロイします。彼の全体の「プロジェクト」は、いくつかのエンドツーエンドのテストを受け、最終的に本番サーバーに展開されます->これはマイナーリリースです. たとえば、最初にアップグレードする必要がある他の製品/プロジェクトに依存している場合、本番サーバーにすぐにデプロイしないと決定する場合があります。次に、これをメジャーリリースに展開します。

ただし、本番サーバーで問題が発生した場合は、すぐに対処する必要があります。そのため、製品の所有者に目標や重要性を尋ねる時間はありません (問題を解決するための目標がある場合でも)。このような緊急のケースでは、この種の問題は製品バックログやスプリントには入れられませんが、純粋なメンテナンスタスクとして、できるだけ早く解決、テスト、展開する必要があり、個別の項目として扱われます。

これをスプリントとどのように組み合わせますか? チームメンバーがスプリントに集中できるようにするために、チームに「オプトイン - オプトアウト」することにしました。これは、1 人または複数の人が特定のスプリントのチームの一員ではなく、これらの緊急修正のような他の仕事に集中できることを意味します。次のスプリントでは、この人物が再びチームの一員となり、他の誰かが緊急通報の責任者になります。

もう 1 つのオプションは、スプリントの時間の 20% 程度を「計画外のタスク」として予測することですが、これはスプリントで実行できる作業量について誤った指標を与えることになります (同じ量の緊急の修正は、スプリント中に行われません)。各スプリント）。また、チームメンバーがスプリントに集中することを望んでおり、スプリントでこれらの緊急の修正を行うと、チームメンバーの注意が散漫になります。「コンテキストの切り替え」も時間のロスを意味し、それを回避しようとします。

それはすべて、「環境」と、緊急の問題をどれだけ早く修正するかによって異なります。

score 0 · Accepted Answer

スプリントの一部が、対処する必要のある計画外の「火災」で構成されていることを認識して、ある程度の成功を収めました。短いスプリントでも、これらは発生する可能性があります。開発チームがこれらの責任を負っている場合、スプリントの計画中は、ストーリーのみがスプリントにコミットされ、これらの他の計画外のアクティビティが発生し、必要に応じて処理されるのに十分な余裕ができます。スプリント中に「火」が発火しない場合、タムはバックログの一番上からストーリーを引き込むことができます。多くの点で、それはキューになります。

利点は、バックログへのコミットメントがあることです。不利な点は、チームを重要でないタスクに引きずり込む機会として伝達できる容量のこの穴があることです。容量のギャップが追跡されていない計画外の作業で埋められている場合も、速度は大きく変動する可能性があります。

この一部を回避する方法の1つは、チームがサポートアクティビティに割り当てることができる利用可能な時間を表すタスクで、残りの容量を埋める「サポート」ストーリーを作成することです。サポート状況がバックログに延期できないスプリントに入ると、タスクを使用して新しいストーリーが作成され、プレースホルダーサポートストーリーとタスクが新しいインジェクションを考慮して再推定されます。サポートインシデントがスプリントに入らない場合、未使用の容量を埋めるためにバックログアイテムが入ってくるため、このサポートストーリーは減少します。

その結果、スプリントは望ましい流れの一部を保持し、人々はサポート作業を引き受ける必要があるときに火傷を負わないように感じます。速度はより一貫しており、バーンダウンは正常に追跡されますが、各スプリントで発生したサポート注入の記録もあります。次に、スプリントの回顧展中に、計画された作業と計画されていない作業を評価できます。次のスプリントで別の方法でアクションを実行する必要がある場合は、そうすることができます。それが新しいスプリント期間、または組織内の誰かとの鋭い会話を意味する場合、新しい決定をバックアップするためのデータがあります。

project-management - スクラムをメンテナンスとレガシーコードの改善にどのように適用しますか？

12 に答える 12

Related

Reference