探索的テスターがUserstoryを作る話と、UserStoryMappingていいね。さんがアジャイルとテスト計画について吟じます。Kyushuの参加レポートです。ポエム多めでお送りします。#JaSSTKyushuいままで東京ばかりの参加だったので地方JaSSTはTohokuに続いて2回目でした。テーマは無し......となっていますが、「関係性とチーム」「開発とテスト」を軸にしているそうです。関東勢が多い印象でしたが、九州と関東でだいたい半分ずつくらいとのこと。紙の不具合票の使われ方を参考にしているワークフローは変わる運用・設計について説明できるチーム!チケット番号すぐにあふれて4桁になった。4桁は口頭で話しやすい要件(サマリー)「できること」を一行で表す。bug(課題):触って確かめるテストを書くtask(作業):テストが書けないものイテレーション週に名前を付けたもの。いつやるかを示すサイン自分でサインする。いまは製品名+バージョン+名前を書いている状態openか、closeか結局、終わっているかどうかだけ明示すれば十分だった見積ベロシティや、納期を約束するものとしては使っていない。bugが終わるたびにテストが増えるTDDの自然な拡張あらゆる設計はテストで駆動。ゴールや意図をテストで表現する顧客が触って分かるような「システムに対する変更」がチケットライブラリなど部品だけ作っても触れないものはチケットの単位にしない今はおすすめテストスイート抽出アルゴリズムによってテストの頻度を調整しているということだったけど、それでも、膨大だろうチケット一つ一つをテストする......というのがあまり想像できませんでした。(ただただスゴイの気持ち)毎回テストするために読み返して、古い記述を修正するので、チケット自体が最新の仕様書であり、テスト項目書になっているのかな。惰性でやっていると矛盾に気が付かないまま間違った結果でOKをつけてしまいそうだし(ダメです)すごくすごく、仕事に対して集中しているんだろうなあと感じました。BAGうちのチームのプログラマーはテストが好きかどうかは分からないけど「これよく見つけたなー」と思うようなバグを見つけてくるからテストがうまいと思う。インデックス編チケットのリスト全員が同じリストを見る表示される場所はほぼ固定いつもとどんな風に違うか一目でわかる面積比でチームの様子がわかる正常(いつも通り)か否か担当者ごとにまとまるので一人で抱え込みすぎていてもバレる今は製品+バージョン+担当者チームがどのプロジェクトに注力しているのか見える毎日同じことを「くり返している」から、「いつもと違う」ことがすぐに感じ取れるのかなと思いました。見えすぎると集中できないことがあるので、適度に情報を絞るのは、普段の業務でもちゃんと意識していきたいところ。朝会は9:15-10:00プロジェクターの解像度とメンバーの年齢に合わせた拡大率に設定w今週のイテレーションのすべてのチケットを音読する音読中は目も耳も集中する誰かが「これなんだっけ?」と言い出してしばらく、チケットの再学習が行われるなぜこれをやるの?いま?うまくいくとどうなるの?......あのチームのあのフレーズで思考されているチケットは、「どう製品を変更したいか」の表明。作業のために作成するのではないbugはstoryに対してゴールが明確なのであんまりもめない45分で終わらないこともある。更新しないなら捨てたほうがいい毎日チケットを読み返して更新していると、メンバーの脳内配線が強化される人側がプライマリのデータベースになる!朝会とかミーティングって、なんだかんだ周りが内職していたり、集中していなかったり......多くないですか?という私も、気になることがあると集中していなかったり、聞き逃したり、よくあります。なんのためにみんな集まってるのかを考えたら絶対によくないのはわかりきってますよね。集中して、ほかの人の作業=自分のチームの作業を拾い上げるようにしなきゃなと、改めて思いました。気を付けよう......。(あと、更新されていないWikiページ......身に覚えが......ありすぎてつらい。誰かに許可とって、調整して、更新して......ヨクナイ。