カイゼンにっき。

@hyokota です。主にtwitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。

イテレーション毎に価値ある成果を届ける 〜アジャイルサムライ読書会 横浜道場 「現場で実践する」に参加しました #agilesamurai #横浜道場 〜

アジャイルサムライ読書会 横浜道場 「現場で実践する」 - アジャイルサムライ読書会 横浜道場に参加させて頂きました。

下記、勉強会にインスパイアされて、私が学んだ/感じたことのまとめです。
※例によって、勉強会のまとめではなく、内容のごく一部にしか触れていないことにご注意を。

アジャイルサムライ横浜道場にご興味を持たれた方はこちらをチェック!

イテレーションのゴール = 顧客に価値ある成果を届けること

イテレーションのゴールは、お客さんに取って価値ある成果を届けることだ。」
本日は、これまで何気なく読み飛ばしてしまいがちな一文に引きつけられました。

  • 「設計書」のような、その時点では何者でもないもの
  • 納品出来ない品質のコード

ではよくない、というのはもちろんなのですが、

  • それだけでは何も生み出さない「機能」
  • もう1イテレーション実施すれば、価値を生み出すであろう「中間物」
  • とりあえず動くソフトウェア

でも充分でない。そして、もっとも重要な点として、下記を感じ取りました。

  • たとえ、「ストーリー」を実現するフィーチャーを作っても、「お客さん」に「価値」を届けなかったら意味がない。

お客さんは誰なのか、この1イテレーションの間に、「価値」を届けるにはどうすればよいか。その中でも最も優先度の高い価値は?一文から改めていろいろと考えさせられました。

※私は、何となくふわっとした「とても抽象的な」レベルの「顧客」が、「もしかしたら必要かもしれない」何かをする、そんなレベルのストーリーを記述しがちだったで、よい学びとなりました。具体的な顧客像、具体的な顧客の課題感(の仮説)が大切。

必要なとき、必要な分だけ

いち早く価値を届ける為には、早すぎる最適化を防止し、「選択と集中」を行う必要がある。
分析やバックエンドの準備は、必要なとき、必要な分だけ。

必要なとき

必要性を感じた時がそのとき

  • 「DB」も、必要が生じたタイミングでアーキテクチャジャンプをする、のがよい?
必要な分だけ

分析なら、プランニングポーカーで、見積もりのコンセンサスが得られる程度の分析。

  • つまり、チームのレベル、ドメインやアーキテクチャへの習熟度にも(もちろん)依存。 画一的な方法論(常にモデル書こうぜ、とか)はよろしくなさそう。

参考図書

アジャイルサムライ−達人開発者への道−アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series (Beck))

開催頂いた @tw_takubon さん、皆さん、素晴らしい場を設けて頂きありがとうございます。