スクラムチームは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人がアーキテクトである場合、必要に応じてNFRを導入することが彼の権利であり、それらのNFRの1つは「前方互換性」になる可能性があります。リリーススケジュール。前もって考えていなかったので、ユーザーがアプリの新しいバージョンをインストールする必要はありません。

他の要件と同様に、受け入れ基準が必要です

つまり、NFRは要件として文書化され、受け入れ基準が定義されている必要があります。また、それらをテストする手段を考え出す必要があります。YAGNIが重要なのはそのためです。テストできないコードを書きたくないので、コードの唯一の目的が誰も使用していない機能をサポートすることである場合、テストするのは困難です。

判断の電話であってはなりません

あなたが見逃したと思われる暗黙の要件についてチームに同意してもらい、それを書き留めておくことをお勧めします。テストする手段を定義したら、実装は少なくとも1つのテストに失敗する必要があるため、投票の問題ではないはずです。

開発チームが迅速なトライアルを可能にするフレームワークを作成することで製品チームを促進しようとしているようですが、これは製品チームが本当に望んでいることのようです。あなたのアプローチは、「文字通り彼らに彼らが求めているものを与え、彼らのために考えていない」に似ています。

私がプロダクトオーナーであれば、開発チームが後者よりも最初のアプローチを取る方がずっと幸せになるでしょう。

私の意見では、民主主義は適切に機能していません-政治システムでも、ほとんどのプログラマーが下級または平凡なチームでも。

チームリーダーとして、そしてチーム内で最も経験豊富な人の1人としてのあなたの言葉は、チームの他の部分よりも大きな影響を与えるはずです。あなたにとってYAGNIが重要な場合は、それについてプレゼンテーションを行う必要があります。それについて議論し、なぜそれが良いのかを見せてください。

結局のところ、あなたの責任は他の人よりも高くなります。コードを書くだけでなく、人々を導くことでもあります。

YAGNIについて少し混乱があると思います。

開発者は、システムを「修正のために閉じ、拡張のために開いたままにする」抽象化を省略すると、YAGNIに従うと考えることがよくあります。

「明らかに」要求されていない機能を使用してシステムを「拡張」しない限り、YAGNIを処理しません。拡張が発生する可能性のある抽象化の導入は、すでに述べた「前方互換性」です。

私の個人的な意見は、ドメインの深い知識だけが抽象化の決定とその場所を決定するのに役立つということです。

YAGNI AND KISSの問題は、それらが完全に主観的で曖昧であることです。

json ?? ヤグニ！csv文字列を送信するだけです！

オブジェクト?? KISSTUPID !!! ただgotoを使用してください!!

「チームリーダー」の役割は明確に定義されていませんが、チームの技術的な選択について主観的な意見を表明することから距離を置くことをお勧めします。間違っていると感じても。明確に定義された要件の短いリストに固執します。

• コードの単体テスト
• APIの統合テスト
• 最終製品の自動UIテスト
• パフォーマンスとスケーリングの要件

チームがすべてのビジネス要件および大規模な技術要件での基本的なパフォーマンスのテストに合格することができれば、動作する製品があります。

その後、同じことをしますが、より高速になります

チームの全員がdoneの定義に同意しなければなりません。これがないと、スコープのクリープ、視点、および中核要件の粗悪化が大量に発生しやすくなります。

これ以上に配信されるものはすべて、バックログ上に存在する必要があり、バックログ自体にも完了の独自の定義があります。

優先順位については、MoSCoWメソッドが常に役立っています-YMMV。

私がこれについて最初に考えたのは...なぜ変更を心配しているのですか？プロダクトオーナーについての歴史的な理解があり、将来の拡張を容易にするためにもう少し構成可能な最初のソリューションを構築する必要があると感じていますか？ソリューションに2日かかり、それらのソリューションに5日かかる場合、はい、2倍以上かかります。しかし、計画の変更に毎回2日間かかり、それらの機能強化に1日間かかる場合、計画は長期にわたってより効率的であるように見えます。この質問に正しい決定や間違った決定があるとは思わない。それは他の要因、私見に依存します。ただし、他のソリューションでLOEを2倍にした場合、そのような直接的なガイダンスがなければ、この考え方については正しいです（スケーラビリティ、堅牢性などに追加の複雑さが必要であるという証拠）。私の提案は、優先順位付けを支援する必要があるため、これらの会話に製品所有者を連れてくることです。ソリューションが5ポイントであり、現在はニーズを満たしているが、彼らがしたいことは50ポイントと2スプリント以上を必要とする場合、POは「保留、このMVPの優先度の高いリリースを計画しており、ロードマップにない機能の構築に2週間費やすことはできません！」