アジャイル-私たちが間違っていることは何ですか？
私はアジャイルチームの開発者です。私たちはスクラムを使用しようとしています。
そこで、状況を説明するために架空の問題を取り上げます。
非常に古いアプリがあり、面倒で保守性の悪いJQueryコードを使用しています。 Reactを使用するアプリの部分もあり、それらの部分は更新/保守がはるかに簡単です。それ以外に、会社の目標はReactでクライアントの単一ページのアプリを作成することです。そのため、JQueryを使用すると、さらに離れることができます。
計画を立てるときは、常に開発時間の観点から簡単な解決策をとります。たとえば、新しいダイアログや何かを作成する場合は、古いJQueryを使用します。なぜなら、その方が速いので、戻ってきたと言っているからです。後で片付けてReactに変換しますが、それはめったに起こりません。
ユーザーストーリーから、私たちがしなければならないことの要件を取得します（IMOはよくできており、IMOはスリムですが、私たちが何をしているか、なぜそれをしているのかを説明します）。
場合によっては、新機能の要件が非常に細いことがあります。たとえば、要件が「大量のコンテンツを読み込むダイアログを作成する」であるが、読み込み機能を実装するように言っていない場合、ほとんどの場合、実装しません、私たちは皆、それが顧客にとってより良いことを知っていますが、これがスプリントの目標を損なう可能性があるという理由で（私は個人的にはそうではないと信じていますが）。
その結果、私たちのコードベースは保守性が非常に悪い大きな混乱であり、新しい機能は時々非常に小さく、完全なスプリントが必要です（優れたコードベースで1日で達成できるもの）。これは主にこの開発が原因です。戦略は、ただ速く、最小限に抑えます。
この場合、何が悪いのでしょうか。先週書いたばかりのコードを書き直したり、コードを書き直したりしないように、より完全な方法でソリューションに取り組む必要がありますか？それとも、コードがすべて書き換えられていることを確認するだけでよいのでしょうか。この問題に対する優れたアジャイルアプローチは何でしょうか。
これはアジャイルやスクラムとは関係ありません。
「今すぐテープを貼って後で修正する」の問題は、後で来ることは決してないということで、その間にたくさんの情報を蓄積している 技術的負債 。
回復の最初のステップは、問題を認識し、悪化をやめることです。
チームはすべての新しいユーザーストーリーについて、「これをハッキングする最も速い方法は何か」ではなく、「これをコーディングする正しい方法は何か」を検討する必要があります。それに応じてスプリントを計画します。
既存の問題を解決するには、 私はスパゲッティコードの200K行を継承しました—今はどうですか？
あなたが持っているのは、Martin Fowlerが "flacid scrum"と呼ぶものです。
すべてを正しく読んだ場合 アジャイルマニフェストの背後にある12の原則 を読むと、ほとんどの場合失敗することがわかります。
作業期間の短いソフトウェアを優先して、数週間から数か月の作業用ソフトウェアを頻繁に配信します。
本当に機能するソフトウェアを提供していると言えますか？または、ほとんど動作しないソフトウェアだけですか？
アジャイルプロセスは持続可能な開発を促進します。スポンサー、開発者、およびユーザーは、一定のペースを無期限に維持できる必要があります。
あなたのプロセスは持続可能なと言えますか？持続可能性を念頭に置いて意思決定を行っていますか？または、長期的な影響を考慮せずに現在の問題を解決するソリューションを選択しますか？
卓越した技術と優れたデザインへの継続的な注意が俊敏性を高めます。
本当に主要な原則。これはページの大きな赤い文字に入れるべきだと思います。これが最も失敗する場所です。
定期的に、チームはより効果的になる方法を検討し、それに応じてその動作を調整および調整します。
そして、明らかに。自分の行動が望ましい結果につながらないことがわかった場合は、それを変更する必要があります。問題が発生していることがチームで確認できない場合は、修正を開始できません。
あなたのコメントから
アジャイルでそれを予防する方法は？
まず、アジャイルが実際に何であるかを学ぶことによって。スクラムはアジャイルではありません。正確な状況に到達するのは簡単すぎるため、スクラムはアジャイルフレームワークの中で最悪だと言う人もいます。他のアジャイルフレームワークについて学ぶ必要があります。私がお勧めするのは、エクストリームプログラミングです。これは明らかにあなたの問題を解決します。ソリューションは単純ではありませんが（堅牢な自動テスト、ペアプログラミング、継続的デリバリーを通じて卓越した技術に焦点を当てています）、非常に効果的です。 State of DevOps report で報告されています。
あなたが説明するのは-少なくとも私の経験ではアジャイルになる）ことを試みるチームのかなり---（一般的な緊急パターンです。これが実際にアジャイル自体の一部である場合、またはアジャイルの一般的な誤実装である場合、アジャイルマニフェスト/原則またはその固有の結果に反する場合などは、議論の余地があります。経験的観点から、そして私自身の小さなサンプルセット（および私が話す人々）に基づいて、チームが俊敏である場合、このパターンに遭遇する可能性は平均より高いようです。そのままにして、具体的な例に焦点を当てましょう。
あなたが説明するものには2つの別々の側面があります：
- 共通の理解やビジョンが欠けているため、効率的ではない
- 成功/進捗状況と総コストを測定する方法
間違った道を行くか、輪になって走る
私の経験では、これが発生する主な理由は次のとおりですコードを迅速に作成するために、チームはすでに知っているユースケースや要件を積極的に脇に置きますまたは簡単に見つけることができます。このように考えてください。10〜20年前、人々は巨大な仕様を書いてすべてを事前に考えようとして、失敗することがよくありました。彼らは時間がかかりすぎるか、何かを見落としました。過去の教訓の1つは、ソフトウェア開発ではわからないことがあり、物事は大きく変化するため、すばやく反復して適切な出力をすばやく生成するという考えです。これは非常に良い原則です。しかし、今日、私たちは別の極端な状況にあります。「次のスプリントの一部なので、これは気にしません」または「そのバグを報告せず、再び現れたときに対処します」。私のアドバイスは：
- すべての高レベルのユースケースを収集する、要件、依存関係、および制限を見つけることができます。すべての利害関係者と開発者がそれらを見ることができるように、それをいくつかのwikiに入れてください。新しい何かが出てきたときにそれらに追加します。株主やユーザーと話し合いましょう。これを開発中のチェックリストとして使用して、最終製品に寄与しないもの、または1つの問題を解決するが3つの新しい問題を引き起こす回避策/ハックを実装しないようにします。
- 高レベルの概念を作成します。私はインターフェースやクラスの設計について話しているのではなく、問題の領域を大まかにスケッチしています。最終的なソリューションの主な要素、メカニズム、相互作用は何ですか？あなたのケースでは、jquery-workaroundが中間ステップとして役立つ場合と、それが追加の作業のみを引き起こす場合を明らかにする必要があります。
- コンセプトを検証します収集したリストを使用します。そこに明らかな問題はありますか？それは意味がありますか？テクノロジーに長い借金をすることなく、同じユーザー価値を実現するより効率的な方法はありますか？
無理しないでください。チームの全員（開発者以外を含む）がMVPへの最適なパスが何であるかを共通に理解できるように、何かが必要です。誰もが明白な見落としはなく、それが実際に機能する可能性があることに同意する必要があります。これは一般に行き止まりに陥ったり、同じことを何度もやり直したりするのを防ぐのに役立ちます。アジャイルは、予期しない事態への対処を改善するのに役立ちます。既知のことを無視することは議論の余地はありません。
sunk-cost-fallacyに注意してください。1つのアーキテクチャまたはデータベースタイプから始める場合、ほとんどの人はプロジェクトの途中で変更することをためらっています。したがって、何かを実装する前に、「教育された最良の推測」を得るために時間を費やすことをお勧めします。開発者は、コードをすばやく記述したい傾向があります。しかし、いくつかのモック、ライブプロトタイプ、スクリーンショット、ワイヤーフレームなどがあると、コードを書くよりも高速に反復できます。書かれたコードのすべての行、または単体テストでさえも、全体的な概念を再び変更することが難しくなることに注意してください。
成功の測定
完全に別の側面は、進行状況を測定する方法です。プロジェクトの目標が、身の回りにあるものを使用して高さ1mのタワーを構築することだとします。カードの家を建てることは、たとえば市場投入までの時間が安定性よりも重要である場合、完全に有効なソリューションになる可能性があります。あなたの目標が長続きするものを作ることであるなら、レゴを使うほうが良いでしょう。ポイントは次のとおりですハックと見なされるもの、およびエレガントなソリューションがプロジェクトの成功の測定方法に完全に依存するもの。
「読み込み」の例はかなり良いです。私は過去にこのようなものを持っていましたが、すべての人（販売、PO、ユーザーを含む）が煩わしいことに同意しました。しかし、それは製品の成功に影響を与えず、長期債務を引き起こしませんでした。したがって、dev-resourcesを使用するためのより価値のあることがあったので、それを削除しました。
ここでの私のアドバイスは：
- チケットシステムのチケットとして、小さなバグも含めてすべてを保持します。プロジェクトのスコープ内にあるものとないものを積極的に決定します。マイルストーンを作成するか、バックログをフィルタリングして、実行する必要があるすべての「完全な」リストを常に取得できるようにします。
- 重要な順序を厳格にし、カットオフポイントを明確にするプロジェクトが成功したと見なすことができる場所。最終的な製品に実際に必要な安定性/コード品質/ドキュメントのレベルはどれですか？上から選んで、毎日の仕事をできるだけよく過ごすようにしてください。 1つのチケットで作業するときは、新しいチケットを導入せずに完全に解決するようにしてください（優先度が低いために延期することが理にかなっている場合を除く）。すべてのコミットは、横方向や逆方向ではなく、最終目標に向かって前進する必要があります。しかし、もう一度強調します。後で追加の作業を行うハッキングは、プロジェクトにとって正味の可能性があります。
- PO /ユーザーを使用してユーザーの価値を把握しますただし、開発者にも技術コストを把握してもらいます。非開発者は通常、真の長期的なコスト（実装コストだけでなく！）を判断できないため、支援します。沸騰カエルの問題に注意してください。多くの小さな無関係な問題が、時間の経過とともにチームを停滞させる可能性があります。チームの作業効率を数値化してみてください。
- 全体的な目標/コストを監視します。むしろ、スプリントからスプリントまで考えるのではなく、「チームとして、プロジェクトの終わりまで必要なすべてのことを私たちができるか」という考え方を守ってください。スプリントは、物事を分解し、チェックポイントを持つための単なる方法です。
- 何かを早く表示したいのではなく、コースを最小の実行可能な製品への最短経路でプロットしますユーザーに与えることができます。それでも、全体的な戦略は、その間に検証可能な結果を可能にする必要があります。
したがって、誰かが最終的な実装目標に合わないことをするときは、理想的には話が終わったとは考えないでください。ストーリーを閉じることが有益である場合（たとえば、顧客からのフィードバックを得る場合）、すぐに新しいストーリー/バグを開いて、短所に対処します。ショートカットを実行してもコストが削減されるのではなく、非表示または遅延になることを明確にします。
ここでの秘訣は、プロジェクトの総コストについて議論することです。たとえば、POが期限を設けるためにショートカットを取るよう要求した場合、プロジェクトが完了したと見なすために後で実行する必要がある作業の量を定量化します。
criteria-based-optimisationにも注意してください：チームがスプリントレビューで表示できるストーリーの数によって測定される場合、良い "スコア"を達成するための最良の方法は、すべてのストーリーをカットすることです10の小さなもの。書かれた単体テストの数で測定すると、不要なものをたくさん書く傾向があります。ストーリーを数えるのではなく、必要なユーザー機能がどれだけ機能するか、プロジェクトの範囲内で解決すべき技術負債によるコストがどれほど大きいかなどを測定してください。
概要
簡単に言うと、最小限にとどめることが良いアプローチです。 T 彼は「高速」と「最小」の解釈に問題があります。長期的なコストを常に考慮する必要があります（これが無関係のプロジェクトがない限り）。 1日しかかからないが、出荷日から1か月の技術負債を生み出すショートカットを使用すると、1週間かかったソリューションよりも会社のコストが高くなります。すぐにテストを書き始めるのは速いようですが、コンセプトに欠陥があり、間違ったアプローチを固める場合はそうではありません。
そして、あなたの場合の「長期」の意味を覚えておいてください。私は、優れたコードを書こうとしたために失敗して出荷が遅れた企業が複数あることを知っています。 会社の観点から見ると、優れたアーキテクチャまたはクリーンなコードは、それを達成するためのコストが、それを持たない場合のコストよりも少ない場合にのみ価値があります。
お役に立てば幸いです。
厳密にはスクラムの観点からすると、あなたが間違っているのは、あなたが働いていないということですwithクライアント。あなたはクライアントと一緒に働き、彼らが何を必要とするであるかだけでなく、必要とするを理解する必要があります。一連の迅速な修正が必要ですか、それとも長期的にサービスを提供する安定した保守可能なシステムが必要ですか？それを判断するのは難しい場合がありますが、品質は背景色やパフォーマンスベンチマークと同じくらい多くの要件です。安定性と保守性は自由ではなく、製品に組み込む必要があることをお客様は認識しておく必要があります。
彼らが前者であると彼らが言うなら、あなたは彼らの目標を達成するためにエンジニアリングのコーナーを切り詰めていることをスプリントレビューで彼らに説明していると仮定して、あなたは何も間違っていません。
彼らが後者だと彼らが言うなら、あなたが間違っているのはあなたが彼らに彼らが望むものを与えていないということです。
スクラムの基礎の1つは透明性です。スクラムをしている場合は、顧客と一緒にスプリントレビューを行う必要があります。これらのレビューでは、ソフトウェアをより早く提供するために手を抜くことを顧客に伝えていますか？そうでない場合は、そうする必要があります。適切なレベルの品質でソフトウェアを提供しているかどうかについて情報に基づいた決定を下す機会を顧客に与えるために、設計の選択の影響について顧客に100％明確にする必要があります。
ユアンは正しい。経営陣がスクラムを好む理由は、スタッカートスタイルの機能を要求し、結果をすばやく得ることができるためです。結果として生じる混乱が他の誰かの問題になるまで。
今、あなたの注意を引いたので、説明させてください。それ自体はスクラムではありません。彼らはプレッシャーを感じているため、合理的で現実的な見積もりを出すことができないのは、強力な製品マネージャーと弱い開発チームの典型的な設定です。したがって、彼らははるかに楽観的な見積もりを出し、時間内に納品するために手抜きをしてトラブルに深く入り込みます。
スクラムでは、（開発者として）自分で計画を立てます。一部の機能をx日で提供するように指示されている人はいません。誰かがx日で配達するように言っているなら、あなたはスクラムをしていません。
修正が必要な問題が何であれ、時間を請求してください。最初に何かをやり直すには時間が必要だと思いますか？見積もりに組み込んでください。あなたはそれをする余裕がありますか？
少しアジャイルを脇に置いて、あなたが何をしているか調べましょう。
計画を立てるときは、開発時間の観点から簡単な解決策に取り掛かります。たとえば、新しいダイアログや何かを作成する場合は、古いjqueryを使用します。その方が速いので、後で戻って片付けて反応に変換しますが、それはめったに起こりません。
これを「技術的借金」といいます。マーティン・ファウラーは、「技術的借金の四分儀」を2つの軸に沿って 彼のブログ投稿 で説明しました：「無謀vs.慎重」と「故意vs.不注意」。
既知のoldテクノロジーjqueryを使用して、明示的な目標の1つから遠ざけることを明示的に決定します（つまり、単一ページのアプリ）。これを行うと、「迅速に」配信されます。これは意図的です。
この「すばやく」の計算に含まれていないのは、後で機能を実装するために必要な時間です。速度が本質的であるとの評価に基づいて、あなたがknowである代替案よりも欠点だけがある代替案を選択します（つまり、機能を実装するために時間をかけて）。これは無謀です。
マーティンファウラーは、「このような設計の時間がない」の下で、この種の負債を要約しています。これは、コードを維持することを期待していない、または数日以上コードを期待することさえない環境では適切な選択です。ただし、このプロジェクトは長期にわたって実行されるプロジェクトであり、顧客のメンテナンスが明示的に含まれています
あなたがしていることは、非常に基本的なレベルでwrongです。 悪いエンジニアリングです！
あなたは技術的債務を引き受けましたが、この債務は返済する必要があることを無視し、利息を請求します。そして、あなたはあなたの借金の利子率があなたのスプリントの間にあなたの利用可能な仕事に近づき始めるまでそれをし続けました。
あなたがすべきことは借金の水準を下げることです。上司と話し、クライアントと話します。あなたは昨日保守性に取り組む必要があります。
アジャイルの使用をやめるだけです...
それどころか、純粋に特定の方法で何かをしようとするのをやめるのは、それがアジャイル（またはスクラムなど...）が要求するものだからです。これらの用語の1つの（誤った）解釈を間違った段階のプロジェクトに適用しようとすると、すぐに最悪の行動方針になる可能性があります。代わりに理由を使用してください。
あなたのプロジェクト、そして世界の他のほとんどすべてのプロジェクトがコードの混乱と分岐アプローチである理由は、一元化された全知的なアーキテクチャー設計の欠如によるものです（私はそれを言った）。
これが欠けている理由は次のとおりです。
- 建築家には専門知識がない（最初の10の趣味プロジェクトのように）
- 建築家には時間がありません
- 建築家には力がありません（マネージャーは「いいえ」または「はい」と言っていますが、一部についてのみ）
- チームはそれらを救うブードゥー教の方法論を信じています（アジャイルを使用しているため、すべてが解決されます）
簡単な解決策は、これらすべての魔法の言葉を落とし、状況の現実を見てみることです。これは次のように要約できます。
- コードの状態は、チームが予定通りにバグを発生させずに実行する能力を妨げています。
- 追加する機能が多ければ多いほど、悪化します。
- したがって、部品を一時停止、再評価、および（おそらく大幅に）再設計することは、本当に理にかなっています。
そもそもなぜこの状態になったのかと問うようになると、責めの指がぐるぐる回る。答えはこれが避けられないということです。設計が成熟するにつれて、別の方法で実行する必要があることに気付きますが、それを予測することはできませんでした。さらに、これはプロジェクトごとに1回の実現ではなく、何度か発生するため、計画を立てる必要があります。
とはいえ、管理者が事態を悪化させるためにできることはたくさんあります。
- 開発者を締め切りに追い詰める。
- 開発者は「思考、統合、および品質のリファクタリング」のチケットがなく、チケットに対する寛大な時間の余裕がない場合にのみ、チケットに対する時間を記録できると述べています。
- 誰もがそれを処理するのに十分な期間、アーキテクチャの所有権を誰にも与えない
- その人が必要だと思う変更を加えることを許可しない
これをこのように見ると、アジャイルとスクラムのいくつかの解釈が実際にどのようにしてこのルートをさらに速く進むかが簡単にわかります。
1つのアプローチは、リファクタリングのビットごとにチケットを作成することです。問題は、小さなチケットで作業を開始するまで大きなリファクタリングが必要であることに気付かないことが多く、これにより締め切りが後押しされ、チケットが承認ループを通過するため、すべてが遅くなるだけです。
別のアプローチは、チームの容量の25-50％のみを使用するようにスプリントを計画することです。次に、開発者は実際のチケットに時間を記録し（リファクタリングを行わずに必要な時間を記録）、リファクタリング時間（1週間に1つの大きなチケット、承認ループなし、開発者間の議論のみ）を記録します。リファクタリングがない場合は、来週のスプリントからチケットをプルできます。プロジェクトの基礎となるコードが改善されるにつれて、今後数週間の割合スライダーを調整します。
したがって、「私たちが間違っていることは何ですか」と答えるには、常識よりも方法論を信頼していると思います。 "この問題へのアジャイルアプローチ"も要求します。私は言葉を落とし、実際の問題について考えます。あなたが本当にあなたの最終的な常識的なアプローチが本当に「アジャイル」または「スクラム」の偽装に該当するかどうかを解読しようとしているさまざまなマニフェストを本当に分けたいなら、ぜひそれを試してください:-)