重なっているのは、各人が出した項目の被りや統合によって重ねてます。なると全員が納得して作っていますよね。1人で作業した方が良いというチームの判断となっています。1人で作業した方が良いからだけではなく、みんなが納得している状態だからが前提条件になります。巣立ちのとき状態遷移図が書き終わった段階で約1時間くらい残っていました。ここから全員で状態遷移表やテストケースを書いてもよかったのですが、どうせなら次のモデルを実施してみたい。どこまでできるのかと思い、ユースケース図を書くことを提案しました。ユースケース図を書くときに、私は一歩引いてみましたが、問題なく進み始めて無事にうまくいったと思います。引いた私は資料作りに専念しました。一人は状態遷移表を記載してもらいました。5人チームなので3人でした。何かをした訳ではないですが、ユースケース図を書くときにも、状態遷移図とやり方を一緒にしました。アクターを4分で書き出すみんなで「せーの」で共有するユースケースを4分で書き出すみんなで「せーの」で共有するあとは棒人間と矢印を書いて整理しました。ほとんど、状態遷移図とやっていることは変わりません。そのため、状態遷移表を書いている人もモデルとやり方を知っていれば進められるはずです。どんなふうになったの?こんな感じで進めた結果がこちらになります。順番に説明していきます。「気になること」は仕様を読んで行く中で、気になったことをあげて行く場所。解決したら、右の「きまった!!きめた!!」に移動して赤字で記入。状態遷移図を作る際にみんなで考えた資料です。これらを元に下の状態遷移図を書いたものになります。これらをみたときに不安点が上がってきたので赤い付箋を張っています。チームの重要なテストにしています。気になったことやイベントの間違いが書かれています。番号は状態遷移表へのトレーサビリティを確保しています。逆光で見にくいですが、上の3枚はそれぞれの進め方を書いています。その下が状態遷移表とテストケースになります。付箋を使った表という発想がすごい!!ユースケース図です。右はユースケースからテストケースです。操作手順とかはみんなで共有しているからそんなに詳しく書いていません。チーム内で共有して暗黙知になっているのは許容しています。個人のタスクを極力減らすためにタイムキープでも、各人のタスクは、チャレンジ時間と追加時間を3分と言っているのに2分半にしたりと鬼畜な事もしましたが、だいたい間に合ってました。1回だけ伸ばしましたが、全体的に短くて問題ありませんでした。これは普段の作業時にも無意識のバッファを積んでいるかもしれないです。そこに意識的にバッファを積んでさらに時間を見積もっている可能性があります。これが悪いことだとは思いませんし、当然だと思います。実際の現場では絶対にしません。これはワークショップだからやったことです。最後にこれは、WACATEだからではなく、普段の業務でも一緒になります。誰かと一緒に働くことで、情報共有の時間も含めて考える時間になるので、私は好きです。現場のメンバーの多くがメンバーのタスクを把握している、お互いにフォローできる、仕様がみんなで共有されている状態になることが理想だと思っています。ここでの経験を現場に活かして、さらに良いチームを作れるようにしたいと思います。2018夏に参加してきました。ワークショップで実験してきました。Tweet広告を非表示にする関連記事2018-04-28テストケースのないソフトウェアテストについて考えてみるどうも、お久しぶりです。ワカテーズハイという症状をご存知でしょ...2017-11-14木テクにて突撃LTをさせてもらいました!!こんにちは、なそです。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事テストの諸々のドキュメントをテキストベースで作ってみるにはどうすれば良いかを考えてみた。windows編システムを把握する3つのコツテストラジオを動画にしたよ九州ソフトウェアテスト勉強会の勉強会でワークショップの実験をしてきました!月別アーカイブ参加グループプログラミングはてなブログをはじめよう!DevTestさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。