Readingagilesamuraiinshimane20120308 - agile-samurai-ja/support GitHub Wiki

Readingagilesamuraiinshimane

第6回、7回読書会ふりかえり

第6回7回 読書会の藩のまとめをプロジェクターに写しながら、発起人の考えを述べさせて頂きました。

各藩 討論の内容

AndroidAppricationAward2012藩

P1010052 P1000994 P1010040

第9章 9.1 - 9.4
  • 必要な時に必要な分だけ分析するについて
    • 意外と難しいよね。
    • あるイテレーションの対象となる要件だけを分析しても、次のイテレーションで矛盾が生じて、破棄しなければならないというケースも出てくるのでは。
    • 単体のイテレーションだけを見ても無理があるので、全体を把握した上で個別の要件を掘り下げた方がいいのではという話。
  • 質疑応答
    • 日本人は割と段取りが好き!という感想について、なぜそう思った?
      • 一般的にそういう傾向があるのではと思う。
      • 私の周りには先を見据えながら仕事をする人が多い。次の次を考えながら、今の仕事をするということ。
      • 狩猟民族ではないからかな…?
      • 必要な時に必要な分だけ分析することが得意じゃないかも。

P1010031 P1010043

第9章 9.5 - 9.7
  • イテレーションゼロのはなし
    • 準備が大事
  • 看板
    • 仕掛に上限をつけるやり方イイね。やってみたい!
    • プロダクトオーナーがイテレーションの途中でもチームの進捗具合が把握できてよい。
    • ただし、看板ボードを見てPOがちゃちゃ入れてきたらチームにとっては不健康になりそう。
  • テスト
    • お客さんはあんまりテストしないよね。
    • テスト専任部隊を置けると幸せ?
    • 想像してみよう!テスト専任部隊が毎週月曜日、新しいタスクを持ってくる映像を。涙が出る…。
  • イテレーションゼロのコストの話
    • イテレーションゼロを組まなくても最終的には同じコストがかかるよね。
    • イテレーションゼロの何がコストがかかる?
      • 環境設定
      • 例外のハンドリングポリシー
      • ログポリシー
    • イテレーションはアウトプットをする為のイテレーション。イテレーションゼロだとストーリーを消化できないのでお客さんに価値を届けているようには見えない。そこに対してどうやってお金を貰いますか?どうお客様の価値に変えていくのか?
      • WFだと見積もりに入っている。
      • お客様にも分かりやすい形でストーリーに書く?
    • ユーザーからすると最初から準備できてんじゃないの?って思う。それをどこでやろうというのか?
      • これまでのWFでは、裏で勝手にやってて、こっそりお金とってましたよ。
      • Agileではどうやるの?
    • イテレーションゼロのユーザーストーリーってどんなものがあがるの?
      • 端末の準備
      • 開発環境の準備
      • データベースを決めたりインストールしたり
      • Redmine用意したりとか。
    • 結局コストは濁すのか、濁さないのか?Agileでも濁すのか…?
      • それにも価値があるとオーナーに説明する、認めない人には濁すのが現実的。
    • 現実的ではないがジャストインタイムの考え方だと…
      • 何もないところ、例えば、IDE無し、進捗管理ツール無し、DB無し、というところからイテレーション始めてみて、ふりかえりのTryに挙げて、オーナーに納得してもらってイテレーションゼロのようなストーリーを出すとか。
      • それ、イタリアワールドカップの時のオシムと同じ。
      • (一同号泣)

P1010145 P1010149

大賞藩

P1000982 P1000990 P1010015

第9章 9.1 - 9.4
皆さん、プロジェクトを開始した時にリーダーの役割として参加した経験があると思います。
開発を進めていて手を取られること。それは、メンバーがやたらと仕様を聞いてくることです。
それを防ぐのがジャストインタイム分析。
ストーリーカードの裏にお客さんと話をしてこれだったら受け入れてもらえるということを明記しておく。
それを、きっちりやることでプロジェクトがドライブするんです。
WFでも全然できます。リーダーとユーザーがちゃんと話をしてお互いのゴールやる前に正確に見える化することが重要です。
その時に大切なことは、動作し続けるプロダクトであること。動いたという状態で家路につくこと。

P1010020 P1010044

第9章 9.5 - 9.7
  • カンバン
    • やりやすいね。効果がありそう。
    • 見積もりがシンプルにできるね。
    • 見積もりについて
      • 見積もりにはポイントとイテレーションが必要だと仮定すると、カンバンにはポイントが付いているので期待はマネジメントできるけど、イテレーションがないので見積もりまではできない。成果をマネジメントをするには至らない。
  • ペアプロについて
    • ペアプロがどうすればうまくいくか
      • 海外だとうまくいく、日本だとうまくいかない
      • 日本は師匠と弟子の関係になってしまいがち。師匠の成果物になってしまい、一馬力にしかならない。
      • 海外は「自称天才」なイメージがあり、言いたいことをボスに対しても言える。対等な関係が気付けるのでうまくいくのではないか。
      • evenな関係づくりがペアプロには必要。
  • 質疑応答
    • 日本で師匠同士が組むとどうなるんでしょう?
      • クックパットみたい企業だと師匠同士が組む可能性はあるけど、自分の周りでは見たことない。
      • 贅沢、もったいない、師匠同士はペアを分けられちゃいそう。
      • 日本にはそもそもそんなに師匠がいない…?
      • 海外でもスキル的には師匠と弟子の関係はあると思う。でも、言いたいことを言える環境かどうかがポイント。
    • オープンソースサロンで海外の方がペアプロの話をされた時、問題点をいくつか紹介していた。
      • 喧嘩してしまう
      • レベルの差が大きすぎると教えるばかりでスピードが上がらない。
      • 日本には入社年次の若い人が古い人に言えないという課題もあるよね。
  • 師匠と弟子、入社年次、レベルの違い、課題はいくつかあるが、お互いの意見を尊重して気兼ねなく言い合える環境を作っていこう!

P1010138 P1010152 P1010153

893円藩

P1010054 P1010081 P1010116

第9章 9.1 - 9.4
  • ジャストインタイム分析
    • 必要な分だけを必要な時にアウトプットする時に必要。
    • お客さんの要求も絶えず変わるものということをお互い理解したうえで分析できたらいいね。
    • どれだけの時間を分析に費やすのか。
      • 経験談として、イテレーションの中で分析するより、イテレーションの合間に1日掛けて分析している。お客様を交えて、いっしょにニーズを引き出しながら分析してました。
  • 質疑応答
    • いつ、どれだけ時間をかけるか、経験をお持ちの方、教えて下さい。
      • 本の中では、次のイテレーションの分析は、前のイテレーションの最中にすると書いてあったが、僕はお勧めしない。お客様としてはそのイテレーションに集中してもらいたいから。
      • 大雑把な分析は最初にやっておいて、細かい分析をイテレーションの合間に行うと、分析に時間を取られる必要がないかもしれません。

P1010004 P1010049 P1010050

第9章 9.5 - 9.7
  • ペアプロ
    • 経験してて問題点がありました?
      • コミュニケーション取りながらやるから疲れる、スピードが遅くなる。
    • 共有しながら進める分、レビュー時間が短縮されるというメリットもある。
    • プログラミングだけでなく設計やりテストのペアワークも良かった。
  • カンバンとイテレーション
    • うちのSaaSの運用部隊はカンバンを使っている
    • 制約を設けて挑むのならイテレーションの方が望ましい。
  • イテレーションゼロ
    • 係るコストはだれが払うのか。
  • 質疑応答
    • ペアワークはどんなもの?
      • DBの設計など…。いっしょに考えることが大事。
    • カンバンっていいの?どうなの?
      • プロジェクトには終わりがある。プロジェクトじゃない仕事には、イテレーションがハマらないケースもあり、そこへのカンバンは使えると思う。
      • うちの会社にも終わりがある…。
    • カンバンって何のため?
      • 気分良く仕事をするため。仕掛りに上限を設け、先入れ先出しを徹底することで、他の大量のタスクを見えなくして、集中することができる。
      • 顧客志向ではないような。だって、イテレーションは回さないので期日が決まっていないわけで。定期的に価値を届ける保証がないということ。カンバンだと甘えが出ちゃうと思うな。
      • 甘えがでるものはイテレーションでやればよい。運用は定期的に何かをやる、インシデントで何かをするなので、そういうところにはカンバンが向いている。
      • イテレーションの中でカンバンを使うと、カンバンに乗っかっているタスクは顧客に価値に直結するとは言えないが一つ一つのタスクは顧客価値の大事なピース。タスクを片付けることがお客さんの価値に繋がる。

P1010121 P1010155 P1010158

発起人ふりかえり

Keep

  • 久しぶりの3藩!多数のご参加に感謝♪

Problem

  • 役割を決めるのに時間かかってしまって、議論の時間が十分に取れてない印象を受けた。
  • 議論が活発になるとどうしても時間の箱に収まらない…。延長してでも議論したい参加者もいれば、時間通りに終わりたい参加者もいる。どう折り合いをつけるか…。
  • 参加人数によって、当初想定してたタイムボックスが崩れてしまう…。

Try

  • 読み進める内容を減らし、議論と発表の時間を多くとってみる。
  • 簡単に役割を決める方法を考える。

参加者ふりかえり

Keep

  • 参加し続ける
  • 時間の箱を意識しながら発表すること
  • みんなの価値観が違うからこそ楽しい
  • 遅れたけど参加した。参加して良かった!!
  • いじる
  • 経験を交えながら意見交換できた
  • 2回発表できた
  • 事前に読んでおく
  • 予習&参加
  • 討論の進行と発表を自主的にできた
  • 発言をする
  • テーマについて多方面から見たり聞いたりする
  • カンバンの心得を忘れるなかれ!

Problem

  • 今回初めて読みました…
  • 周りを気にかけることが出来なかった
  • 15分延長したこと
  • 時間内で読み切れなかった
  • 意見をまとめた上で発表することができなかった
  • 時間を見ていない
  • 緊張しすぎてしまう
  • 予習
  • 本の内容を理解せず、討論に入ってしまった
  • 付箋を書けなかった。読み切れなかった。
  • 時間配分
  • 涙しばりはキツイ…。
  • イテレーションゼロについてうまく説明できなかった
  • カンバンの話をミスリーディングした。人に説明できると思うなら本くらい読めるようにならないとね。
  • 魅せるホワイトボードのまとめ方をもう少し頑張る。

Try

  • 本を買って予習する!!
  • この後の飲み会に参加♪
  • 早く終わるくらいの余裕をもったタイムマネジメントをする
  • 討論、発表の役割は、一度決めたら固定で良い(のでは?)
  • 他のロールもする
  • 時間を気にしながらDo
  • まず、白い板にTwitterIDを書く
  • 時計を持ってくる
  • 予習する
  • 次回も参加する
  • 落ち着く
  • 復習する!!
  • 予習を十分に!
  • オシム以外の金槌を手に入れる!
  • 自分の業務にカンバンを取り入れているけど、もっと有効活用するっ!!
  • WITを知ったので使ってみよう。
  • 分析力を高めていきたい

SAPA ~ ShimaneAgilityPointAverage ~

15.5 → 第8回読書会 → 25.0

今週の"彩鮮酒楽 やぁ"

P1010175

Readingagilesamuraiinshimane20120223 ← → Readingagilesamuraiinshimane20120322

⚠️ **GitHub.com Fallback** ⚠️