YAGNIの原則に従わないスクラムチーム
SCRUMミーティングで、製品チームは、モバイルアプリによって使用されるAPIの機能について議論していました。画面の外観と画面に含まれる主要な要素（「レイアウト」）を示すモックアップを用意しました。
これと製品所有者との話し合いに基づいて、API応答（HAL + JSON）のプロトタイプを作成しました。それは、モックアップにあるものを表す以外に何もしない、非常にシンプルなHAL準拠のJSONでした。ビジネスマンは頻繁にアイデアを変更する傾向があるため、将来予測されるアイデアに影響を受けることはなく、最小限のアプローチを取ることにしました。私の提案はチームによって拒否され、7対1で投票されました。
チームは、レイアウトをより柔軟に配置できる、より複雑で非セマンティックな抽象json構造を使用することを決定しました。このアプローチの欠点は、設計上、nullおよび空のプロパティを持つ可能性のある均一なオブジェクトのセットになってしまうことです。彼らはまた、A/Bテストを可能にするのは良いことだと思っていましたが、それは私たちがそのような要件を持っていなかったため、彼らの予測に基づいていました。
ほとんどの場合、スプリントの一部ではなく、モックアップで言及されていないものについて議論していました。記述された問題は、「将来のマーケティングがどうなるか...」、「ビジネスが私たちに望んでいるかどうか...」でした。
私と製品の所有者は経験豊富なプログラマーであり、過去にこの種の問題を見てきました。 [〜＃〜] yagni [〜＃〜] と [〜＃〜] kiss [〜＃〜] の原則に従っています。チームの他のメンバーは少し経験が少なく、これらの原則を知っていますが、それらを理解していないようです。
チーム全体が私たちにとってより重要であり、それほど重要ではない何かをめぐって戦いたくなかったので、私たちは彼らの解決策に同意しました。しかし、私はそのようなことが今後のより複雑な議論の先例になることができるのではないでしょうか？そのような行動にどう対処するのですか？チームリーダーとして私がもっと上手くできることはありますか？
この製品は初期のMVPであることは言うまでもありません。
私はあなたの痛みを感じ、そこにいました。私見これらの種類の問題はあなたが8人のチームを持っているという事実によって引き起こされます、それはあなたが常に最高の戦略的決定に来るのを許すには大きすぎます。
サイズが8以上のチームでは、可能性が高いため、経験のあるプログラマーの数よりも平凡なプログラマーの数が多くなります。それはしばしば、より良い決定が平凡なものによって支持される状況につながります。特にあなたがより経験豊富な人の1人である（またはあなたがそうであると思う）場合は、それは満足のいくように聞こえませんが、少なくとも同じことが本当に悪い決定に対してしばしば当てはまります。
事実はチームが変わらない限り、あなたができることはそれほど多くない、少なくとも物事が民主的であり続けるなら、
- それとともに生きることを学ぶ
- チームと1〜2年間作業し、自分の専門知識を共有して、YAGNIの価値と、KISS
- チームへの「販売」設計または戦略的決定の独自のスキルに取り組みます
- 自分の専門知識のレベルがチーム全体の平均に近い別の（おそらく小規模な）チームに切り替えようとする
ミニマルなアプローチとYAGNIの真の価値を学び、理解する唯一の方法は、いくつかの経験を直接体験することだと思います。たとえば、多くの誤った「what if」予測、「ジャストインケース」引数によって動機付けられた誤った設計決定、または実際には決して必要とされない多くの過度に一般化されたフレームワークコードを含むレガシーシステムの保守に関与することによって。しかし、それは2日間でチームメンバーに教えることができるものではありません。人々が自分で作らなければならない経験もあります。
前方互換性は正当な懸念事項です
あなたに賛成した7人の開発者の1人がアーキテクトである場合、必要に応じて NFRs を導入するのは彼の権利であり、特にリモートシステムをサポートしている場合、それらのNFRの1つが「前方互換性」になる可能性があります。より疎なリリーススケジュールを持つ可能性のあるコンポーネント。前向きに考えていなかったため、ユーザーにアプリの新しいバージョンをインストールしてもらう必要はありません。
他の要件と同様に、受け入れ基準が必要です
とはいえ、NFRは要件として文書化され、定義されている必要があります 受け入れ基準 。また、 それらをテストする手段 を考え出す必要があります。 YAGNIが重要なのはそのためです。テストできないコードを記述したくない場合、そしてコードの唯一の目的が誰も使用していない機能をサポートすることである場合、テストすることは困難です。
それは裁判の呼びかけであってはならない
チームがあなたが明らかに見逃した暗黙の要件に同意し、それを書き留めてもらうことをお勧めします。テストの手段を定義したら、実装は少なくとも1つのテストに失敗するはずなので、投票の問題にはなりません。
開発チームが製品チームを迅速に試行できるフレームワークを作成することで製品チームを促進しようとしているようです。これは明らかに製品チームが本当に望んでいることです。あなたのアプローチは、「彼らが求めているものを文字通り与え、彼らのために考えていない」というようなものです。
私が製品の所有者であれば、開発チームが最初のアプローチを採用するよりも、開発チームの方がはるかに幸せになるでしょう。
YAGNI AND KISSの問題は、彼らが完全に主観的で曖昧であることです。
json ?? YAGNI！ CSV文字列を送信するだけです！
オブジェクト?? KISSTUPID !!!ゴトスを使うだけ!!
「チームリーダー」の役割は明確に定義されていませんが、チームの技術的な選択について主観的な意見を表明することから遠ざけることをお勧めします。あなたが彼らが間違っていると感じたとしても。明確に定義された要件の短いリストに固執する。
- コードの単体テスト
- aPIの統合テスト
- 最終製品の自動UIテスト
- パフォーマンスとスケーリングの要件
チームがすべてのビジネス要件と大規模な技術要件での基本的なパフォーマンスのテストに合格できた場合、製品として機能します。
その後、同じことをするだけで速くなります
まあ、私の意見は、民主主義は適切に機能していないということです-政治システムでも、ほとんどのプログラマーがジュニアまたは平凡であるチームでも。
チームリーダーであり、チームで最も経験豊富な人々の1人であるあなたの言葉は、チームの他のメンバーよりも大きな影響力を持つべきです。 YAGNIが重要な場合は、それについてプレゼンテーションを行う必要があります。それについて話し合い、なぜそれが良いのかを示してください。
結局のところ、あなたの責任は他の人よりも高いです。コードを書くだけでなく、人々を導くことでもあります。
YAGNIについては少し混乱があると思います。
開発者は、システムを「変更のために閉じて拡張のために開いている」状態に保つ抽象化を省略した場合、YAGNIに従うと考えることがよくあります。
「明らかに」要求されていない機能でシステムを「拡張」しない限り、YAGNIは扱いません。拡張が発生する可能性がある場所での抽象化の導入は、すでに述べた「前方互換性」です。
私の個人的な見解では、ドメインの深い知識だけが抽象化の決定とそれをどこに配置するかを決定するのに役立ちます。
これについての私の最初の考えは...なぜチームは変更を懸念しているのですか？彼らは、将来の拡張を容易にするために最初のソリューションをもう少し設定しやすくする必要があると感じさせる、プロダクトオーナーの歴史的な理解を持っていますか？ソリューションに2日、5日かかる場合、はい、2倍以上かかります。ただし、プランの変更に毎回2日かかるが、それらの拡張に1日かかる場合、それらのプランは長期的にはより効率的に見えます。私はこの質問で正しいか間違った決定があるとは思いません。それは他の要因、私見に依存します。ただし、他のソリューションでそれを行うための直接のガイダンスなしにLOEが2倍になる場合は、この考え方について正しい（スケーラビリティ、堅牢性などのために追加の複雑さが必要であることを示す証拠）。私は、優先順位付けを支援する必要があるため、製品の所有者をこれらの会話に参加させることをお勧めします。あなたのソリューションが5ポイントであり、それが今のニーズを満たしているが、彼らがやりたいことは50ポイントと2回以上のスプリントが必要な場合、POは「保留、このMVPの高優先リリースを計画しており、ロードマップにない機能の構築に2週間を費やすことはできません！」