僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
第4回 設計作業としてのテスト駆動開発 | gihyo.jp
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明しています。第四回目は、開発者の視点からの透明性について、テスト駆動開発(TDD)をキーワードに考えます。 ソフトウェア開発においては、コミュニケーションギャップにより、最終的な成果物と顧客のニーズとの食い違いを生み出す原因となっています。 以下のような箇所でギャップが発生します。 顧客と開発者の間 開発者と開発者の間 前回までに、顧客と開発者の間のギャップを如何に埋めるかについてご説明してきました。適切なイテレーション設計でフィードバックの連鎖をつなげることと、タスク管理をより透明度の高い方法で実施することの重要性について紹介しています。今回は、開発者内部でのコミュニケーションギャップにスコープを当ててみたいと思います。 設計の共有の重要性 事前に詳細を全て決定し、ドキュメントを起こしてから開発に入るウォータ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
受入テストの自動化 - 理論にすぎないのか、それとも実践的なのか
