アジャイル-何が間違っているのでしょうか？

私はアジャイルチームの開発者であり、スクラムを使用しようとしています。

そこで、状況を説明するために仮想問題をここに入れます。

面倒で保守性の悪いJQueryコードを使用した非常に古いアプリがあります。また、Reactを使用したアプリの一部もあり、それらの部分は更新/保守がはるかに簡単です。それに加えて、会社の目標は、Reactでクライアントシングルページアプリを作成することです。そのため、JQueryを使用すると、さらに離れることができます。

計画を立てるときは、常に開発時間の観点から簡単な解決策を探します。たとえば、新しいダイアログなどを作成する場合は、以前のJQueryを使用します。後で整理してReactに変換しますが、それはめったに起こりません。

ユーザーストーリーから、必要なことの要件を取得します（IMOはよくできていますが、スリムですが、何をしているのか、なぜそれをしているのかを説明しています）。

新しい機能の要件は非常にスリムな場合があるため、たとえば、要件が「大量のコンテンツをロードするダイアログを作成する」と言っているが、ロード機能を実装するように言っていない場合、ほとんどの場合、実装しません、それは私たちがスプリントの目標を妥協する可能性があるという理由で、私たち全員がそれが顧客にとってより良いことを知っているにもかかわらずです（私は個人的にはそうはしないと信じていますが）。

その結果、私たちのコードベースは非常に保守性の悪い大きな混乱であり、新しい機能は非常に小さく、フルスプリントを費やすことがあります（良いコードベースで1日で達成できるもの）主にこの開発のため戦略、ただ速く行き、最小限のことをしてください。

この場合、何が間違っていますか？先週書いたばかりの悪いコードを書いたりコードを書き直したりしないように、より完全な方法で解決策に取り組むべきでしょうか？それとも、すべてのコードが書き直されていることを確認するだけでそれを続けるべきでしょうか？この問題に対するアジャイルなアプローチは何でしょうか？

これはアジャイルやスクラムとは何の関係もありません。

「今すぐダクトテープし、後で修正します」の問題は、後から来ることはなく、その間に多くの技術的負債を蓄積していることです。

回復するための最初のステップは、問題を認識し、悪化を止めることです。

新しいユーザーストーリーごとに、チームは「これをハッキングする最も速い方法は何ですか？」ではなく、「これをコーディングする正しい方法は？」を検討する必要があります。それに応じてスプリントを計画します。

既存の問題をクリーンアップするには、20万行のスパゲッティコードを継承したことに対する優れた回答をご覧ください。

マーティンファウラーが「穏やかなスクラム」と呼ぶものがあります。

アジャイルマニフェストの背後にある12の原則すべてを適切に読んだ場合、それらのほとんどで失敗していることがわかります。

作業ソフトウェアを数週間から数か月まで頻繁に、より短い時間スケールを優先して配信します。

本当に機能するソフトウェアを提供していると言えますか？または、ほとんど機能しないソフトウェアだけですか？

アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。

あなたのプロセスは持続可能であると言えますか？持続可能性を念頭に置いて意思決定をしていますか？または、長期的な影響を考慮せずに現在の問題を解決するソリューションを選択しますか？

卓越した技術と優れた設計への継続的な注意は、俊敏性を高めます。

真に主要な原則。これはページの巨大な赤い文字に入れるべきだと思います。これが最も失敗する場所です。

チームは定期的に、より効果的になる方法を熟考し、それに応じて動作を調整および調整します。

そして、最も明らかに。自分の行動が望ましい結果につながらないことがわかった場合は、変更する必要があります。チームに問題があることがわからない場合は、修正を開始できません。

あなたのコメントから

アジャイルでそれを防ぐ方法は？

まず、実際にアジャイルとは何かを学ぶことによって。スクラムは機敏ではありません。スクラムはアジャイルフレームワークの中で最悪だと言う人もいるでしょう。正確な状況に到達するのは簡単すぎるからです。他のアジャイルフレームワークについて学ぶ必要があります。私がお勧めするのは、エクストリームプログラミングです。これは明らかにあなたの問題を解決します。ソリューションは単純ではなく（堅牢な自動テスト、ペアプログラミング、継続的な配信を通じて技術的な卓越性に焦点を当てています）、非常に効果的です。で報告されているようにDevOpsチームレポートの状態。

あなたが説明するのは、少なくとも私の経験では、「アジャイルになろう」とするチームの非常に一般的な出現パターンです。これが実際にアジャイル自体の一部であるか、一般的な誤実装であるか、アジャイルのマニフェスト/原則またはその固有の結果に反するかなど、議論の余地があります。経験的な見地から、そして私自身の小さなサンプルの経験セット（そして私が話した人々）に基づいていますが、チームが機敏であれば、このパターンに遭遇する可能性は平均よりも高いようです。そのままにして、具体的な例に焦点を当てましょう。

説明する内容には、2つの異なる側面があります。

• 共通の理解/ビジョンがないため、効率的ではない
• 成功/進捗と総費用を測定する方法

間違った道を進むか、輪になって走る

私の経験では、これが起こる主な理由は、コードを迅速に作成するために、チームが既に知っている、または簡単に見つけることができるユースケースまたは要件を積極的に破棄することです。このように考えてみてください。10〜20年前、人々は巨大な仕様を書き、すべてを事前に考えようとして、しばしば失敗しました。時間がかかりすぎるか、何かを見落としていました。過去に学んだことの1つは、ソフトウェア開発にはあなたが知ることができず、物事は大きく変化することです。そのため、迅速に反復し、適切な出力を迅速に生成するという考えです。これは非常に良い原則です。しかし、今日、私たちは他の極端な状況にあります。「次のスプリントの一部であるため、私はこれを気にしません」または「そのバグを登録せず、再び発生したときに対処します」。

1. 見つけることができるすべての高レベルのユースケース、要件、依存関係、および制限を収集します。すべての利害関係者と開発者がそれらを見ることができるように、いくつかのウィキに入れてください。何か新しいものが出てきたら追加してください。株主とユーザーに相談してください。開発中にこれをチェックリストとして使用して、最終製品に貢献しないもの、または1つの問題を解決するが3つの新しい問題を引き起こす回避策/ハックを実装しないようにします。
2. 高度な概念を策定します。私はインターフェイスやクラスの設計について話しているのではなく、問題の領域を大まかにスケッチしています。最終的なソリューションの主な要素、メカニズム、および相互作用は何ですか？あなたの場合、中間ステップとしてjquery-workaroundヘルプを使用するとき、および追加作業のみを引き起こすとき、それは明らかにする必要があります。
3. 収集したリストを使用して概念を検証します。明らかな問題はありますか？理にかなっていますか？長期にわたる技術的負債を引き起こすことなく、同じユーザー価値を達成するためのより効率的な方法はありますか？

無理をしないでください。チームの全員（非開発者を含む）がMVPへの最善の道が何であるかを共通理解できるように、何かが必要です。明らかな見落としがなく、実際に機能する可能性があることに全員が同意する必要があります。これは一般に行き止まりになったり、同じことを何度もやり直さなければならないことを防ぐのに役立ちます。アジャイルは、予期せぬことにうまく対処するのに役立ちます。既知のことを無視することは議論の余地がありません。

サンクコストの誤りに注意してください。1つのアーキテクチャまたはデータベースタイプから始める場合、ほとんどの人はプロジェクトの途中で変更することをためらいます。そのため、何かを実装する前に、「教育された最良の推測」を得るためにある程度の時間を費やすことをお勧めします。開発者は、コードをすばやく書きたい傾向があります。ただし、多くの場合、モック、ライブプロトタイプ、スクリーンショット、ワイヤフレームなどがいくつか用意されているため、コードを記述するよりもさらに高速な反復処理が可能です。記述されたコードのすべての行または単体テストでさえ、全体の概念を再度変更するのが難しくなることに注意してください。

成功の測定

完全に別の側面は、進捗状況を測定する方法です。あなたのプロジェクトの目標は、周りにあるものを使って高さ1mの塔を建設することだとしましょう。たとえば、安定性よりも市場投入までの時間が重要である場合、カードの家を建てることは完全に有効なソリューションになります。継続するものを構築することが目標である場合、レゴを使用する方が良いでしょう。要点は、ハックと見なされるものと、プロジェクトの成功がどのように測定されるかに完全に依存するエレガントなソリューションです。

「ロード」の例はかなり良いです。過去にこのようなことがありましたが、誰もが（セールス、PO、ユーザーを含む）それが迷惑であることに同意しました。しかし、それは製品の成功に影響を与えず、長期債務を引き起こしませんでした。そのため、dev-resourcesにはもっと価値のあることがあるため、削除しました。

私のアドバイスは次のとおりです。

1. チケットシステムにチケットとして、すべて、小さなバグも含めて保管します。プロジェクトの範囲内にあるものとそうでないものを積極的に決定します。マイルストーンを作成するか、他の方法でバックログをフィルタリングして、まだ実行する必要があるすべての「完全な」リストを常に保持します。
2. 重要な順序を厳しくし、プロジェクトを成功と見なすことができる明確なカットオフポイントを設定します。最終製品に実際に必要な安定性/コード品質/ドキュメントのレベルは？トップから選ぶことで、可能な限り最高の仕事をするようにしてください。1つのチケットで作業するときは、新しいチケットを導入せずに完全に解決するようにしてください（優先度が低いために延期することが理にかなっていない限り）。コミットするたびに、横向きや後ろ向きではなく、最終目標に向かって前進するはずです。しかし、もう一度強調します。後から追加の作業を行うハックが、プロジェクトにとってプラスになることもあります。
3. PO /ユーザーを使用してユーザーの価値を把握し、開発者に技術コストを把握させます。通常、開発者以外は、実装コストだけでなく、真の長期コストを判断することはできません。沸騰カエルの問題に注意してください。時間の経過とともに、多くの小さな無関係な問題がチームをホールド状態に陥らせる可能性があります。チームがどれだけ効率的に作業できるかを定量化してください。
4. 全体的な目標/コストに注目してください。スプリントからスプリントまで考えるのではなく、「プロジェクトの最後までチームとして必要なことをすべて実行できますか」という考え方を維持してください。スプリントは、物事を分解してチェックポイントを設定するための単なる方法です。
5. 早く何かを見せたいのではなく、ユーザーに提供できる最小限の実行可能な製品への最速パスでコースを計画します。それでも、全体的な戦略では、間に検証可能な結果が得られるはずです。

そのため、誰かが最終的な実装目標に合わない何かをするとき、できればストーリーを考えないでください。ストーリーを閉じることが有益な場合（たとえば、顧客からフィードバックを得るため）、すぐに新しいストーリー/バグを開いて不足を解消します。ショートカットを使用してもコストは削減されず、単に非表示になるか遅延するだけであることを透明にしてください！

ここでの秘Theは、プロジェクトの総コストについて議論することです。たとえば、POが期限を設定するためにショートカットを取ることを求めた場合、プロジェクトが完了したと見なすために後で行う必要がある作業量を定量化します。

また、基準に基づく最適化にも注意してください。チームがスプリントレビューで表示できるストーリーの数で測定される場合、良い「スコア」を達成する最良の方法は、すべてのストーリーを10の小さなストーリーにカットすることです。記述された単体テストの数で測定される場合、多くの不要なテストを記述する傾向があります。ストーリーを数えるのではなく、むしろ、必要なユーザー機能がどれだけ機能するか、プロジェクトの範囲内で解決する技術的負債によるコストの大きさなどの尺度を持ちます。

概要

それを煮詰めるには：高速かつ最小限に抑えることは良いアプローチです。T 彼の問題は、「高速」と「最小」の解釈です。長期コストを常に考慮する必要があります（これが無関係なプロジェクトがある場合を除きます）。1日しかかからないが、出荷日から1か月の技術的負債を生むショートカットを使用すると、1週間かかったソリューションよりも会社のコストが高くなります。すぐにテストの記述を開始するのは速いように見えますが、概念に欠陥があり、間違ったアプローチを固めている場合はそうではありません。

そして、あなたの場合の「長期」の意味を覚えておいてください。すばらしいコードを書き込もうとして失敗して出荷が遅すぎた会社を複数知っています。企業の観点から見た場合、優れたアーキテクチャまたはクリーンなコードは、それを達成するためのコストがそれを持たないコストよりも低い場合にのみ価値があります。

お役に立てば幸いです！

厳密に言えば、スクラムの観点からすると、あなたが間違っていることは、クライアントと仕事をしていないということです。クライアントと協力して、クライアントが望むものだけでなく、必要なものを理解する必要があります。一連の迅速な修正が必要ですか、それとも長期的に役立つ安定した保守可能なシステムが必要ですか？それを判断するのは難しいかもしれませんが、品質は背景色やパフォーマンスのベンチマークと同じくらいの要件です。顧客は、安定性と保守性が無料ではないことを認識しておく必要があり、製品に組み込む必要があります。

彼らが前者だと言うなら、あなたは間違って何もしていません-あなたが彼らの目標を達成するためにエンジニアリングコーナーを切っていることをスプリントレビューで彼らに説明していると仮定すると、

彼らが後者だと言うなら、あなたが間違っているのは、彼らが望むものを彼らに与えていないということです。

スクラムの基礎の1つは透明性です。スクラムを行う場合は、顧客とスプリントレビューを行う必要があります。それらのレビューでは、ソフトウェアをより迅速に提供するために、あなたはコーナーを切っていると顧客に言っていますか？そうでなければ、あなたはそうあるべきです。適切な品質のソフトウェアを提供しているかどうかについて十分な情報を得た上で意思決定を行う機会を顧客に与えるために、設計選択の結果について顧客と100％明確にする必要があります。

ユアンは正しい。管理者がスクラムを好む理由は、スタッカートスタイルの機能を要求し、迅速に結果を得るためです。結果の混乱が他の誰かの問題になるまで。

あなたの注意を払ったので、説明させてください。それ自体はスクラムではありません。プレッシャーを感じているため、合理的で現実的な見積もりを下すことができないのは、強力な製品マネージャーと弱い開発チームの典型的な設定です。そのため、彼らは楽観的な見積りに遠く及ばず、問題を深く掘り下げ、時間内に納品するためにコーナーを切り開きます。

スクラムでは、（開発者として）自分で計画を立てることができます。x日で何らかの機能を提供するように言っている人はいません。誰かがx日以内に配信するように言っている場合、あなたはスクラムをしていません。

修正が必要な問題が何であれ、時間を要求してください。最初に何かをやり直す時間が必要だと思いますか？見積もりに組み込みます。それをする余裕はありますか？

少しの間アジャイルを脇に置いて、あなたが何をしているかを調べてみましょう。

計画を立てるとき、開発時間の観点から簡単な解決策を探します。たとえば、新しいダイアログなどを作成する場合は、以前のjqueryを使用します。きちんと整理して反応に変換しますが、それはめったに起こりません。

これは「技術的負債の取得」と呼ばれます。Martin Fowlerは、「Reckless vs. Prudent」と「Deliberate vs. Inadvertent」という2つの軸に沿った彼のブログ投稿で「技術的負債の象限」について説明しました。

明示的な目標の1つ（つまり、単一ページのアプリ）からさらに離れた、既知の古いテクノロジーjquery を使用することを明示的に決定します。これを行うと、「迅速に」配信されます。これは故意です。

この「すばやく」計算に含まれないのは、後で反応する機能を実装する必要がある時間です。速度が重要であるという評価に基づいて、正しいものであることがわかっている代替案よりも欠点のある代替案を選択します（つまり、反応に機能を実装するのに時間がかかります）。これは無謀です。

マーティン・ファウラーは、このような借金を「設計する時間がない」と述べています。これは、コードを維持したり、数日以上コーディングしたりする予定がない環境での適切な選択です。ただし、プロジェクトは、顧客のメンテナンスを明示的に含む長期実行プロジェクトです

あなたがしていることは、非常に基本的なレベルでは間違っています。それは悪いエンジニアリングです！

技術的な負債を引き受けました。この負債は返済する必要があり、利子を請求することを無視しました。そして、あなたの借金の金利がスプリント中に利用可能な仕事に近づき始めるまで、あなたはそれを続けました。

あなたがするべきことは借金のレベルを減らすことです。上司と話し、クライアントと話します。昨日、保守性に取り組む必要があります。

アジャイルの使用をやめる...

むしろ、純粋にアジャイル（またはスクラムなど）が指示するものであるため、特定の方法で何かをしようとするのをやめることです。これらの用語の1つの（誤った）解釈を間違った段階でプロジェクトに適用しようとすると、すぐに最悪の行動方針になります。代わりに理由を使用してください。

あなたのプロジェクト、そして世界の他のほとんどすべてのプロジェクトが、コードの混乱と多様なアプローチである理由は、一元化された全知のアーキテクチャ設計の欠如によるものです（私はそれを言った）。

これが欠けている理由は次のとおりです。

• 建築家には専門知識がありません（最初の10の趣味プロジェクトのように）
• 建築家には時間がありません
• アーキテクトには権限がありません（マネージャーは「いいえ」または「はい」と言いますが、一部の部分のみ）
• チームは、それらを救うブードゥー教の方法論に信仰を持っています（アジャイルを使用しているため、それ自体がすべて無効になります）

簡単な解決策は、これらすべての魔法の言葉を落とし、状況の現実を見ることです。これは次のように要約できます。

1. コードの状態は、チームが時間通りに、バグなしで提供する能力を妨げています。
2. 機能を追加すればするほど、機能は悪化します。
3. したがって、一時停止、再評価、および（おそらく大幅に）パーツを再設計することは本当に理にかなっています。

そもそもなぜこの状態になったのか、そして非難の指がぐるぐる回ってくるので、自然に質問するようになるでしょう。答えは、これは避けられないということです。設計が成熟するにつれて、別のやり方でやるべきであると気づきますが、それを予見することはできませんでした。さらに、これはプロジェクトごとに1回の実現ではなく、数回発生するため、計画を立てる必要があります。

そうは言っても、事態を悪化させるためにマネージャーができることはたくさんあります。

1. 開発者を締め切りまでに死の行進。
2. 開発者はチケットに対して時間を記録するだけで、「思考、統合、品質のリファクタリング」のチケットがなく、それらの時間に余裕があると述べています。
3. 誰にもアーキテクチャーの所有権を与えないで、それを十分に理解する
4. その人が必要だと思う変更を加えることを許可しない

このように見れば、アジャイルとスクラムのいくつかの解釈が実際にこのルートをさらに速く進んでいく様子を簡単に見ることができます！

1つのアプローチは、リファクタリングの各ビットに対してチケットを作成することです。問題は、小さなチケットで作業を開始するまで大きなリファクタリングが必要であることに気付かないことが多いことです。

別のアプローチは、チームの能力の25〜50％のみを使用するようにスプリントを計画することです。その後、開発者は実際のチケット（リファクタリングなしでかかったはずの時間を記録する）とリファクタリング時間（1週間に1つの大きなチケット、承認ループなし、開発者間の議論のみ）に時間を記録します。リファクタリングがない場合は、来週のスプリントからチケットをプルできます。プロジェクトの基礎となるコードが改善されたら、今後数週間のパーセンテージスライダーを調整します。

「私たちは何を間違っているのか」と答えるために、常識よりも方法論に信頼を置いていると思います。「この問題に対するアジャイルなアプローチ」を求めさえします。言葉を落として、実際の問題について考えてみよう。その後、最終的な常識的なアプローチが実際に「アジャイル」または「スクラム」の装いに該当するかどうかを解読しようとするさまざまなマニフェストを本当に分離したい場合は、ぜひ行ってください:-)

あなたは何も悪いことをしていません。この種の方法論は、仕様にできるだけ早く機能を提供するように設計されています。

あなたが目指している二次的な目標がある場合は、「非機能要件」または「完了の定義」として表現するのが最善です。

たとえば、非機能要件がある場合があります。

「すべての新機能はReactで作成する必要があります」

そして

「すべての非同期呼び出しは、ロードスピナーとエラー処理を実装する必要があります」

製品所有者（または同等のもの）に、開発者が気に入ったためにこっそり入るのではなく、やりがいのあることであることに同意してもらうだけです。