仕様書を書いているときは多くの時間を浪費しているのに気づいたのですが、後でアプリを書くときは無視でき、いくつかの重要なことを忘れてしまいます。
私は、(私にとっては) 概念実証アプリケーションを作成し (適切なエラー ハンドラーやセキュリティ機能がない、スタイルにマイナーな問題があるなど)、それを参加者の仕様として使用する方が高速であることを発見しました。
それでも、私はこの方法でも時間を無駄にしていると感じています。これをどのように行うべきかについて何か良いアイデアはありますか?
仕様書を書いているときは多くの時間を浪費しているのに気づいたのですが、後でアプリを書くときは無視でき、いくつかの重要なことを忘れてしまいます。
私は、(私にとっては) 概念実証アプリケーションを作成し (適切なエラー ハンドラーやセキュリティ機能がない、スタイルにマイナーな問題があるなど)、それを参加者の仕様として使用する方が高速であることを発見しました。
それでも、私はこの方法でも時間を無駄にしていると感じています。これをどのように行うべきかについて何か良いアイデアはありますか?
あなたはアジャイル開発を支持していると主張しているようです
この反復プロセスを使用して、私たちのチームは重要度のスケールで機能を「ランク付け」し、リリース日と必要な機能を比較検討することができます(簡単に言えば)
仕様への興味深いアプローチは「テスト」です。高レベルのものについてはFitnesseなどのツールを使用して受け入れテストを記述し、低レベルのものについては単体テストを記述します。
開発者がコーディングを完了したら、テスト スイートを実行して、すべての仕様が実際に機能していることを確認します。
このアプローチは、仕様を書く人がテストの観点から自分自身を表現できることを期待しています。これは通常正しくないため、このアプローチはユートピアに似ています。それでも、試してみることができます。
Joel On Software には、これについて役立つ記事があります。ただし、この質問と回答はユーザー固有で主観的なものだと思います。