TDD Boot Camp(TDDBC) - TDDBC大阪3.0/KPT Diff
- Added parts are displayed like this.
- Deleted parts are displayed
like this.
! 一日目
!! Keep
* ペアプロやレビューで他の人がどう考えるのか知れて楽しかった
* ペアプログラミング
* 久しぶりにプログラムを書いて楽しかった！
* テストを先に書く
* パラメタライズド Gtest
* 楽しくプログラミングする
* TAで、TDDを伝えることができた（＾＾）ｖ
* Eclipseのショートカット覚えた（教えてもらいました）
* TDDBC
* TDDやペアプロ初めてでしたがすごく勉強になった
* TDDを実践する
* 勉強会に参加する
* テストコードを書き続ける
* RSpecを学ぶ
* ペアプロ楽しい
* Ruby楽しい
* 楽しかった
* テストを書いて実装する流れを続けたい
* 楽しかった
* ちこくしなかった
* TDDのリズム/方法の基本がわかった
* ペアプロが体験できた
* ナイスなデモのおかげで、スムーズに1stサイクルをまわせた
* ナイスデモ
* TAをした前回より良かった…？
* とりあえずJUnit使おうと
* 意味のある変数のつけ方
* TA
* Groovyによるテスト実装
* 初TAで不安だったがJUnit実戦入門よんでたので質問の対応できた
* TDDを教える側としての良い経験ができた
* 和田さんのイントロダクションが非常に理解を助けてくれました。
* Groovyを使ったテストコーディング！サイクルを早くまわせるから
* CRCをt買った手短なペア設計
* ペアプロ初めて体験。新鮮な感じで良かった。
* C++の新しいテストフレームワークを知れた
* リファクタリングを積極的にやっていきたい
* テスト書く
* (Google Test)TESTP(?)を知った
* 楽しくプログラミングする
* 社内にTDD経験者が増えた
* 社内にペアプロ経験者が増えた
* 様々な人に会う
* テストコードを書く
* ペアプロの機会があれば参加する
* GoogleTestの使用と勉強を続ける
* Googletest思ってたより便利なので使っていく
* TDD
* Groovy!（空メソッドを作るついでについプロダクトコードを書くことがなかった）
* ペアプログラミングを体験できた
* TDDについて知ることができた
* ペアプロやってよかった
* まずテストを考えられた
* GitGitHubを利用してペアプロやるお他の人のPC環境が見られて学べることが多い
* GitHub経由で3人TDDペアプロをした。（PC,Editor的に）スムーズだった。
* 質問がしやすかった
* (Ruby,RSpec)TAのガイドが良かったので、今後のテスト設計にとても役立った
!! Problem
* テストする上で思考力をつけないと
* もう少し具体的なHintも？
* 進めているときにTDDとして問題がないか不安になった
* 3人ペアちょっと難しい…
* 3人でやるのは無理がある気がした
* ネット環境が用意できなかった
* ビルの正面玄関がしまっていて道に迷った
* VisualStudioだった(スタッフ追記：たぶんC++の話)
* 次善にGTestを勉強
* 問題を大きいまま考えてしまう
* 勉強不足（プログラム自体、TDD、設計）
* MSTestの使い方を予習してくるべきだった
* 懇親会不参加…orz
* 検証のようなテストケースを書きたくなってしまう（書かないと何か気持ち悪い）
* 小さな問題に分割できない
* アイスブレイクのタイミングを見失う
* NUnitを用意すればよかった。MSTest…
* Mac+Eclipseが使いこなせていない
* リファクタリングのタイミングが迷った
* TDDの精神を習慣づける
* gcc等の開発環境でうまく利用する方法がまだ不明
* 問題の分割がうまくできなかった
* 言語の基本理解（補間がなければ使えない！）
* 体調不良
* 単純な知識不足
* テストより実装を意識してしまう
* テストコードよりソースコードを見てしまった。Ruby力がなかった。
* Codeをちゃんと読んでいない←的確な指示
* (自分が)rspec,ruby力不足のため、step0にとどまってしまった。
* 事前準備をしていなかった
* 残り時間が少なくなると、つい急いでプロダクトコードを書きたくなった。
* あらかじめ環境を用意しきれていなかった
* Rubyの文法を忘れているところがあったので予習してきたらよかった
* 遅刻して全力疾走した
* 徹夜
* Linux環境でgoogletestのサンプル実行するところまでいけなかった
* IDEの初期設定がうまくいってない（初期設定重要）
* リファクタリングがエンドレスでやってしまう
!! Try
* RSpecを練習してからまたやりたい
* 他言語のテストフレームワークに挑戦
* 環境を作って振り返りをする。明日までに。
* とにかくコードをたくさんかく
* メイン以外のエディタで開発
* NUnitを用意する！！
* ノートPCを入手
* JUnit実戦入門を読む
* 「勝手にTDDしてしまう！」くらい日常にクセをつけたい！
* 実際のプログラムでTDDを使ってみる
* ○○をテストする場合はこうする、といった応用を知りたい
* TDDを学んで実践する
* 次の新しいプロジェクトに導入する
* 他の言語でもチャレンジする
* 他の人のテストコードを見る
* 他の人のテストコードを見るようにする
* よりシンプルで読みやすいテストコード（言語含む）の追求
* 事前準備をする（Git+GitHubを使えるようにすると良い）
* エディタの操作に慣れる
* 途中でおやつをたべたい！
* C++11
* VCSを使いながら
* CIもやりながら
* 次のPJではTDDを実践する！！
* Eclipseを使ってみる
* 今回Visual Studioをつかったけど、次はGCC/Emacsでgoogletestする
* HEW - テストのヒント
* C#に習熟する
* テスト自動化
* TDDで小さなプログラムを作ってみる
* プロジェクトにTDDを取り入れる
* MSTest,NUnitを使いこなしたい
* 今の仕事場でもペアプログラミング、TDDを実戦する
* （テスト名に）日本語が使えるテスティングフレームワークを作る（C++）
* GoogleTestをもっと使いこなす
* 社内にTDDを持ち帰る。まずは自チームに。
* 使用言語に詳しくなって基礎力をつけたい
* テスティングフレームワークの使い方をもっと覚えたい
* リファクタリングを読み直す
! 二日目演習後ペアKPT
!! Keep
* コンパイルエラー読む
* ソース書きは要求ありき。テストのやりやすさを最優先にしない。
* パラレルチェンジ戦略（Refactoring Strategy）
* 交代しつつペアプロを行えた
* テストをリファクタリングする
* テストがやりすぎにきづかせてくれた（シンプル実装）
* 具体的な数値でタスクを書く
* テストリストを作成しそのテストがあるのか確認したので、できてるもの、できていないものが把握できた
* テスト名とテストコードの意図があっているか確認したので、複数の意味を含めたテストが存在することに気づけた
* テストを通じた仕様の理解
* テストを読む
* リファクタリング
* コンテキストの意識
* テストをよく読んだ
* 人のテストを読み解く
* 前回よりTDDのイメージができた、小崎さんのおかげです！ありがとうございます！
* 取り組む問題を事前に合意できた
* テンポよく進めれた
* お互い納得するまで話した
* テストのリファクタリング
* 早いステップ
* はじめるときに情報の水平展開ができた
* todoごとに見積り作業時間を記入していく
* 会話
* 議論しながら問題点を発見できた
* いい名前をつけようと悩むことができた
* 「見過ぎない程度」の先を見た「準備のためのリファクタリング」に取り組んだ
* Groovy面白い！
* テストを書く上でユースケースからテストケースに落とし込む方法なんかつかめた気がする
* 形になっていくところが楽しかった
* 行き過ぎた実装を防いだ
* パラレルチェンジを効果的に利用できた
* TDD手順にそってデバッグできた
* ペアプロかつスピードの維持
* Groovy
* GitHub経由でのコード共有
* Gitでバージョン管理
* TDDですすめられた
* 目標をたてて作業をすすめる
* Guardを紹介できた
* リファクタリングを続けたい
* 自分のエディタ環境が使えた
* Chainingの存在を知れた（スタッフ注釈：Chaining Assertionのこと？）
* ペア交替がスムーズだった
* RSpecの実践的な利用方法について多くを学習できた
* テストケース自体の過不足が見つけられた
* Spockこわくない
* Spockイケてる！
* ソース管理（DVCS）が良かった
* タスクリストを作ってTODOつぶしていった
!! Problem
* テストの見通しが悪い
* todoを書く前にロジックを修正してしまう
* 確認を厳格にやりすぎたのでなにも進んでいない
* ペア交代のタイミングがつかめなかった
* なんとなく不安がある
* 小さく一つずつ対処できない
* TODOリストのメンテが必要。先にもう少し書く。
* Redの時間が長すぎた。「もう少し細かいテスト」がかければ…
* クラス設計がやっぱり難しい。レッドが長い。
* リファクタリングなのにインターフェースを変えてしまった
* テストファーストが継続できない（すぐ実装に入ってしまう）
* テスト粒度の選定
* タイムボックスがはっきりせず、わりとのんびりしてしまった
* ペア交代がうまくいかなかった
* TDDをやっていない
* サンプルコードの理解に時間がかかった
* 再設計のタイミング
* 状態の整理
* リファクタリングに時間をかけすぎた
* テストコードがばらばらになってわかりにくかった
* 休憩しなかった
* あまり交代できなかった
* TDDとしてはテストをしすぎた
* 課題の予習がなかっあｔので理解するまで時間がかかった
* エネルギーが切れた
* PMDとかFindBugsとか使えばよかった
* 環境整備、準備などに時間がかかる→ペアをするなら「できるかぎりの準備」は必要
* 他人の開発環境への適応力が…それで時間とってるのは…
* Macでのコーディングになれていない
* Redの状態でプロダクトコードをさわる
* テストの重複
* Commitわすれてた
* リファクタリング力
* Rubyのコードを読めなかった（続けて勉強しないと忘れる）
* C++のスキル不足
* メソッド名で悩みすぎた
* 同じレベルのテストでコードが統一してなかった
* メソッド名が曖昧なままつみ残した
* テストメソッドの名前がわかりづらい
* バージョン管理してなかった
* Rubyの勉強不足
* clangのエラーわかりにくい
* Java力の不足
* Chainingの書き方がよくわからなかった（スタッフ注釈：Chaining Assertionのこと？）
* C++力不足
* 責務がわかれていない
* 抜け仕様の修正が想定より高コストだった
* Rubyがすらすらかけない…
* 見積り作業時間を大幅に越えるtodoがあった
* 大きな変更に対して小さく分割しないまま修正しようとしてしまった
* Ruby力
* Ruby力、RSpec力
* コンパイルエラーが多い。こまかくコンパイル実行するべき。
* forでてまどる
* eclipseで日本語環境が動かなかった
* Gitでもどしたかった
!! Try
* 責務ごとにクラスをわける
* もっと素振り必要
* 事前設計のあるTDD
* 問題設定がイベントに合致していないということをブログ経由でマサカリ投げる
* ステップを細かくする！
* ペアの画面をVNCか何かで見てもよさそう（Wimax経由だとつらいか？）
* 多少プロダクトコードを理解してから開始する
* Groovy力の向上
* プロダクトコードのGroovy化とリファクタリング
* マルチスレッド対応はどうか？
* シナリオの想定
* Red期間のタイムトライアル
* 「本質的でない準備」はペアプロ等に入る前に終わっとく
* テストはGroovyで書いたほうがシンプル！
* 間違いを恐れずどんどん書いていく
* 自分でもっと考えて書けるようにしたい
* ドメインモデルの構築
* リファクタリング本を読む
* C++11を使う
* テストのリファクタリングをやっていきたい
* Chainingの書き方を学ぶ（スタッフ注釈：Chaining Assertionのこと？）
* 早めに再設計（設計を確認する）
* テスト計画をたてる
* リファクタリングを正しくする（グリーンのまま直す）
* TDDの方法の縛りで小さいプログラムを作ってみる
* Javaをやってみる
* 大きな変更は、テストをpendingいて小さく確実な変更にする
* 早くテストをまわす
* テストごとのcommit等、バージョン管理
* 機能追加に対するTDD
* TDDをあきらめずにやる
* TDD勉強
* テストのクラス抽出をしたい
* ミューテーションテストをやってみる
* 機能を追加する（既存のコードをほどほどで）
* テストコードを疎結合にすべき
* gcc4.7をインストールする
* TODOを先に書く
* 日常的にTDDを使用する状況を作り、習熟できるようにする
* 入れ子テストの見通しを良くしたい
* ステップ4の実装
* とりあえず早くテスト書く
* Eclipse動かすようにする
* Java,IDE力をもっとつける
! 二日目全体KPT
!! Keep
* TDDBC外伝
* TDD楽しい
* 途中のコード引き継いで実装
* 2日目のお題は実践的で良かった（すでにあるプログラムに対するTDD）
* 引継ぎからはじまるTDD
* 2日連続で参加したので、より理解が深まった（初日だけでは限定的）
* テストリスト作成→どのように？→(一例として)ユースケースドリブン、とても興味がある
* TDDのブートとしては良い内容だった
* 濃い内容だった
* コミュニケーションをとりながらテンポよくペアプロできた
* ペアプロによる気づきが得られる体験ができた（1人では気づかない問題を発見できる）
* リファクタリング方法を知り勉強になった
* パートナーのお力で「言語面でのよい書き方」「技術的な問題に手をわずらわされないTDD」ができた
* 和田さんらTAが巡回してアドバイスを下さったのでよかった（問題解決のアプローチにバリエーションがでた）
* 時間の長さが丁度良い
* パラレルチェンジ
* RedとGreenの状態を意識する
* TDD+リファクタリングがつながった
* TODOリストを作成してTDDでやってみることができた
* TDDでプログラミングしてみる
* ちゃんとテストを書く
* これからもMacでいきたいです
* Groovy,Spockのテストコード
* テストコードでの実装する流れが勉強できた
!! Problem
* 言語や環境への慣れ・知識不足の影響がある
* 元のコードが動かなかった（環境問題のため）
* Visual Studioのバージョンやテストツール（MSTest/NUnit）を統一したほうが良い？
* テストコードが増えるにつれてテストクラスがわかりにくく（見にくく）なってしまった
* 変更が当たり前のように行えるようにしてしまうという目的の課題で全メソッド再実装レベルの問題が埋め込まれていた
* キーバインドや環境の違いに翻弄された2日間だった
* アナログツール重要
* 変更の粒度がまだまだ粗い
* 途中で戻したときにバージョン管理されておらず最初まで戻ってしまった
* 「技術的にたりない部分」にて本質的ではないことに時間がとられた
* TDD済みのTDD追加とTDD未のTDD追加は別物
* 2日目だけだと追いつくのに時間がかかった
* 全体でのQA時間がほしい
* ふりかえりが有効活用できてなかった
* 目的が発散しすぎた（課題をすすめるか？リファクタリングするか？テストを充実させるか？）
* 課題の何度が言語によって差がおおきかったように思う
!! Try
* TDDの練習
* Emacs,C++11,Boost
* 忘れないうちにもう1度やる
*「マルチキーボードTDD」を試してみたかった→「完全な作業」な時間の有効活用法
* 自分の書くコードからでもテストを書いて実装する流れを実務でも使ってみたい
* Kataで素振り
* もっとTDDを理解する！！そして広めたい！！
* TDD
* 持ち帰って実戦
* TAとして参加できるくらいになる
* リファクタリング本を読む
* テストのリファクタリング
* リファクタリングBootCamp
* テスト技法BootCamp
* 宿泊型！
* もう少し大きい規模のプロダクトコードを改修する
* テストコードとプロダクトコードをうまく両立させる
* TDD以外のスキルの伝播（ペアプロ、リファクタリング）
* ツールの使い方にも眼を向けてみる
! スタッフ反省会時のKPT
!! Keep
* 仕込みありのデモ
* TDD周辺の技術についての講演
*
!! Problem
* 一人で主催（主催はコミュニティでやったほうがいい）
* PHPのTAが足りていない（参加可能言語に自分のやりたい言語がないので別の言語で登録するも、なれておらず演習として成立しないほど詰まる場合がある。TAがいれば解消できるが、現状TAを探せていない）
* 当日ノリでのGroovyへの変更(事前にGroovyをきちっと学んでからでないと、Groovyの勉強に終始してしまいTDDが体感できないのはTDDBCとしては問題なのでは、という話を踏まえて)
* KPTに黄色のペンを使うと文字が読めない
!! Try
* 席を向かい合わせにしない
* アラートのあげやすい方法を作る
* 言語によってペンの色を変えてKPTでの統計をとってみる
* なれる！TA（自分がTAやれるの？という不安に対する回答集を作る）
* 運営手伝いを増やす
* テストコードに関するガイドを演習の間（or 前）にいれる
* 言語を学ぶイベントではないことを伝える
* 課題の事前公開（特に二日目）
* テスト(TODO)リストフォーマット(or ツール)を作る
* TODOリストの隣に重み付けチェックリスト（テストスカウター）を用意する
* 実装コードを試し書きして、その後コードを消してもらう
* テストコードを1，2個かいたらTAを呼んで、次にやることを説明し「いいね！」をもらう
* ペアプロBootCamp+ユニットテスト入門（なイベント）
* TDDで使えるテクニックの体系化(各トピックにスポットをあてたレガシーコード改善)
* 全メソッドを再実装するような変更が必要な場合にどうすればいいのかを事前に講演等する
* サポート参加者（仮称。イベント中に参加者以上TA未満の立ち位置が明確にあったほうがいいかもね、という話から）
* ペア替えのときは振り返りをしない
* （二日目）ゴールをいくつか提示してペアで選択してもらう or テーマにそった一つのゴールをきめる
* （二日目）スタートラインをそろえる
* イベント終了時刻は遅めに設定する
* 別途テストコードやテスト技法に関する情報提供
* 派生イベントのときは講演と演習のテーマをあわせる
!! メモ
* TAが「他のTAに質問してはいけない」ということはない！！
!! 気になる
* 2日目ペアKPTで「P TDDをやっていない」というKPTをみかけたがどういう文脈でなのだろう？
!! Keep
* ペアプロやレビューで他の人がどう考えるのか知れて楽しかった
* ペアプログラミング
* 久しぶりにプログラムを書いて楽しかった！
* テストを先に書く
* パラメタライズド Gtest
* 楽しくプログラミングする
* TAで、TDDを伝えることができた（＾＾）ｖ
* Eclipseのショートカット覚えた（教えてもらいました）
* TDDBC
* TDDやペアプロ初めてでしたがすごく勉強になった
* TDDを実践する
* 勉強会に参加する
* テストコードを書き続ける
* RSpecを学ぶ
* ペアプロ楽しい
* Ruby楽しい
* 楽しかった
* テストを書いて実装する流れを続けたい
* 楽しかった
* ちこくしなかった
* TDDのリズム/方法の基本がわかった
* ペアプロが体験できた
* ナイスなデモのおかげで、スムーズに1stサイクルをまわせた
* ナイスデモ
* TAをした前回より良かった…？
* とりあえずJUnit使おうと
* 意味のある変数のつけ方
* TA
* Groovyによるテスト実装
* 初TAで不安だったがJUnit実戦入門よんでたので質問の対応できた
* TDDを教える側としての良い経験ができた
* 和田さんのイントロダクションが非常に理解を助けてくれました。
* Groovyを使ったテストコーディング！サイクルを早くまわせるから
* CRCをt買った手短なペア設計
* ペアプロ初めて体験。新鮮な感じで良かった。
* C++の新しいテストフレームワークを知れた
* リファクタリングを積極的にやっていきたい
* テスト書く
* (Google Test)TESTP(?)を知った
* 楽しくプログラミングする
* 社内にTDD経験者が増えた
* 社内にペアプロ経験者が増えた
* 様々な人に会う
* テストコードを書く
* ペアプロの機会があれば参加する
* GoogleTestの使用と勉強を続ける
* Googletest思ってたより便利なので使っていく
* TDD
* Groovy!（空メソッドを作るついでについプロダクトコードを書くことがなかった）
* ペアプログラミングを体験できた
* TDDについて知ることができた
* ペアプロやってよかった
* まずテストを考えられた
* GitGitHubを利用してペアプロやるお他の人のPC環境が見られて学べることが多い
* GitHub経由で3人TDDペアプロをした。（PC,Editor的に）スムーズだった。
* 質問がしやすかった
* (Ruby,RSpec)TAのガイドが良かったので、今後のテスト設計にとても役立った
!! Problem
* テストする上で思考力をつけないと
* もう少し具体的なHintも？
* 進めているときにTDDとして問題がないか不安になった
* 3人ペアちょっと難しい…
* 3人でやるのは無理がある気がした
* ネット環境が用意できなかった
* ビルの正面玄関がしまっていて道に迷った
* VisualStudioだった(スタッフ追記：たぶんC++の話)
* 次善にGTestを勉強
* 問題を大きいまま考えてしまう
* 勉強不足（プログラム自体、TDD、設計）
* MSTestの使い方を予習してくるべきだった
* 懇親会不参加…orz
* 検証のようなテストケースを書きたくなってしまう（書かないと何か気持ち悪い）
* 小さな問題に分割できない
* アイスブレイクのタイミングを見失う
* NUnitを用意すればよかった。MSTest…
* Mac+Eclipseが使いこなせていない
* リファクタリングのタイミングが迷った
* TDDの精神を習慣づける
* gcc等の開発環境でうまく利用する方法がまだ不明
* 問題の分割がうまくできなかった
* 言語の基本理解（補間がなければ使えない！）
* 体調不良
* 単純な知識不足
* テストより実装を意識してしまう
* テストコードよりソースコードを見てしまった。Ruby力がなかった。
* Codeをちゃんと読んでいない←的確な指示
* (自分が)rspec,ruby力不足のため、step0にとどまってしまった。
* 事前準備をしていなかった
* 残り時間が少なくなると、つい急いでプロダクトコードを書きたくなった。
* あらかじめ環境を用意しきれていなかった
* Rubyの文法を忘れているところがあったので予習してきたらよかった
* 遅刻して全力疾走した
* 徹夜
* Linux環境でgoogletestのサンプル実行するところまでいけなかった
* IDEの初期設定がうまくいってない（初期設定重要）
* リファクタリングがエンドレスでやってしまう
!! Try
* RSpecを練習してからまたやりたい
* 他言語のテストフレームワークに挑戦
* 環境を作って振り返りをする。明日までに。
* とにかくコードをたくさんかく
* メイン以外のエディタで開発
* NUnitを用意する！！
* ノートPCを入手
* JUnit実戦入門を読む
* 「勝手にTDDしてしまう！」くらい日常にクセをつけたい！
* 実際のプログラムでTDDを使ってみる
* ○○をテストする場合はこうする、といった応用を知りたい
* TDDを学んで実践する
* 次の新しいプロジェクトに導入する
* 他の言語でもチャレンジする
* 他の人のテストコードを見る
* 他の人のテストコードを見るようにする
* よりシンプルで読みやすいテストコード（言語含む）の追求
* 事前準備をする（Git+GitHubを使えるようにすると良い）
* エディタの操作に慣れる
* 途中でおやつをたべたい！
* C++11
* VCSを使いながら
* CIもやりながら
* 次のPJではTDDを実践する！！
* Eclipseを使ってみる
* 今回Visual Studioをつかったけど、次はGCC/Emacsでgoogletestする
* HEW - テストのヒント
* C#に習熟する
* テスト自動化
* TDDで小さなプログラムを作ってみる
* プロジェクトにTDDを取り入れる
* MSTest,NUnitを使いこなしたい
* 今の仕事場でもペアプログラミング、TDDを実戦する
* （テスト名に）日本語が使えるテスティングフレームワークを作る（C++）
* GoogleTestをもっと使いこなす
* 社内にTDDを持ち帰る。まずは自チームに。
* 使用言語に詳しくなって基礎力をつけたい
* テスティングフレームワークの使い方をもっと覚えたい
* リファクタリングを読み直す
! 二日目演習後ペアKPT
!! Keep
* コンパイルエラー読む
* ソース書きは要求ありき。テストのやりやすさを最優先にしない。
* パラレルチェンジ戦略（Refactoring Strategy）
* 交代しつつペアプロを行えた
* テストをリファクタリングする
* テストがやりすぎにきづかせてくれた（シンプル実装）
* 具体的な数値でタスクを書く
* テストリストを作成しそのテストがあるのか確認したので、できてるもの、できていないものが把握できた
* テスト名とテストコードの意図があっているか確認したので、複数の意味を含めたテストが存在することに気づけた
* テストを通じた仕様の理解
* テストを読む
* リファクタリング
* コンテキストの意識
* テストをよく読んだ
* 人のテストを読み解く
* 前回よりTDDのイメージができた、小崎さんのおかげです！ありがとうございます！
* 取り組む問題を事前に合意できた
* テンポよく進めれた
* お互い納得するまで話した
* テストのリファクタリング
* 早いステップ
* はじめるときに情報の水平展開ができた
* todoごとに見積り作業時間を記入していく
* 会話
* 議論しながら問題点を発見できた
* いい名前をつけようと悩むことができた
* 「見過ぎない程度」の先を見た「準備のためのリファクタリング」に取り組んだ
* Groovy面白い！
* テストを書く上でユースケースからテストケースに落とし込む方法なんかつかめた気がする
* 形になっていくところが楽しかった
* 行き過ぎた実装を防いだ
* パラレルチェンジを効果的に利用できた
* TDD手順にそってデバッグできた
* ペアプロかつスピードの維持
* Groovy
* GitHub経由でのコード共有
* Gitでバージョン管理
* TDDですすめられた
* 目標をたてて作業をすすめる
* Guardを紹介できた
* リファクタリングを続けたい
* 自分のエディタ環境が使えた
* Chainingの存在を知れた（スタッフ注釈：Chaining Assertionのこと？）
* ペア交替がスムーズだった
* RSpecの実践的な利用方法について多くを学習できた
* テストケース自体の過不足が見つけられた
* Spockこわくない
* Spockイケてる！
* ソース管理（DVCS）が良かった
* タスクリストを作ってTODOつぶしていった
!! Problem
* テストの見通しが悪い
* todoを書く前にロジックを修正してしまう
* 確認を厳格にやりすぎたのでなにも進んでいない
* ペア交代のタイミングがつかめなかった
* なんとなく不安がある
* 小さく一つずつ対処できない
* TODOリストのメンテが必要。先にもう少し書く。
* Redの時間が長すぎた。「もう少し細かいテスト」がかければ…
* クラス設計がやっぱり難しい。レッドが長い。
* リファクタリングなのにインターフェースを変えてしまった
* テストファーストが継続できない（すぐ実装に入ってしまう）
* テスト粒度の選定
* タイムボックスがはっきりせず、わりとのんびりしてしまった
* ペア交代がうまくいかなかった
* TDDをやっていない
* サンプルコードの理解に時間がかかった
* 再設計のタイミング
* 状態の整理
* リファクタリングに時間をかけすぎた
* テストコードがばらばらになってわかりにくかった
* 休憩しなかった
* あまり交代できなかった
* TDDとしてはテストをしすぎた
* 課題の予習がなかっあｔので理解するまで時間がかかった
* エネルギーが切れた
* PMDとかFindBugsとか使えばよかった
* 環境整備、準備などに時間がかかる→ペアをするなら「できるかぎりの準備」は必要
* 他人の開発環境への適応力が…それで時間とってるのは…
* Macでのコーディングになれていない
* Redの状態でプロダクトコードをさわる
* テストの重複
* Commitわすれてた
* リファクタリング力
* Rubyのコードを読めなかった（続けて勉強しないと忘れる）
* C++のスキル不足
* メソッド名で悩みすぎた
* 同じレベルのテストでコードが統一してなかった
* メソッド名が曖昧なままつみ残した
* テストメソッドの名前がわかりづらい
* バージョン管理してなかった
* Rubyの勉強不足
* clangのエラーわかりにくい
* Java力の不足
* Chainingの書き方がよくわからなかった（スタッフ注釈：Chaining Assertionのこと？）
* C++力不足
* 責務がわかれていない
* 抜け仕様の修正が想定より高コストだった
* Rubyがすらすらかけない…
* 見積り作業時間を大幅に越えるtodoがあった
* 大きな変更に対して小さく分割しないまま修正しようとしてしまった
* Ruby力
* Ruby力、RSpec力
* コンパイルエラーが多い。こまかくコンパイル実行するべき。
* forでてまどる
* eclipseで日本語環境が動かなかった
* Gitでもどしたかった
!! Try
* 責務ごとにクラスをわける
* もっと素振り必要
* 事前設計のあるTDD
* 問題設定がイベントに合致していないということをブログ経由でマサカリ投げる
* ステップを細かくする！
* ペアの画面をVNCか何かで見てもよさそう（Wimax経由だとつらいか？）
* 多少プロダクトコードを理解してから開始する
* Groovy力の向上
* プロダクトコードのGroovy化とリファクタリング
* マルチスレッド対応はどうか？
* シナリオの想定
* Red期間のタイムトライアル
* 「本質的でない準備」はペアプロ等に入る前に終わっとく
* テストはGroovyで書いたほうがシンプル！
* 間違いを恐れずどんどん書いていく
* 自分でもっと考えて書けるようにしたい
* ドメインモデルの構築
* リファクタリング本を読む
* C++11を使う
* テストのリファクタリングをやっていきたい
* Chainingの書き方を学ぶ（スタッフ注釈：Chaining Assertionのこと？）
* 早めに再設計（設計を確認する）
* テスト計画をたてる
* リファクタリングを正しくする（グリーンのまま直す）
* TDDの方法の縛りで小さいプログラムを作ってみる
* Javaをやってみる
* 大きな変更は、テストをpendingいて小さく確実な変更にする
* 早くテストをまわす
* テストごとのcommit等、バージョン管理
* 機能追加に対するTDD
* TDDをあきらめずにやる
* TDD勉強
* テストのクラス抽出をしたい
* ミューテーションテストをやってみる
* 機能を追加する（既存のコードをほどほどで）
* テストコードを疎結合にすべき
* gcc4.7をインストールする
* TODOを先に書く
* 日常的にTDDを使用する状況を作り、習熟できるようにする
* 入れ子テストの見通しを良くしたい
* ステップ4の実装
* とりあえず早くテスト書く
* Eclipse動かすようにする
* Java,IDE力をもっとつける
! 二日目全体KPT
!! Keep
* TDDBC外伝
* TDD楽しい
* 途中のコード引き継いで実装
* 2日目のお題は実践的で良かった（すでにあるプログラムに対するTDD）
* 引継ぎからはじまるTDD
* 2日連続で参加したので、より理解が深まった（初日だけでは限定的）
* テストリスト作成→どのように？→(一例として)ユースケースドリブン、とても興味がある
* TDDのブートとしては良い内容だった
* 濃い内容だった
* コミュニケーションをとりながらテンポよくペアプロできた
* ペアプロによる気づきが得られる体験ができた（1人では気づかない問題を発見できる）
* リファクタリング方法を知り勉強になった
* パートナーのお力で「言語面でのよい書き方」「技術的な問題に手をわずらわされないTDD」ができた
* 和田さんらTAが巡回してアドバイスを下さったのでよかった（問題解決のアプローチにバリエーションがでた）
* 時間の長さが丁度良い
* パラレルチェンジ
* RedとGreenの状態を意識する
* TDD+リファクタリングがつながった
* TODOリストを作成してTDDでやってみることができた
* TDDでプログラミングしてみる
* ちゃんとテストを書く
* これからもMacでいきたいです
* Groovy,Spockのテストコード
* テストコードでの実装する流れが勉強できた
!! Problem
* 言語や環境への慣れ・知識不足の影響がある
* 元のコードが動かなかった（環境問題のため）
* Visual Studioのバージョンやテストツール（MSTest/NUnit）を統一したほうが良い？
* テストコードが増えるにつれてテストクラスがわかりにくく（見にくく）なってしまった
* 変更が当たり前のように行えるようにしてしまうという目的の課題で全メソッド再実装レベルの問題が埋め込まれていた
* キーバインドや環境の違いに翻弄された2日間だった
* アナログツール重要
* 変更の粒度がまだまだ粗い
* 途中で戻したときにバージョン管理されておらず最初まで戻ってしまった
* 「技術的にたりない部分」にて本質的ではないことに時間がとられた
* TDD済みのTDD追加とTDD未のTDD追加は別物
* 2日目だけだと追いつくのに時間がかかった
* 全体でのQA時間がほしい
* ふりかえりが有効活用できてなかった
* 目的が発散しすぎた（課題をすすめるか？リファクタリングするか？テストを充実させるか？）
* 課題の何度が言語によって差がおおきかったように思う
!! Try
* TDDの練習
* Emacs,C++11,Boost
* 忘れないうちにもう1度やる
*「マルチキーボードTDD」を試してみたかった→「完全な作業」な時間の有効活用法
* 自分の書くコードからでもテストを書いて実装する流れを実務でも使ってみたい
* Kataで素振り
* もっとTDDを理解する！！そして広めたい！！
* TDD
* 持ち帰って実戦
* TAとして参加できるくらいになる
* リファクタリング本を読む
* テストのリファクタリング
* リファクタリングBootCamp
* テスト技法BootCamp
* 宿泊型！
* もう少し大きい規模のプロダクトコードを改修する
* テストコードとプロダクトコードをうまく両立させる
* TDD以外のスキルの伝播（ペアプロ、リファクタリング）
* ツールの使い方にも眼を向けてみる
! スタッフ反省会時のKPT
!! Keep
* 仕込みありのデモ
* TDD周辺の技術についての講演
*
!! Problem
* 一人で主催（主催はコミュニティでやったほうがいい）
* PHPのTAが足りていない（参加可能言語に自分のやりたい言語がないので別の言語で登録するも、なれておらず演習として成立しないほど詰まる場合がある。TAがいれば解消できるが、現状TAを探せていない）
* 当日ノリでのGroovyへの変更(事前にGroovyをきちっと学んでからでないと、Groovyの勉強に終始してしまいTDDが体感できないのはTDDBCとしては問題なのでは、という話を踏まえて)
* KPTに黄色のペンを使うと文字が読めない
!! Try
* 席を向かい合わせにしない
* アラートのあげやすい方法を作る
* 言語によってペンの色を変えてKPTでの統計をとってみる
* なれる！TA（自分がTAやれるの？という不安に対する回答集を作る）
* 運営手伝いを増やす
* テストコードに関するガイドを演習の間（or 前）にいれる
* 言語を学ぶイベントではないことを伝える
* 課題の事前公開（特に二日目）
* テスト(TODO)リストフォーマット(or ツール)を作る
* TODOリストの隣に重み付けチェックリスト（テストスカウター）を用意する
* 実装コードを試し書きして、その後コードを消してもらう
* テストコードを1，2個かいたらTAを呼んで、次にやることを説明し「いいね！」をもらう
* ペアプロBootCamp+ユニットテスト入門（なイベント）
* TDDで使えるテクニックの体系化(各トピックにスポットをあてたレガシーコード改善)
* 全メソッドを再実装するような変更が必要な場合にどうすればいいのかを事前に講演等する
* サポート参加者（仮称。イベント中に参加者以上TA未満の立ち位置が明確にあったほうがいいかもね、という話から）
* ペア替えのときは振り返りをしない
* （二日目）ゴールをいくつか提示してペアで選択してもらう or テーマにそった一つのゴールをきめる
* （二日目）スタートラインをそろえる
* イベント終了時刻は遅めに設定する
* 別途テストコードやテスト技法に関する情報提供
* 派生イベントのときは講演と演習のテーマをあわせる
!! メモ
* TAが「他のTAに質問してはいけない」ということはない！！
!! 気になる
* 2日目ペアKPTで「P TDDをやっていない」というKPTをみかけたがどういう文脈でなのだろう？