スクラムでコードをランダムにリファクタリングできますか

バックグラウンド

• 私のチームはスクラムを使用しています
• 現在、タスクが割り当てられていません
• バックログに保留中のタスクはありません
• 今日は私のクライアントの労働者の日です。

今日やるべきことがあまりないので、作業中のプロジェクトで見続けるコードのリファクタリングを開始したかったのですが、現在、大規模なリファクタリングを行うためのスプリントタスクは割り当てられていません。

それはでOKですスクラム私はランダムに私が持っていると書かれていないいつも私を気にすることをが、理由は他の日の割り当てのそれを修正するために、他の日の時間を持っていないこと、コードをリファクタリング開始した場合？

スプリントの間に余暇がある他の日はどうですか。

私は実際に継続的なリファクタリングを行い、それを信じています。私は常にストーリーを割り当てたときに作業しているコードの一部でそれを行いますが、それが現時点で作業しているものに現在関連していない他のコードはどうですか？

私は本当に他の答えを攻撃するつもりはありませんが、自動テストをここで書いている人は誰もいませんか？ ここでは「適切なソフトウェアエンジニアリングの実践なしでスクラムを行う人のためにMartin Fowler氏からの読み込み楽しいですよ。ロバートC.マーティンもここでこれについてたくさん語っています。

だから、私の答えに...要するに、それはこのようになります：

はい、チームが行うべきであると決定する限り、「ランダムに」リファクタリングコードがScrumで許可されます。（結局、それは自己組織化です）

そして今、長い答え：

スプリントごとにますます技術的な負債を残すことは、災害のレシピであることは明らかです。コードが乱雑になると、すぐにみんなが遅くなります。コードは非常に複雑で複雑なので、実際の変更を行うよりも変更するスポットを見つけるのに時間がかかるため、すべての変更を行うのが難しくなります。あなたが何も知らない大きくて厄介なモジュールに変更を加える必要がある場合はさらに悪化し、プロジェクトに人を追加/切り替えするときに生産性を獲得/維持することができなくなります。

チームが速度を一定に保ちたい場合、ソフトウェアを継続的に増加させるために、コードベースをきれいに保つことができなければなりません。リファクタリングは、プロジェクトのライフサイクル全体にわたって速度を維持したい場合、およびプロジェクトに人を追加/切り替えするリスクを軽減したい場合、および何も知らないモジュールを変更できるようにする場合に必須のプラクティスです。約など。

ただし、リファクタリングは非常に危険な作業です。私は繰り返します-それは非常に危険な活動です。つまり、コードベースを安全かつ自由に変更できるほど十分なテストカバレッジがない限りです。ボタンを押すだけで何も壊れていないかどうかを確認できる場合、リファクタリングは非常に安全なアクティビティになります。実際、非常に安全であるため、TDDのサイクルの一部であり、最初にこのようなテストスイートを作成できるプラクティスです。

しかし、スクラムのチームは自己組織化されているため、最終的にはチームが正しいことを決定する必要があります。誰かを説得しなければならない場合には、いくつかの議論をしたいと思います。（最初の段落のリンク、およびそれらが指し示す他のすべての記事に特別な注意を払ってください）

スクラムはリファクタリングについては何も言っていません。

スクラムの言うことは、スプリント内で作業するタスクがない場合、チームの他のメンバーがスプリントの目標を達成できるようにサポートする必要があるということです。それが彼らのためにコーヒーを取ってくることを意味するとしても。
コードをリファクタリングすることが最善の方法であることにチームが同意する場合（そして、リファクタリングがあまりにも多くの新しいバグを導入しないことを保証するためにインフラストラクチャを配置することを含む）、すべての方法でそれを行います。

いいえ、そうではありません。これは、作業の種類（リファクタリングなど）に関係ありません。

少なくとも、タスクを作成して現在のスプリントにプッシュする必要があります。時間追跡の目的は、将来のスプリントを効果的にプロットできるように速度をキャプチャすることです。それらを追跡せずに作業している場合、速度に影響を与え、適切な追跡で意図したとおりに時間が経過しても改善しません（投影速度が実際の速度よりも小さいため、通常は十分な作業ができません）。

リファクタリング作業自体については、私はそれについて大げさな話をすることができますが、私はそれがあなたが答えようとしている核となる質問だとは思わないので、そうはしません。

私もノーと言うつもりです。リファクタリングは、適切な方法で管理されていない場合、意図しないバグにつながることがよくあります。

GMとして、定期的に全員を別のプロジェクトに置き、1週間かけてプロジェクトのコードレビュー/リファクタリング/名前の変更と規則の施行を行いました。これらのリファクタリングスプリントは、ほとんどの場合、本質的に化粧品です。機能的なリファクタリングは事前に計画され、元の開発者が関与します。

機能的なリファクタリングは、スクラムプロセスの一部として常に計画および調整し、時間を追跡し、必要なすべてのチームメンバーがプロセスを検証できるようにする必要があります。ある開発者は、他のオフトラックによって記述されたコードを変更することを避けるべきではありません。ほとんどの場合、誰にとっても現在のスプリントを台無しにしてしまうからです。特にコードのマージ時間に関しては。

それがあなたが唯一のメンテナーであり、あなた自身の自由時間であるプロジェクトである場合、現在のスプリントで不必要な遅延を引き起こさないことを確実にするための措置を講じると仮定すると異なる場合があります。

疑問がある場合は、マネージャーに尋ねてください。

編集：私はまた、あなたが好きではないコードの特定の部分がそれに関連付けられている特定のパフォーマンスターゲットを持っている可能性があることを言及したいと思います。あなたはそれを好まないかもしれませんが、それはあなたがそれを使いたい方法に合うあなたが構築することができる何よりも速いかもしれません。機能的リファクタリングが常に管理されたプロセスであるべきであるもう一つの理由。

スクラムはリファクタリングについては何も言っていません（Robert C. Martinの講演「スクラムが忘れていた土地」を参照）。

スクラムのタスクでは、リファクタリングによって返済する技術的負債ではなく、顧客が指定したソフトウェアの機能を対象としています。これらはまったく異なる抽象化レベルです。顧客はほとんどの場合、必要性を評価できません。

スクラムは統計的なプロジェクト管理です。「所要時間」の意味のある測定値を取得するには、パフォーマンス（スプリントごとの出力）を知る必要があります。統計を取得するために、少なくとも1つ以上のスプリントの機能の推定と実際の継続時間を比較します。5つのスプリントをお勧めします。しかし、それはあなたのチーム次第です。

主なことは、あらゆる予測を可能にするために、測定値を意味のある比較可能なものにすることです。技術的な負債のためにパフォーマンスが低下している場合は、そうではありません。

今でもタスクのリファクタリングを考えている場合、次の2つの問題があります。以前のスプリントでは考慮されなかった別の変数を突然変更したため

どちらの場合でも、機能について顧客と話し合い、「どれくらい時間がかかりますか？」の信頼できる予測をしたいので、スクラムのアイデアを妥協します。統計的な方法で。安全のために、コードベースを一定の（おそらく高）品質に保つ必要があります。

リファクタリングは、ほとんどの場合、アンダーグラウンドタスクです。「素晴らしい」リファクタリングとは、「小さな」リファクタリングが過去に処理されていないことを意味します。

最後に、リファクタリングを行う場合、テスト対象のコンポーネントがあることを確認してください。ああ、テストはありませんか？テストを作成するタスクを作成します。お客様は、現在使用しているソフトウェアのテスト範囲が十分でないことを喜んで知るでしょう...

技術的なものは顧客から遠ざけ、プロの開発者として仕事をしてください。

ここに1つのアプローチがあります：両方をしてください！

リファクタリングは、多くの場合、@ misterbiscuitが指摘していると当初推定されたエラーが発生しやすい、またはより時間がかかります。

したがって、それをドラフトまたはスパイクにする試みを検討してください。この段階で承認を求めたり広告を出したりすることはできません。

次に、2つのチャネルのいずれかでそれを含めるようにします。

• これを合理的にラップできるのと同じコード/機能に触れる既存のチケット。他のチームメンバーと合意したとおりに合理的に。
• 次のチケットグルーミング（またはウォーターフォールの場合は毎週のミーティングなど）でレビューするためにチケット全体を作成します。その時にあなたはそれを主張することができます。

実際のバイインを取得したら、スパイクを適用または再実行して、コードを実際にメインライン（マスターなど）ブランチにマージすることができます。

これにはいくつかの利点があります。

• すべてのコードは同じプロセスを経てテストされ、QA、リリースパイプラインなどで取得されます。
• リファクタリングはクラフトの一部であり、休日に「忍び込む」必要のあるものではないという、プロダクトマネージャーからの正式な賛同を得ます。実際の機能が遠近法に役立つかもしれないので、なぜ「潜入」していないのか自問してください。
• ペアリング、コードレビュー、qa、devops、およびコード変更のファクタリングに必要な他のすべてのサポートを依頼できます。ポリシーと手順およびボードに従って、すべてが公式になります。
• SOX準拠の株式公開企業の場合、この種の正式なプロセス（文書化してからそれを実行するなど）を実行する必要がある可能性があります。
• 製品マネージャー（変更は迅速に行われた）と開発チーム（コードベースが改善された）の両方でより良い評判を得ます。
• 組織は、生産性、士気、従業員の定着、その他の多くの理由に適したコード品質を重視しています。
• すべての作業を含めると、プロジェクトの速度への影響をより簡単に追跡できます。存在自体が速度に影響を与えるために使用できるため、ポイントを指定しないことは問題ありません。
• 開発者は、Fisheye、Githubなどのコードレビューを容易にするツールを見つける可能性があります。
• 開発者は、コードを共有し、リファクタリングを容易にする基本的な標準（文書化されている場合もありますが、そうでない場合もあります）を見つける可能性が高くなります。リファクタリングの大部分は、スタイルを選択してからそれを広く適用することです（アプローチの混合物をスタイルに置き換える）。

最後のコメント：製品マネージャーが「ランダム」という言葉を聞くのを避けます。「ターゲットを絞った戦略的なパフォーマンス強化」コードのアップグレードにより、より好意的に反応する場合があります。または、アプリケーションサービスパック。または、どの言語でもカバーできます。

ランダムリファクタリングは意味がありません。理にかなっているのは、ほとんどの利点をもたらすコードのリファクタリングです。ということは：

• 設計またはアーキテクチャの問題を修正する
• 実装の改善

スクラムでは、自分のコードをランダムにリファクタリングし始めて、常に面倒なことはしますが、他の日の割り当てのために修正する時間がありませんか？

この答えから：

コードを保守可能に保つことは、バーンダウンリストの項目である必要があります（スクラムを使用する場合）。新しい開発と同じくらい重要です。「ユーザーに見える」ものとは思えないかもしれませんが、無視すると技術的な負債が増えます。コードの保守性の欠如が開発を遅らせるほど技術的な負債が積み重なると、新しい機能の開発の遅れが顧客に見えるようになります。

私の以前の仕事では、大きなスプリント（2〜3か月）で、ある種のスクラムがありました。スプリント間の遅延（1か月）があったため、この時間を使用してソフトウェアを分析し、コードをリファクタリングしました。