re:反復開発

勉強会告知ページ

connpass.com

スライド

speakerdeck.com

自己紹介

  • @m_seki
  • XPプログラミングを16年ぐらいやっている

クックパッド

  • 2015年にイベントをやってた
  • 秋山さんが論文を書いてた
    • 開発チームの中にテストエンジニアを配し…テストの現場の理想型の一つと思う
    • 開発者もテストエンジニアも不具合を減らし、
    • このようなチームを@m_sekiさんが持っている

Agenda

  • 反復開発の基本
  • 上手くやることのヒント

本当はなにに困っていますか?

歴史

  • 2004年には会社の理解が無かった
  • 2008年
    • 川口さんが上手くやり始めた
  • 2016年のJaSST
    • 「Scrumは上手く行っているがプロジェクトは上手く行っていない」
    • →反復開発が上手く行っていないみたい

障害を想定したい

  • 今日の会場は「変わりたくない層」ではないと思うことにした

反復開発ができてないのでは?

  • まず、反復開発を説明するべきかもしれない
  • Scrumとか色々な名前の手順書が出てきたのに、それを使いこなせてない

プロジェクトが終わったとき

  • どんなことを感じますか?
    • こうすれば良かった…とか
  • もう一度やったらうまくいくような気がしませんか?

ウォーターモデル

  • 図だけ引用されることが多い。
  • 実は「戻りはnステップですよ」と書いてある
    • 工程は1ステップずつ進むけど戻りはnステップ
  • 同じ工程は何度も起こる
  • むしろ2度作りましょう
    • 1回やって分かったことを使って本番の開発をしましょう
      • 2度作ることで色々活かせることがある

期間を半分にしてみる

  • 期間と内容を半分にして、2回に分けて開発したら?
    • なんだかうまくいきそう!

工程別の不具合の調査結果

  • Royceの図はテストは1つ
  • この資料ではV時モデル風
  • 原因工程と発見工程の違い
    • 原因は上流工程が60%強
    • 下流工程で75%発見
      • 企画・仕様・設計の問題をその時に見つけるのは難しい
      • テストは問題を見つける能力が高い
  • 試して分かることは試す
  • 試さずに調べるのは高コスト
  • 中間成果物(ドキュメント)をあてにするのは危険
  • 試してみたほうが安いので、上流工程で頑張るのはコストがかかる

利用する

  • 工程と時期を分けて考えてみよう
  • システムテスト・運用テストをより早く
  • 結合された状態でのテストを早く、頻繁に行うために反復型の開発を行う

期間を半分にしてみる

  • 1/2、1/4、1/8としていって、どんどん小さくしてみる
  • V字を行うにあたって、どこまで短くできるか考えてみる
  • 時期ざっと並べて開発するのと同じ

やり方視点

  • V字モデルの全行程をやるのが1反復
  • 小さな動くシステムから始める
  • 強のシステムを次の反復で改造する
  • じわじわ開発するのとは違う
    • V字の下部分しかやってない
    • @t_wadaが言っていることを信じちゃうやつ
  • V字の一番底だけを繰り返すもの
  • うまくいってそうに見えるのがやっかい
  • 例えば、「ブランチで作業することで、結合時の問題を避けている」という状態になったり

システムを改造する単位

  • 確認ができ、数日で終わる仕様を作る
  • ストーリー毎に全行程を行う
    • 部品、フレームワークを先に揃えるのは✕
    • ストーリー単位に必要なものを用意するのが○
  • 住みながら増築していく感じ
  • アプリケーションとフレームワークが同時に進む

製品を反復毎に確かめる

  • 不具合を確認するだけではない
  • 製品を前にして様々なことを発見できる
    • 製品の意味とか
    • この製品はどういうものだったのかとか
  • 顧客の欲しいものは顧客もよくわからない
  • 実装の問題もよくわかってない
  • 最初から分かるはずがない

プロセス=チーム

  • 出来上がって製品によって、要求が変わったりチームが変わったりする
  • チームが変わったことでどんな効果があったかを製品を見ることによって分かる
  • 要求を変えたりチームを変えたりするには、製品を作る必要がある
  • 全部が成果!
    • 製品はもちろん成果だが、その作り方とか、その途中で分かってきた要求仕様とかも成果物になる
      • 2008年では膨大なテストスイートも成果物だった
      • 自動テストではなく、手動テストだった

製造業であれば…

  • おそらく自社製品
  • 3つの成果を活かしやすい
    • 良い仕様の開発は非常に難しい
      • 何が使いやすいのか
    • 製品寿命が長い
    • 開発期間が長い
      • チームが長生きする
  • 数ヶ月でAgileとかは難しいと思う

チームの変化

  • 反復毎に何かが変わる
  • メンバーのちょっとしたふるまいの変化とか
  • わざとらしい変化以外もあったりする

やろうとすると難しい

  • よく知られている話だけど実践するのが難しい
  • なので、m_sekiならではのヒント

反復開発ならではの問題

  • プロジェクトの初めから終わりまでに起こる問題が5日間の中で発生する
    • ごまかせない。目をそらす時間がない

壁?

  • 世界のエリートは大事にしないが、普通の人にはそこそこ役立つビジネス書

おすすめ→無理をしない

  • 無理そうなことは無理そう
  • 3つの例を示す
    • サブシステム間のペースの違い
    • 工程別のチーム
    • ストーリーの分割

ペースの違い

  • 大きなシステムでは全員同じペースではないかもしれない
  • ペースの違いから揉めがち
  • 実はペースを混ぜても大丈夫
    • 結合された状態で確認するという原則を守っていればね
  • まだ結合されてない部分はリスクとして持っておけば良い
    • あるチームだけ確認した内容は信じない
  • 反復が綺麗に揃うことはあまり重要でない
    • そんなところでは揉めない
  • 隣のチームのペースを無理に変えない
    • スムーズに行っている自分達が合わせる
  • となりのチームもサボっていないのでイライラしない
    • となりのチームは遅いのではなく、実はタイミングが合わないことへの不満が多い
    • 質問しても返事が来ないとか
      • 相手の都合を聞いてみよう
  • どこまでがチームなのか、チームの切れ目に意味があるのか?
  • となりのチームの人達も同じチーうの人達のように考えましょう
  • チームの境界を曖昧にするのが吉

工程別チーム

  • ロール別にチームを作ったり…
    • 開発者とテスターとか
  • なんとなく仲違い
  • 遠慮とか不信感が…
  • 担当する工程がうまくいっているかどうか製品で確認する
    • 自分達の工程だけ上手く行っている状況はあり得ない
  • 前後の工程のチームがうまくいくように気を使おう

開発に関わる活動

  • 以下の5つ全部!
    • 欲しいものを実現する
    • 仕様を具体的にする
    • 実装を考える
    • プログラムを書く・直す
    • テストする
  • 5日間の中に全ての工程がある
  • ソフトウェア開発の加圧動画そのままロールになった
  • こうなるのが自然
    • 5日間でやるとなると自分でやらざるを得ない
  • ほかのロールは?
  • やらないことが違う
    • テスターの場合、「プログラムを書く・直す」だけがない
  • テスターは劣化プログラマか?
    • テスターならではの価値がある
    • 開発者に比べ…
      • 領域が広い・深い
      • テスターの方がより長い時間製品を触れる
      • 製品全体を触れる
      • 手触りの一貫性をイメージしやすくなる

ストーリー

  • 要求の分割のテクニック
    • 練習しないと難しい
    • パターンは存在する
  • ルール
    • 結合したシステムで確かめられること
      • 部品だけのストーリーを作らない
    • 何かしらの価値が増えていること
  • 作戦
    • 起動、主処理、終了までの最も単純なフローを見つける
      • まずはこれを作る
      • 最初は起動と終了だけ作る
        • 設定ファイルは…とか面倒なものが多い
      • その後、徐々に増築し、単純なフローを完成させる
        • 起動の面倒なものが多いので、それが終われば主処理のコードに集中できる
        • なるべく早い時期に心配な処理が試せるように工夫する
        • 枝葉を気にせず幹(中心となるもの)を作る
    • 基本フローから徐々に枝葉を増やす
      • 幹無しで枝が生えないように、いきなりリンゴを作らない
  • 階層のあるチケットはオススメしない
    • 入れ子になりがち
    • なんとなくかっこいい!
      • しかし確かめられない…!
        • 進捗が分かっても確かめられない
    • 個人の進捗は確かめられるが、製品の出来は確かめられない
  • いつも結合テストを可能にする
    • 手に触って完成した様子が分かるようにする
    • 新しいものが載っていることを確かめたい
      • 個人の進捗はどうでも良い
      • 「進んでいる」と言う割には分からない
      • 「どうやって確かめるの?」と聞いてみると良い
        • 「実は確かめられないです」「ダメだね」となったりする
  • ボタン一つは価値があるの?
    • システムが壊れていないことは分かる
  • できるだけ早く喜ばれるものにしたくなる
  • 向かい合うことは大事!

質問

チケットの粒度について。チケット1つが価値を届けるものになっているのか?それともストーリー?

  • ユーザーが確かめられるものが一単位
  • チケットはストーリー、バグ、タスクの3種類。そのうち、ストーリー、バグは確かめられないことが書いてある。
    • タスクは確かめられないもの。ほとんど書いていない

イテレーションの最初は考えるものが多いと思うが、最初はユーザーに届ける価値が無いのでは?

  • ボタンを押して起動して、終了できること
  • 少なくともWindowが出てくること

受託開発をやる場合は、お客様が出した要件通りにやらないといけない。3ヶ月でとかだと難しいのでは?

  • 難しいと思う。
  • 3ヶ月経って作ったもの見せて「ああ、ダメだね」となったり。
  • 「早く気付くために期間を半分にしてみよう」と提案するとか

ストーリーと価値の話について。「ボタンを押して起動して動くものを提供する」というものは、ストーリーを繋げて話すと思うが、お客様としては繋がらないと意味ないじゃんと言われるのでは?

  • 「価値」というと難しくなるので、「変化が分かる」と言ったほうが良いかも
  • ユーザーのゴールは一番細い線ができること

今のやり方に組織が変わるきっかけはあったのか?

  • 全員がやっているわけではない
    • 最初にやっていたのは、V字のテスト部分のみをやっていた、それによって開発が変わったりする

じわじわ開発について。非機能の部分とかも反復の中でやっているのか?

  • 非機能の多くは分けていない。
  • パフォーマンスはもはや非機能ではない。パフォーマンスはほぼ毎日触る。
  • ただ、できないのもある気がする。
  • できないものは「できないなぁ」と思っているようにする。

エンタープライズアジャイル勉強会のきっかけは?反復開発できていないと気付いたのはどこで?

  • テストのイベントでテストエンジニアが開発と話をしていないことがわかった
    • 永田さんから「これが普通なんだよ」と言われた
  • プログラマの話は、プログラムの話はあってもプロダクトに興味を持たない

ストーリーを扱うのは1本だけか?

  • 最初は少なくしていたが、どんどん増える

徐々にテスト工程が増えてくるのでは?

  • やるべきテストスイートを集めてきて優先順位を付けるツールを作った

テスト工程を全なめするわけではない?

  • 全体をカバーしているが、全なめするわけではない

疎にしていると思うが、そのアルゴリズムはどういう風にしているか?

  • 最近触ったものは暫くしなくてよいとか
    • だいたい通っているものは下がっていく
    • rateを決めていて、rateが高いものは頻度を高くするとか

ストーリーの分割が難しい。「DBにアクセスしないといけない」とか、「インタフェースを切り替えたい」といったようなものは、どういうタイミングに行うべきか

  • 増築していくと辛いから整理したいときとかで。

その結果、何が良くなるのか?

  • 次の増築がやりやすくなる

リファクタリングしたい」という要望が出る場合は?ストーリーなどが書けないと思うが…。

  • それで何ができるの?
  • 言ってくる自体怪しいよね

増築するとぐしゃっとなるのでは?

  • 数日で終わる経験が多い。それだけ大ジャンプしてないのかも。
  • 限定的にするように話をすり替えているのかも