@rinunuさんに誘いいただいた、スクラム勉強会に行ってきました。
幹事の@matsukazさんとは少し前からmongoDB周りで色々お話させていただいていたのですが、
この日が一番しっかり話したかなぁ。。行動力の素晴らしい方です。見習いたい。

今回の勉強会はタイトルほど、すくらむすくらむしていなくて、アジャイル開発ってなんすかー( ゚д゚)
って人でも、とてもわかりやすい(であろうと思われる)プレゼンを聞くことができました。


以下、メモの転載です。


@unlearnedさん】
遅刻しての参加だったため、最初の方はお聞きできませんでした・・・
ただ、結構な勢いでウォーターフォールをdisってたのが印象的でした。
米国防総省ってそんなにウケるキーワードだったとは知りませんでしたw

<まとめ>
● ウォーターフォールはシステムの学習には有効
  →理解しやすい順番ではある。
● アジャイルプロジェクトは大規模プロジェクトでも有効
  →米国防総省でも取り入れられている
● 人は要求をあらかじめ定義できるほど賢くない

● 整備されたドキュメントと、プロジェクトの成功には、弱い関係しかない

● ウォーターフォールは失敗するやりかた

(所感)
個人的には1、3番目が分かりやすくて納得でした。
いつも痛感するのが3番だったりするので、、、賢くない自分を補うための
ベストプラクティスというか先人の知恵は、どんどん活用したいところです。
国防総省なんやねん、と思っていたけど、国防総省がウォーターフォールモデルを標準として
採用したことがその後のWFの広まりの発端?になってるから的な理由だったのですね。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@bash0C7さん】
★ アジャイルの先にあるもの事業の成功

● アジャイル → "最速最高のプロダクトリリースサイクル"
・アジャイル戦略室って組織がECナビさん(グループ)にはあるとのこと

・事業のキモから

・最速でpdcaサイクル

● アジャイルざっくり
・壮大なビジョン(の共有)
・物語(ユーザーストーリー)たちで織り成す
  → 物語がリリースの単位
  → 付箋に書いて列挙
・大事な順に一列に
  → どれが一番大事なの!?
  → product backlog
    → 機能ごとにより詳細に(sprint backlog)
・大事な物語に全てを集中
・小さく分けて、確実に作る
・実際に使ってもらって完成

● スクラム(例としては3週間1サイクル)
短い期間を繰り返す
  → 次どうする?(スプリント)

● アジャイルとは言うものの、、こんな失敗も
・プロトタイプを捨てずに利用
・小さく作りすぎる

  → あるある過ぎて笑いながら涙目

★ 重要な箇所から着実に動かす


● アジャイル開発の事例
[team]
事業責任者/ドメインエキスパート/プログラマ/デザイナ
?:ドメインエキスパートの役割は?
  → そのマーケットに対して特に詳しい人。プロダクトオーナと同じ場合もある。

プロダクトオーナ(事業責任者(/スクラムマスタ(やや外部)/チーム(作る人)
・チーム→どれくらいで作れるか?
・ヒエラルキーではなくフラット

● ふろしきをしまう
  → ひろげまくった夢をリリースに向けて収束させる
● 厳密なタイムボックス
  → タイムボックスごとに必ず成果物を

★ 毎週(タイムボックスごと)に成果物が出る
  → ってことは毎週、何か問題が起こる。毎週悩む。
    → その都度捨てる、相談する。
    → 期日は守る

(所感)
「物語」という言葉は、新鮮でしたが、自分自身のプロジェクトを振り返ってみたとき、
新しい機能、サービスを作る上で、「ある1シーン」を細かく詰めていくことが、成功確率の
高い手法であると感じていたので、とてもハラオチできました。
そこからさらに、タイムボックスを決め、期間ごとに成果物をだしていく、という所は
これからの開発ですぐ実践してみたいと思います。
=====================================================


以下、懇親会的なところでの話のメモ。

・ペーパープロトいいよ
  → 行動を口に出してもらう
  (わからない所が明確化できる)
  → ゲームは難しいかもしれないけど、SNSとか、webサイトとかは有効な手法
  → ペーパープロトで出た課題は何度か繰り返しペーパープロトで詰めていく
   →実装する前に、具体的なイメージにいかに落とすか、それをチームでしっかりと共有するか、
   そのための手法として、ペーパープロトはとても有効なやりかたに思えます。
   ブレスト的に、みんなで画面を書いた図を持ち寄っても面白いかも、と思ったり。


● うまいことプロジェクトをすすめるために
・見積に嘘をつかないこと(ちゃんと現実を伝える勇気)
・何を捨てるか/何に借金するか
  →producerの引き出しからより良い物を引き出す、一緒に解決策を考える
・自分を定量化する
  →わからないことは、短期間で自分を振り返り、見積もりを出せるようにする
・ドラスティックに変える時にはリスクがともなうことをきちんと共有する


【アジャイル戦略室の生まれた背景】
・チームとしてどうやるか、が重要
  →事業責任者、プロデューサーに対してどう伝えるか
  プロジェクトはエンジニアだけではない。
  他のメンバーの理解を得るためにもエンジニアのみで立ち上げなかった。
・先行事例があった(UI戦略室)
・他のメンバーと一緒にスクラムマスター研修に
  →相談しながら得るものがあった
・エンジニア、デザイナ、ビジネスメンバーをチームとしてで立ち上げ
・新規プロジェクトと一緒にやる、というところまで準備をして立ち上げ
  →成果を周りにわかるように伝えることが重要
・稼働の2、3割をさくのにOKをもらう
  →片手間でやるより、堂々と出来る(これ重要)


【上記の新規プロジェクトでやってみて】
・毎週振り返りをやってる
・工期の半分いかないくらいでゴールが見えてきた(もちろん課題込みで)
  → このタイミングでわかることが重要、そこから調整しつつ、きちんと期日に成果物を。
開発者のスキルより「姿勢」が重要
  → 話しあって、最高の落とし所を見つける
  → ゴールに対して真摯な姿勢を貫くこと(一蓮托生)



● その他
・「どう作るか」「円滑にすすめるか」は別の話
  → スクラムマスターは別チームの人がやるのが望ましい
 これは聞いてて悩ましかった。いきなり同じような組織を作るのは難しい。
 もう少し小規模に、でも成果を人に伝えられる方法は考えないといけないと感じた。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
長くなりましたがめも終わり。
懇親会でも色々と現場のお話を伺うことができて、とても有意義でした!


一口にアジャイルと言っても、その組織のカラーに合わせることが重要だなと
感じました。ゴールは「事業成果」であって、そのためのプロセスなので。

無意識にやってたこと、新しい気づき、たくさんの勉強会でした。


最後になりますが、発表してくださった@unlearnedさん、@bash0C7さん、取り仕切り頂いた、@matsukazさん、お誘いいただいた@rinunuさん、ありがとうございましたー!