スプリントを複数こなしたあとに結合テスト、総合テストと称するものをやる理由がわからん。それをやらなきゃ品質担保できないのだとしたら、スプリントごとにリリース可能にするという原則に反しているんじゃないかね? 個人的な感想だが、最後に結合テスト、総合テストと称するものやらなきゃいけなくなっている理由は以下のような感じかな? 会社のプロセスで決められているw 顧客から求められた そもそも設計に失敗していて、複数のオブジェクトの結合度が高すぎるが故に、ユニットテストできない(←僕の予想ではこいつが本命)。従って実はスプリント単位ではリリースできないw ユニットテスト書く時間が無かったので力技でなんとかしようとしている ちなみに、重厚長大なテストを行うのに大量のコストをかけるくらいなら、とっととリリースして出てきた問題潰した方が良いケースもあるだろう。これはROIの問題なので、必ず100%のカバレー
テストに関する疑問 | Ryuzee.com scrum の要素を試す中で、設計とテストのイメージできないことを、金曜日の OSC で劉爺さんたちに聞いてみたところ、このような話になった。 ウォーターフォールとスクラムでの開発の流れ 話の背景としてはウォーターフォールとスクラムでの流れの関連に対しての疑問からきている。 ウォーターフォールでの開発は一般的にこのような流れになると思う。 要件定義 → 設計 → 実装 → テスト → リリース これがスクラムではこのような流れになるというのが今の理解 バックログ策定 → 実装 & 単体テスト → リリース → 実装 & 単体テスト → リリース 「実装 & 単体テスト → リリース」が一つのスプリントになる。 期間一か月、1スプリント、1週間のイメージはこんな感じ ここで疑問が出てきた 設計はいつやるの? ドキュメントはいつ書くの? システムと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く