TDDBC大阪3.0/KPT - History
! 一日目
!! 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
!! Problem
!! Try
! 二日目全体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
!! Problem
!! Try
! 二日目全体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をみかけたがどういう文脈でなのだろう？
Keyword(s):
References: