Readingagilesamuraiinshimane20120531
← Readingagilesamuraiinshimane
@takaokouji による 勉強会をはじめよう
-
疑問
- 素早い開発が求められているのに失敗するテストをわざわざ書くの？
- プログラムを上手に作る為には頭とか紙で整理した方が良いのでは？
-
テストコードを書くということはプログラムの仕様を先に書いてコーディングするということ。
-
プログラムを書くときは粒度が大事。粒度の荒いところから細かく落として行く。何を作るのかをどう実現するかというステップの中で頭の中で設計の整理をしなければならない。そんな時にテスト駆動開発が効率的ではないでしょうか。
-
質疑応答
- メソッド単位でテスト書く場合、さらに粒度を細かくするイメージが湧かない。
- 細かければ細かいほど一般的にはよさそうだが、メソッド単位が落とし所かな。このインプットに対してはこのアウトプットになるというような。
- Rubyならメソッドより細かいテストが可能。あるメソッドを呼び出して中身の状態が変わったかどうかをチェックできる。そんなテストを書くと、次にバージョンアップした時に中身の状態を誰も意識していないのにテストが通らないことが、往々にしてある。
- メソッド単位でテスト書く場合、さらに粒度を細かくするイメージが湧かない。
-
失敗するテストを書くけどそれが出来ない場合どうするの？
- ブラウザのテストは手動で人数掛けてカバーしている。
-
redとgreenどっちが大切なの？
- red→green→refactoringの流れが重要だよね。
-
テストコードはどういう価値を持つのか？
- 思わぬところでバグの侵入を防ぐリグレッションテストに役立つ。
-
質疑応答
- カバーってどういうこと？
- ブラウザ周りを手動でカバーするとか、後々の不具合を修正するタイミングで、テストが無かったので追加するとか。カバレッジツールを使うとか。
- 最近はツールが良くなってきてる。ブラウザのテストも自動でできるので、新しい実装の為にもテストが役に立つことが分かってきた。
- 今は自然言語で動くテスト仕様書みたいな形に移行している。また、操作の流れで一連のテストができるようになってきている。
- ユニットテストとしてcucumberを使うのはどうか？
- 一度書いたことがあるが、画面の流れとかなので、かゆい所に手が届かないもどかしさを感じた。
- カバーってどういうこと？
-
テストを繰り返すとあるが、どこまでサイクルを繰り返すのか。
- 全てのストーリーの受け入れ条件を満たすまで繰り返す。
- 危なっかしいところはテストする。全てをテストするわけではない。なぜか？
- このプロダクトコードにはどういう意図があるのかということを共有する為のテストファースト。自分がこう考えているということを示すことが大事。また、自分だけの考えで進めるのではなくて、他人にレビューしてもらうことが大事。
-
TDDで複雑さに立ち向かうけど、TDDは後から効いてくるもの。初めから定量的な効果を示すことはできないから顧客の理解を得ることが難しい。
-
質疑応答
- 全機能に対してテストを書くことに対してどう思いますか？
- 最初から全て書くことはむずかしい。テストコードを書いてアプリケーションのやりたいことを明確にしたうえで他人と共有して、 テストコードの正しさをカバーしていく。それを目の前のストーリーに対して集中して行う。そういった活動を繰り返しながら、プロダクトを育てて行くことが正しいと思います。
- 全機能に対してテストを書くことに対してどう思いますか？
実行可能なプラクティス produced by @takaokouji
- 標的
- Agileなソフトウェア開発をやってる人、やりたい人
- 目的
- Agileなプラクティスについて実ビジネスで採用可能、もしくはすでに採用しているプラクティスについて議論し合い、自らのAgileな活動のヒントを得る
- 進め方
- マトリクスを作り、各々思うがまま付箋に書き出す。
- 付箋をマトリクスにマッピングしながら、議論する。
- チーム毎に発表
- 採用しているプラクティス
- TDD
- ツールが充実している。テストデータの自動生成など。
- TiDD
- redmineを使っている。テスト駆動をチケットで管理することで、タスクが見えやすくなる。
- TDD
- 採用可能なプラクティス
- ItretionZERO
- これから新しいメンバーで新しい価値を創ろうとする時には準備作業が必要。
- 集まったメンバーが業務を理解しているか、技術的なレベルを確認する為。
- ItretionZERO
- 質疑応答
- TDDとTiDDの時間に余裕が無いとできない？
- テストコードを書くことが個人的には得意じゃない。プロダクトコードと同じぐらいテストを書くことに時間を費やしている。時間に余裕がないと難しいと感じています。
- TDDの中のテストコードを書いている時間は見えないコストだと思います。経営者としてそのコストをどう感じるか？
- 我々はシステム開発をしている。プロ集団としてある一定のレベルには達していないといけない。そういう意味で全てのテストコードを書く必要はない。複雑なところ不安な所にテストコードを入れて開発すればよい。ただ、最終的に品質のいいものを作らないと、返ってトータルコストが増えてしまうので必要なことだと思います。テストコードを作っているからといって生産性が落ちているという解釈はしていなくて、品質の高いものを作ろうしていると解釈しています。
- テストコードを書いているときは価値を生んでないように思えて不安。そういう言葉が経営層や営業から聞こえてくると担当としては仕事がしやすいなと思いました。
- 我々は行政のシステムを収めることが多い。行政からはしばしばテストのエビデンスを求められる。テスト仕様書とかテスト結果を添付するという納品物を作るだけの為の作業、これは無駄だと感じている。それに比べるとテストコードを書くことはとても生産的なことだと思います。
- TDDとTiDDの時間に余裕が無いとできない？
- 既に取り組んでいるプラクティス
- ユーザーストーリー
- イニシャルコストがほぼ不要。デメリットが無い。
- 使い勝手の悪い機能が減った。
- カンバン
- 実現が容易
- ゴールが見えるようになった。
- ユーザーストーリー
- 実現が難しいプラクティス
- インセプションデッキ
- バックグラウンドや環境によってできるできないがあるから。
- → まずはできるものからやってみてはいかがでしょうか。
- インセプションデッキ
- まとめ
- 自分自身のおかれている環境によってプラクティスを取捨選択することが大事。
-
既に取り組んでいるプラクティス
- スクラム盤
- タスクの状態を可視化できる。メンバー同士、支え合うことができる。
- ticket driven devlopment
- Doneがうれしい。タスク漏れが減った。
- 懇親会
- 強調が加速する
- ふりかえり
- ハードルが低い。一体感が得られる *IRCドリブン
- 顧客と常時、IRCでコミュニケートしながら進める。電話だと割り込みが入るが、適度な距離感と時間の間隔が継続性に繋がる。なお、お客さんと繋がっているという安心感を得ながら進めることができる。
- スクラム盤
-
質疑応答
- IRCでお客さんとやり取りする頻度は？
- プロジェクトや状況による。一日何時間とやり取りしている日もあればまったくの日もある。緊急時、または問題がある時に即繋がるチャネルを用意しておくということが大事。
- 常時やり取りできるということが甘えに繋がったりしないか？
- あると思います。利害が一致しているが立場は違うので適度な緊張感がある。ただ、電話なら割り込みが入りそう。少し遅れても大丈夫という緩い感じがIRCのメリットとしてあると感じる。ロギングしとけば記録も残るし。
- お客さんがIRCが得意だったからIRCが選択されただけであって、電話が良ければ電話を選択する。お客様が得意なツールに合わせることが重要。
- IRCでお客さんとやり取りする頻度は？
- ふりかえりにテーマを設ける
- ワークショップの時間が短いと思う
- 気が付かない程度に黙読の時間を短くしてみよー ｷﾘｯ
- 討論→発表→質疑の流れ
- 採用、不採用について色々な背景からの意見を聞く
- 発言をする
- プラクティスを採用する「なぜ」と「効用」を認識できるワークショップ
- 今回のワークは良かった
- ワークショップ楽しい
- やること自体
- 楽しい
- 企画者リスペクト
- Agile Hiroshi
- …。
- 初めて参加 アジャイルは熱い＝おもしろい
- バックグラウンドによってツールは使えないかもしれないが、目的を達成するためには他の手段があるかもしれないということが分かった
- 常に他の人の意見を大事にする
- 読書会よりもワークショップの方が楽しくない？
- 何でも話す（正直に）
- 話が進む
- ワークショップをサポートする
- テーマへの理解が浅かった
- 時間が短く感じる（もう少し読みこんでから参加すべき？）
- ホワイトボードにうまくまとめられていなかった
- 採用不可能なプラクティスが思いつかなかった
- プラクティス自慢になっていないか？
- Problemなんてないよ！
- 討論の時間が短い
- 一枚の付箋に何を書けばよいか教えて欲しい
- ワークショップの内容を事前に知りたい（目的だけでも良いかも）
- 権力者への拍手の大きさ（大きすぎる）
- （進行役をはじめとした）媚び諂い
- 聞くだけになってしまう
- もっと意見交換したかった
- 今日粘着の付箋じゃなかった
- 自分の話が長かった
- 付箋の粘着力が弱い
- 何も問題はない
- 時間が短かった
- 皆が参加できるテーマを扱いたい
- CIで実践している単体テスト以外のプラクティスを議論したい
- 話しの内容を捉えてホワイトボードをうまくまとめる
- 「なぜ採用するのか？」「効果は何か？」「どうやって評価するか？」を考える
- ワークのふりかえりを個人的につづけてみます
- 時間を有効に使う為の進行をしたい
- 他の人がやっていて良いと思ったことは実践したいね！
- 社内でやりたい
- 何か言おう…。
- もう一回しても面白そう
- 非アジャイルな手法の中にアジャイル的手法と組み合わせると得るものは無いか
- みんなでプランニングポーカー（いろんな立場の人がいるので見積もりをやってみたい）
- ホワイトボードに付箋を何度もギュッと押さえてみる
- 古い井戸にはまだ水がある。新しい井戸を掘る必要はない。
- 時間に合わせてテーマを決めてからホワイトボードでの議論を進める
18.8 → 第12回読書会 → 20.2
Readingagilesamuraiinshimane20120531 ← → Readingagilesamuraiinshimane20120628