読者です 読者をやめる 読者になる 読者になる

mokky14's IT diary

IT関係の仕事メモ、勉強会の感想など書いてます。

アジャイル×テストに行ってきました

今回はすくすくスクラムソフトウェアテスト勉強会のコラボ企画で、細谷泰夫さん(@yasuohosotani)による講演とワークショップ。

細谷さんの講演(スクラムと品質)

気になったトピックなど。

  • 品質が悪くなる要因は、オーバーコミットメント(能力以上の作業を割り振られる)、階層的な組織構造(実行不可能な計画を、実行可能な計画に戻すまでに時間が掛かる)が原因。こういったムリをチームで吸収させられることがないように、スクラムのルールが決まっている。
  • スクラムではバッファを必要としない(スプリント期間は変えない)。チームのベロシティに合わせてスコープを変動させる。スコープを縮める代わりにチームは品質を保障する。
  • チームの見積もりに対して、上司等の外部の人間が「もっと早く出来るんじゃないか?」とか言ってはいけない。ルール違反。
  • チームが情報を隠すのはルール違反。
  • ルールが守られないと、プロダクトの価値や品質が価格と釣り合わない結果になる。

こうして読むと、まっとうな事を言ってるだけに感じるんだけど、このまっとうな事が難しい。。
「スコープが変動する」事を客に受け入れて貰うのは簡単ではないと思う。このあたりは契約含めて考えないといけない話。
アジャイルの見積もりは全然勉強してないので、このあたりをどう持っていくかはまだ勉強が必要。


続いて、入社1~2年のC#未経験者を集めてC#での開発を行った話。

  • 入社1~2年の開発言語未経験の新人でも、短い期間(数日程度)で要求分析~テストを行うプロセスを繰り返し実行させたところ、短期間で成長が見られた。
  • 要求分析、方式設計は経験者の助けが必要だが、詳細設計、実装、テストは経験の浅いメンバーでも作業可能(支援は必要)。
  • 設計に原因結果グラフを使うことで、複雑なロジックのメソッドが作られることを抑止できる。

このアプローチは興味深かった。
確かに、実装したことない人間がまともな設計なんて出来るわけもないし、実装してみて、その反省をすぐに次の設計に活かせる環境だと成長するというのはよく分かる。手段として覚えておくとよさげ。

この後は、アジャイル開発とテスト品質に関する話。

アジャイルとテストについてのワークショップ

5グループに分かれて、グループ内の一人が携わっている開発の内容を題材にしてワークショップを実施。
うちのチームは、大学情報データベースを題材にした。

まず、大学情報データベースを、誰が、何の目的で使用するかの洗い出し。
f:id:mokky14:20131207232027j:plain

上げた人の中から、特にフィードバックが欲しい人を選択し、いつ、どんなフィードバックが欲しいかを考える。
f:id:mokky14:20131207232523p:plain

フィードバックが欲しい人達に対して、どんな順番でどんな機能を提供していくかを考える。
(画像ちょっとピンぼけ)
f:id:mokky14:20131207232604j:plain

フィードバックが欲しい機能に、どのような品質が必要で、その品質をどうやって確保するか考える。
ここでやっとテストの話になる。
f:id:mokky14:20131207232544p:plain

フィードバックばかりになって、テストで品質を確保するという方向にならなかった。「フィードバックを貰うための品質」がこのワークショップのテーマなので勘違いしてた。

アジャイル開発は、優先度が高い機能から順に早く提供していくための手法なので、テストで力を入れる所も、その機能の使用目的を果たせるように考える必要がある、というふうに理解した。

うちのチームでは、教員の情報を使用する人からのフィードバックを真っ先に貰った方がよいと考えて、データを使用する人からのフィードバックをスケジュールにしたけど、このスケジュールを説明したとき、実際に運用するのは事務の人だろうから、そちらから先にフィードバックを貰った方が良いんじゃないかという意見を頂いた。
どちらの意見が正しいとかがあるわけではないけど、「どこに価値を置くのか」の意識合わせって大事だなと改めて実感した。

アジャイルって何?」という人がチームに2人いて、その人たちの意見を引き出せなかったのはちょっと反省点。

ビアバッシュ

妻に参加OKしてもらったので、久しぶりにビアバッシュ参加。
ビアバッシュで聞いた話メモ。

  • 入社1年目だからやってくれるけど、これが5年目にもなると自分のやり方が出来てるので難しい。
  • 手が空いた人は、その時点で最も優先度が高い機能を実装するルールにしてる。その機能の実装に必要なスキルとかは考えないで割り当てられるので、知識の偏りが出ない。
  • ハードの人はアジャイルに理解がある。ハードはリリースしたら修正が効かないので、何度も試作品を作ってテストを繰り返すらしい。

後半はアジャイルウォーターフォールで盛り上がってた。
個人的には「アジャイルじゃなきゃダメだ」と言うつもりはなくて、ウォーターフォールアジャイルも開発の品質確保手段でしかないと思ってる。
ただ、アジャイル開発は、開発手法以上にユーザに提供する価値を考えることが重要なので、「言われた通りに作りました。何に使うのかは知りません」な開発者は相当な意識改革が必要になると思う(本来はアジャイルに限らず考える必要があるだろうけど、アジャイルはプロセスに考えるための仕組みが取り入れられているので)。そういう点でアジャイルをやってみたいな、と思ったりしている。

何か今回はあまりテストの話にならなかった。。