私はスクラムで仕事を始めたばかりで、何かが欠けているようです。私はスクラムが初めてです

コードは、古典的なASP / ASP.NETの組み合わせの完全な混乱です。スクラムは、大きな混乱を修正するか、それを追加することで構成されます。書き直しを始めるのに忙しいので、不思議に思っています。

スクラムのどこに、開発者が十分に十分であると言うことができ、大きな書き直しを開始する時間を与えることを要求することができる部分がありますか？古いコードに「Stories」をパッチするだけの無限ループのようです。

そのため、コードベースがどれだけ悪くなったのか理解していないため、書き直そうとは思わない非技術的な人々によって物事が実行されています。

では、誰がこの大きな書き換えの変更を担当しているのでしょうか？開発者ですか？スクラムマスター？

現在の戦略は、時間を見つけて、より高いレベルの人が関与することなく自分でそれを行うことです。なぜなら、彼らは主に現在の混乱に責任がある<-からです->。

これがなぜ人々にとってこれほど難しいのかはわかりません。彼のビジネスケースはここにあります。

We seem in an endless loop of just patching old code with 'Stories'.

開発者の時間はお金です。たくさんのお金。私は1年以上前にUIの改良を計画していた会社を辞め、スクラムを採用することで車輪の回転が止まることを望んでいました。何が起こった？同じオール '同じオール'。基礎となるコードベースが完全に時代遅れになったために、繰り返しごとに作成したコードの半分が無意味になっても、彼らは新しい機能を追加し続け、「技術的負債」にはビジネスケースがありませんでした。私が去って以来、彼らのフロントエンドで変化したものは一つもありません。私はそれを完全に改造するというまさにその目的のために連れてこられました。2か月間、私は実際にCSSやJavaScriptをなじみませんでした。1990年代後半から、HTMLと古代のJavaテンプレートシステムをいじっていました。

私の答え？あなたができることをしてください、しかし、他の開発者がすでにgivenめ、より実用的な期限を主張するよりもスプリントの目標を達成するために遅れて働いている場合、技術的な負債は実際にブロッキング問題であると主張し、最悪の事態を想定して新しい仕事を探し始めます今。開発者が懸念を伝えることができないか、許可されていないか、ビジネスがあまりにも近視眼的で、彼らがどれだけのお金を浪費しているのかを理解することができません。

これらの問題を無視すると、長期的には常にコストが高くなります。そしてもう少しではなく、もっとたくさん。開発時間が関係するのは胸が痛いだけでなく、知識が豊富で他のオプションを持っている開発者がペストのような会社を避けるため、才能レベルが低下することも避けられません。私の上司は開発者であり、会社の所有者です。他の優先順位に焦点を合わせて書き直すことはできませんが、一貫性のあるタイムシンクであるためにリファクタリングが本当に必要な場合は、適切なリファクタリングが行われます。そして結果は明らかです。新しい要素の変更と追加は、複数の要因により簡単かつ迅速になります。適切なアーキテクチャでは、かつて何時間もかかっていたことが数分かかることがあります。ビジネスはそれを聞きたくありませんが、そのために物事を保留する価値があります。

スクラムは、開発者があまり動揺しない環境、IMOでの失敗です。なぜなら、ビジネスタイプが、「成功したイニシアチブ」リストに載せることができる箇条書きを支持して、メンテナンスと更新を無視したいのは簡単すぎるからです。評価時間が来ます。彼らは常にこれらの問題を無視するようにロバに噛みついていても、彼らの皮と長期的な昇進の可能性を常に好むでしょう。

スクラムは、利益重視の業界であり、その一部です。企業はスクラムトレーニングに多額のお金を払います。採用を検討している人は、誰にマーケティングされているか、そしてそれが彼らの与えられた文化の中でどれほど現実的であるかについて慎重な目を向けるべきです。

とにかく、実際に開発、くだらないコードベース、耳にワックスを使った管理、棘のない開発者について気にするなら、悲惨さのレシピであり、有用な点でスキルセットを強化することはほとんどありません。問題を解決する努力が実際に成果を上げているかどうかを実際に発見する前に、GTFOへのステップを開始することをheしないでください。

もしあなたが本当にスクラムをやっているのなら、私は疑いますが、プロダクトオーナーが書き換えを決定する責任を負うでしょう。ほとんどの場合、書き換えは新しい機能を生成せず、新しいバグを導入するだけなので、良いアイデアではありません。

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

「書き換えは良い考えではありません」を展開するには：

漸進的な改善を試みることはほとんど常によりよいです。Jarrod Robertsonがコメントで書いたように、改善が必要なモジュールを見つけてそのモジュールの専門家になり、その特定のモジュールを改善するための次のスプリントのストーリーを書きます。そのモジュールが動作する必要がある理由を製品所有者に説明します。

私は本当に鈍くなります...

• この仕事の開発者を担当していますか？
• あなたはプロジェクトリーダーですか？
• 開発者はプロジェクトにどのくらいの「ステーク」を保持しますか？
• 書き換えのビジネス上の正当性は何ですか？
• 完全に役に立たず、回復不能にするコードベースについてはどうですか？

あなたは、あなたが仕事を始めたばかりであると述べましたが、あなたはすでにその状況のマスターであるように見えます。おそらく私はあなたの質問の意図を誤解しているかもしれませんが、あなたは多くの問題を抱えている仕事に就き、コードが壊れている唯一の方法である最も簡単な結論に飛びついたという印象を受けます書き直しますが、それを行うために雇用主の費用を本当に考慮しましたか？

既存のコードベースでは、状態がどれほど貧弱であっても、所有者は通常、コードが表す製品にかなりの投資をします。コードベースに関連する直接コストと間接コストの両方があり、コード資産の価値を下げるリスクがあるため、ソフトウェア開発者として書き直しが最後にしたいことがよくあります。尽力。

例として、Windowsのオペレーティングシステムを取り上げます。新しいバージョンが作成されるたびに、以前のバージョンから引き継がれた大きなコードの塊がありました。場合によっては、ライブラリとAPI全体がOSの複数の世代に渡って前方にドラッグされます。どうして？開発者は、これらの要素が機能し、テストされ、セキュリティとメモリの問題を防ぐためにパッチが適用され、修正されていること、そしてその状態に入るのに莫大な費用がかかっていることを知っています。メンテナンスコストが比較的高くても、最初から作業を開始するためのコストは常に高くなりますが、Microsoftの場合のように、銀行には数十億の銀行があります必要に応じて最初から始められるようにしますが、そうしません t投資からのリターンを最大化するため。あなたの雇用主は、プロジェクトに投入する現金が数十億ドルあるということを除けば、マイクロソフトと同じです。

そのため、このコードは混乱し、会社のさまざまな分野の間にコミュニケーションと境界の問題があるように聞こえます。これについてあなたや同僚は何ができますか？

1つの選択肢は、チームがこれまでと同じように継続し、将来の奇跡を期待することです。おそらく良い考えではなく、あなたの欲求不満とストレスを増やすだけでしょう。

より良いオプションは、単純にこじって仕事をすることですが、この一環として、最も脆弱であると思われるコード領域をサポートするテストを追加し、それらがより安定するまでリファクタリングする機会を探します。会社の投資を改善するという説得力のある議論をするだけで、すべてを捨てるのではなく、時間を節約できます。

さらに優れたオプションは、チームとして編成され、チームがコードベースを改善するための時間をスケジュールするための柔軟性を高めることができるように、十分な年配の人を確保することです。会社の忙しさやスケジュールの厳しさは気にしませんが、1つか2つの改善を行うために使用できるアクティビティには、時折「だまし」があります。ただし、他のタスクを完了しながら改善を行うことができればさらに良いでしょう。それが私なら、ソフトウェア開発者が読む標準的な本のいくつかのコンセプトをマネージャーに紹介し、それらを紹介します。 きれいなコードおそらくあなたのチームが最も必要とするものです。コードを改善する方法についていくつかの種を植え、あなたが何を意味するかのいくつかの例を提供します。特に技術的負債の概念を説明できる場合、優れたマネージャーはコードに漸進的な改善を加えることの価値を理解します。チームリーダーまたはマネージャーがコードを改善するための優れたビジネスケースを作成できるように支援してください。そうすれば、コードに基づいて行動するより良いモチベーションが得られます。

「コードが乱雑だ」と言うだけでも十分ではありません。同僚に常にきれいなコーディングを練習するように促し、きれいなコーディング手法を使用して、少しずつ片付けを促す必要があります。新しい仕事に就くたびに、小さなポスターを印刷して、オフィスの壁に掛けます。「常に、あなたが見つけたよりも少しだけ美しいコードを残すよう努めています」と書かれています。そのすぐ隣に、「ユリは金メッキする必要はありません」という別のコメントを追加します。どちらも、私が見つけたものを常に改善するよう努めるべきであるが、ある問題を別の問題と単純に金メッキすることを避けなければならないことを思い出させてくれます。大量の書き換えは、しばしば間違った理由で行われるため、最悪の種類の「金メッキ」です。まったく新しい製品バージョンがいつか正当化される可能性がありますが、

公式スクラムガイドからのスクラム開発チームの公式定義を以下に示します。あなたに直接関係する部分に重点を置きます。

開発チームは、各スプリントの最後にリリース可能な「完了」製品の増分を配信する作業を行う専門家で構成されています。開発チームのメンバーのみが増分を作成します。開発チームは組織によって構成され、自分の仕事を整理し管理する権限があります。結果として生じる相乗効果により、開発チームの全体的な効率と有効性が最適化されます。開発チームには次の特徴があります。

• 彼らは自己組織化しています。開発チームに、製品バックログをリリース可能な機能の増分に変換する方法を伝える人はいません（スクラムマスターでさえも）。

• 開発チームは職域を超えており、製品の増分を作成するのに必要なチームとしてのスキルをすべて備えています。

• Scrumは、開発者以外の開発チームメンバーのタイトルを認識しません。その人が実行している作業に関係ありません。この規則に例外はありません。

• 個々の開発チームのメンバーは、専門的なスキルと重点分野を持っている場合がありますが、説明責任は開発チーム全体に属します。そして、

• 開発チームには、テストやビジネス分析などの特定のドメイン専用のサブチームは含まれていません。

そのため、開発チームは自身の混乱に責任を負い、チーム外の人に尋ねることなく、それ自体に対処する必要があります。

将来の見積もりの​​それぞれに技術的な債務修正時間を含め、提供するソフトウェアの品質が最高であることを確認してください。

完全に書き直す必要がある場合は、スクラムレトロスペクティブで問題に対処する必要があります。プロダクトオーナーは、最終的にプロジェクトをキャンセルし、新しいプロジェクトを開始できます。スプリントをキャンセルできるのはプロダクトオーナーだけです。

あなたがこれを説明し、私はSCRUMとは何かを持って何も表示されない、またはお使いの製品開発チームが問題であることを言わなければならない現在。

これは正常です

あなたが説明するのは、コードベースの通常のエントロピーです。あなたの場合、チームはおそらく理想から遠く離れたところから始まったかもしれませんが、それでもすべてのコードベースは最終的には泥の大玉になります。

完全に完璧な グリーンフィールドのシナリオでは、絶対エントロピーから遠く離れて開始し、ゆっくりと進むことしかできません。

私は他の人に同意します、コードベースの混乱は開発者によるものです。これは、SCRUMの採用よりも何年も前のことです。

これは、書き直すという技術的または開発者の決定ではなく、ビジネス上の決定です。

製品の所有者が書き直したくない理由を知っているわけではありません。開発者としてあなたはそれが必要だと思いますが、それに対するビジネスケースは本当にありますか？

真のビジネスケースがある場合、手を振るだけではありません。「コードは私が望んでいるので、私はグリーンフィールドを開始したいレガシーな混乱です」、そして管理はその投資に対するリターンを考慮して、書き換えの費用を楽しませるでしょう。

あなたは一つの固体与えられていないビジネスケース、ちょうど再書き込み用の暴言あなたについての意見誰もがこの混乱を引き起こし、どのようにあなたはそれに対処する必要はありませんが。

証拠-利益は、OCDがクリーンなコードベースを必要とせずに、業務上の意思決定を動かして、動作中のソフトウェアを捨てる

実際に証拠を示すことができる場合、理論だけでなく、グリーンフィールドの書き換えにドルを費やすことで、時間枠内でビジネスのドルを作ることが保証されるという確固たる証拠（高い場合と短い場合）、経営陣から何らかの牽引力を得ることができます。これは、提示して証明できる可能性が非常に低いケースです。X X * NYNY

そうでなければ、あなたはそれに対処する必要があります、これは現実です。この壮大で完全な書き直しがないと絶対に前進できないという断固たる主張とは反対に、あなたが不満を漏らしているコードベースは今から5年後も誰かの機能と価値をどこかで提供し続けていると信じていますあなたは会社を辞めました。

私は通常、人々が「大きな書き直し」を求めたとき、懐疑的です。確かに理にかなっているケースもありますが、ほとんどの場合、レガシーコードには価値があります（既に生産されており、その作成を促した目的で使用されているため）。多くの場合、大きな書き換えを行うことはアジャイルの反対です。新しいバージョンのアプリケーションを、既存のアプリケーションを実行可能な状態に置き換えることができるポイントまでどれくらいの時間がかかりますか。

私が好むアプローチはマーティンファウラーが絞め殺すstrと呼ぶものです。新しいアプローチを使用して新しい機能（既存の機能への変更を含む）を実装しますが、既存のアプリケーションを、新しい機能が成長できるトレリスとして使用します。これにより、両方の長所が得られます。大規模な書き換えが行われている間、すべてを停止する必要はありませんが、更新されたフレームワークを活用する新しいコードを作成する利点が得られます。それは間違いなく、きれいに始めるよりも難しいアプローチであり、それほどセクシーではないかもしれませんが、時代遅れなのでそこにあるすべてのものを捨てるよりもビジネスに多くの価値を提供します。

私がどこにいるのか、これがどのように機能するのかが私たちのすることです。新しいストーリーを書き、それをプロダクトオーナーに渡してください。たとえば、「製品Xの開発者として、将来の開発がより効率的になるように、この領域のコードを書き直したいと思います。」受け入れ基準は、次の行に沿っている必要があります。この方法でより良いように。

あなたがいる状況については知りませんが、ここから最初からやり直したい場合は、製品の所有者と一緒に座って、なぜ彼らを説得し、既存のものを再作成するために物語の山を書くのでしょう機能。

悪いコードやレガシーコードに対処するために私たちが行った他のことは、ユーザーストーリーを外に出すときに再作業のためのタスクを含めることです。

大規模な書き換えを決定することはビジネス上の決定です。物事のビジネスの部分を担当する人々にあなたの視点で販売することにより、ビジネスの決定に影響を与えることができます。

しかしながら; あるイテレーションから次のイテレーションへのコード品質の変化は開発者の決定です。コード品質の低下を許容する場合、製品所有者の期待に応えるために技術的な負債を追加しています。あなたができることは、あなたが書いたコードの責任を取り始め、それがコードベースを改善することを確認することです。これは、技術的負債の量を継続的に減らしているため、速度を失うことを意味し、製品所有者はきっと失望するでしょう。コードの品質を低下させ、この問題を修正するための措置を講じていることを喜んで説明してください。

今、私はそれが恐ろしい一歩であることを理解し、重要な締め切り前にフィーチャーXを出すことができるようにもう1つのスプリントを遅らせたいと思うかもしれません。残念ながら、長く待つほど難しくなります。

ところで、これは厳密にスクラムの問題ではなく、スクラムに固有の解決策を提案するものでもありません。これは、開発者がコードの所有権を取得することに関するものです。

開発者は、コードベースの現在の状態を世界中に警告する責任があります。これは、毎日のスクラム、レトロスペクティブ、または単に非公式に発生します。当たり前のように思えるかもしれませんが、それが何であるか、そしてそれのためにどれだけの時間を無駄にするかを明確に表現しなければ、誰も気付かないでしょう。通常、スクラムマスターは、POとプロジェクトの担当者に情報を渡し、何かする必要があることを説得し、チームによるソリューションの実装を促進する責任を負います。

サイドノートとして、ビッグバンの書き直しはIMOが必ずしもこの種の問題に対する正しい答えではないということです。ただし、開発者は現在のコードベースにうんざりしているので、進捗状況を確認し、POに成果を定期的に表示して作業を正当化し、新しいユーザーを実装するフローを続けることができるため、よりクリーンなアーキテクチャに向けて小さな測定可能な手順を踏むことは多くの場合、より良いアイデアです無限のリソース独占変身で迷子になるのとは対照的に、物語を並行して。

あなたが尋ねた：

スクラムのどこに、開発者が十分に十分であると言うことができ、大きな書き直しを開始する時間を与えることを要求することができる部分がありますか？古いコードに「Stories」をパッチするだけの無限ループのようです。そのため、コードベースがどれだけ悪くなったのか理解していないので、書き直そうとは思わない非技術的な人々によって物事が実行されています。

マネージャーと開発者の両方であるあなたの質問に対する最も簡単な答えは、スクラム、その他の方法論、または開発者が十分で十分だと言う力を持っているビジネスシナリオではないことです。リライト。ここの多くの人々は、書き換えが頻繁に悪い考えである理由を説明し、変化が漸進的で俊敏な方法でもたらされるべきであり、どのようにもたらされるべきかを説明するために、良い有効な議論をしました。そして、私は彼ら全員に同意します。

しかし、最終結果はさらに単純です。あなたはその決定を下すことは決してできません。あなたは従業員であり、あなたが本当に下す決定は、「これらの攻撃のために働き続けるか、私の狂ったスキルを恐れる新しい仕事を見つけるか」です。あなたの新しい仕事でもあなたはその決定をすることはできませんが、少なくともあなたが仕事から仕事に飛び移るとき、あなたはあなたの運命をコントロールしているように感じるでしょう。

私はあなたの痛みを感じますが、それがスクラムと何の関係があるのか​​分かりません。コードを書き直すかどうかの決定は、開発プロセスに依存しません。

待って…何？

あなたはしているパッチを適用しますか？リファクタリングする必要があります。アジャイル値に固執します。TDDと適切なプラクティスを使用すると、状況は最終的に改善されます。