いもろぐ

思い立ったら書いていくスタイルで

Ques#6 感想とメモ

2015/5/14 に行われたQues#6のメモ。

永田さんの話に勇気づけられた会でした。

あと、懇親会で知ってる人がだんだん増えてきてそこで近況報告とかするのが楽しくなってきたのでこの輪を大事にしたい。だけど懇親会の時間だけじゃ話足りないのよね。懇親会だけを目的としたイベントとかあればいいのに。(やればいいのか。ただの飲み会だけど)

感想、思ったことを先に

  • スクラム開発について

    • もともと開発チームのベロシティ(スプリント内にいくつのストーリーポイントを消化できるか)は一定(実際は慣れていくと上がるけど)として進めるはずなので、スクラム開発していながら「終わらないから残業とか土日でやるわ」っていうのは違う気がする。
    • その場合は納期を遅らせるか、スコープを減らすか、の対応がスクラム的には正解なんじゃないかな。
    • できるところまでしかできません、が基本。
    • 大前提として「自分のプロジェクトであり、成功させることが自分のミッションである」と感じているメンバーが集まっていること。
    • そうじゃないと「できるところまでしかやりたくありません」っていう「逃げ」になって不毛。
  • スプリント内に終わらない話

    • スプリント内にテストが終わらない、あるいはテストは終わってもそこで見つかったバグ修正が終わらない、とか。
    • 本来は「○○のバグを修正する」という作業もストーリーとしてチケット化され、ストーリーポイント(作業にかかる工数というか相対的な値)を割り振るのがセオリー。
    • だけどスプリントでのベロシティは変わらないはずなので、ここでもスコープ(か納期)の調整が発生する。
    • これを吸収するには「バグ修正」のタスクを予め想定しておくこと、かな。
  • そもそもスクラムのチームって一つのチームなのでは?

    • 役割が違うだけで、チームとしてやるべき作業は洗い出されているはず。
    • 企画・設計・開発が作ったものをQAがテストする、という仕組みじゃない。
    • 企画・設計・開発・QA(必要ならその他の役割も)で一つのチーム、という思想。
    • だけどこれまでの経緯から「作ったものをテストする」タイプの関わり方をしていた組織にとって、開発チームの中に入っていって何ができるのか、は課題。うちの会社でも課題。
    • でもそこで確立できたら楽しそう。
  • スクラムに必要なドキュメント

    • 何でもドキュメント化するんじゃなくて、チームの暗黙知が高まると、そのチーム内のコミュニケーションは高速になるよ、というのはわかる。
    • そうしそうしたいけど、そこに後から入ってくる人とか、引き継ぐ人がいる。
    • あるいは将来の自分が見た時に「これなんだっけ?」になりそうなジレンマはある。
    • 「必要最低限のドキュメント」として何がアレばいいのか、はその時々だけど、その時々で定義できるのかな自分は。

セッションのメモ

ソニーの永田さんの話を聞いたメモ。(最初のKDDI鈴木さんのセッションには到着が間に合いませんでした)

品質をよくできなければアジャイル開発は成功しない

テストベースどうするのか?

  • ドキュメントが書かれない。
    • それがないとテスト出来ない・・・うまく関係が持てない
    • まずここが障壁になりそう
  • なぜドキュメント化しないか?(QAから見て欲しい情報)
    • 企画、開発は暗黙知を持っていて、それで意思疎通している。
  • 設計をするためにアーキテクチャプロトコルはドキュメント化している
    • そのドキュメントと暗黙知をミックスして開発している。
  • その中にQAが入って欲しい情報をとってくる。
    • ユーザーストーリーで要求と仕様を表現できるか?
    • 彼らの暗黙知の中に入っていく
    • ドメイン知識は知らなければダメだし、(そのチームの)ポリシーみたいのを感じる?のが大事

設計開発へのフィードバック

  • (テストをして)何をフィードバックするのか、を説明する
    • そのためにどんな情報、成果物が必要か
    • その中で信頼関係が生まれる
  • 設計者にテストケースをレビューしてもらう
    • 設計にテストを組み込んじゃう
    • 設計しているときにシステムテストをやるイメージ
  • ツールから取れる情報を見える化する
    • メトリクスとかKPIに対する現状とか
    • バーンダウンじゃなくてバーンアップチャート
    • ストーリーポイントが増えていることがわかる
  • ベロシティは経験値。改善していくことで上がっていく。
    • 劇的には変わらない
    • 手戻り(バグ)を減らす
    • コミュニケーションロスを減らす
    • 待ち時間を減らす
  • 現状の把握(メトリクスとか、事実を見て)
    • それに対してどうするかを計画する、何をするのかを都度決める
    • (今起こってる、すぐ改善すべきところはどこなのか)

3分悩んだら聞け

  • 困ったら聞けばいい→ドキュメント減らせる→暗黙知高まる

QAが(開発プロセスも含めて)改善する

  • おしまいのフェーズに入ってくるのではなく
  • 朝会も振りかえりもQAが入っていて改善していく
  • 施策の効果がメトリクスに現れる
  • 例えばバグ傾向のフィードバックとか

ウォーターフローでは情報を待ってた

  • アジャイルイテレーションごとにメトリクスがわかる
  • それを改善するところに入っていく、むしろ仕切る
  • アジャイル開発を正しく理解することが必要だけど。
  • やってることはシステムテストレベル。マニュアルテスト。
  • それをやるためのテストベースを「取りに行く」

トークライブ

鈴木さんと永田さんのトークライブ。MCは@snskさんでした。

アジャイルチームに歓迎されるテスターのスキル・人物像

  • 鈴木さん
    • コミュニケーションに苦痛を感じないこと
    • 暗黙知やフィジカルなコミュニケーションがMUST
  • 永田さん

    • 年齢とか関係ない。
    • 得意なところ、何を提供できるかを「表現できる」と信頼される
  • 永田さん

    • アジャイルは設計も開発もシロウトじゃできない
    • リアルタイムで改善していきながら、設計も実装もする。CMMIではレベル5
    • やる気。面白いなこれ、やってやろうって思える人。
  • 鈴木
    • スーパーヒーローはいらない
    • どこにでもいる人でやっていける
    • マインドセットが大事。

最低限必要なアジャイルチームのドキュメンテーション

ユーザーストーリーのテンプレはある。ただHOWが書かれていないのでテスト設計ができない。どんなドキュメントが必要になるのか。

  • 永田さん
    • エラー処理を全ては(ドキュメントに)書くわけじゃない
    • が、だいたいパターンが決まってる。(ウィンドウのどこにエラーがでる、的な)
    • そこは書こうよ、という決めにした。
  • 鈴木さん
    • 製品によって違うけど、うちの場合は画面設計書は必須。
    • ユースケースマップを作っている
    • 誰が目的で使うか、かな。
    • (そのドキュメントは)主に設計開発の人がつかう。QAの人もみる。
  • 永田さん
    • 結局はチームで決めること。
    • 今までQAが入っていないなら、これから入っていって「何がアレば自分たちは何ができるのか」を言っていく(成果を出す)ことでチームに信頼してもらう

...以上です。 今回も楽しい会でした。 運営の方、ありがとうございました。