クリアな問題点を確認する
—— 昔のやり方とアジャイルとで比べると、違いはありますか?
角谷 昔のやり方では、問題があったとき、「誰のせいなのか」「どこで処理するか」という話になることが多かったです。要求エラーか実装エラーかを判断できませんでした。いまは実装のエラーはほとんどなく、考慮しない使い方とか、そういう部分がエラーになっています。
—— するといまの方が問題は明らかな感じですね。
角谷 そうですね。「あーそれは考慮してないわ」「それは伝えてないからね」というような(笑)。
猪狩 伝えたものは大体テストされます。こちらが思い込みで伝わっているというのがあったりするけれど、思い込みで伝わらないところはウォーターフォールでも伝わらないだろうし。それに自分が想定していないならそれを設計するのはできません。要求ミスはいままでとあまり変わらないかなと。イテレーションごとに議論して問題や新しい使い方を見つけ出すことができています。最初に書いて出しちゃうとレビューしたってそんなには見つけられません。
これ大事。
何が問題なのかを明らかにするプロセスをばっさり省略できるってデカイ。
※ 引用と本文の比率的には著作権法に反したエントリになってしまった。
More
Recent Posts
- » LLMアプリをLLMを使いながら作ってみた
- » Gemini Advancedでもうゲームが変わっていた
- » 今さらLLMのモデルの違いとプロンプトエンジニアリングについて
- » Bundler環境でIRBでもLSPでもドキュメントを利用する方法
- » Ruby 3.2と3.3のirb historyの扱いの違いと対処方法
- » Result型とRailway Oriented Programmingをめぐる旅
- » dry-operationのススメとエラー情報をViewまで持っていく方法の模索
- » aligach.netのRubyとViteをバージョンアップした
- » ViteRuby 3.7.0は起動方法のデフォルトがnpx経由になった
- » GmailからSpreadsheetとGoogle Driveへ書き出すGASライブラリを作った