Readingagilesamuraiinshimane20120126
← Readingagilesamuraiinshimane
sousk3さんが第5回読書会についてまとめて下さいました！ こちらから
第4回読書会 の藩のまとめをプロジェクターに写しながら、発起人の考えを述べさせて頂きました。
- 我々はなぜここにいるのか
- 大きな意味での「何のために」を忘れないため
- 現場の人の気持ちを理解することを忘れないため
- 一方でコストや時間的にそばに行きたくても行けないこともあるよね
- エレベーターピッチ
- 端的に説明できるようにする
- お客さんと自分達の間で、ある物事を指していても、ほんとにあっているのか？歩調が合わなくなることもある
- 端的に説明できるようにする
- パッケージデザイン
- 分かりにくい効果の時はどうしよう
- RubyとかAgileとかって割と分かりにくい概念なので、時には誇張も必要だよね
- 分かりにくい効果の時はどうしよう
- やらないことリストをつくる
- 後で決めるリストが多すぎる場合はどうメンテしよう
- 後で決めるにしても期限をきめよう
- ご近所さんを探せ
- 本人の意識、率先していろんなつながりを見つけて行く気持ちが大事
- RubyとかAgileとかってフィーチャーなのかもしれない
- 人によって説明を使い分ける
- Rubyを使うことが目的だろうか…。
- 解決案
- 認識の共有
- 色々な解決策があると思うが、それを共有する方法を明確にしておく必要があるのでは
- 良いチームメイトを集めるには
- 母数が大きい企業は選択の余地があり自由度が高いが小規模な企業だとどうすんだろう。現実的には決められたメンバーでスタートするだろう
- それぞれが思っているリスク、不安に思っていることを共有するだけでも違うが、リスクの度合いについても話し合おう。また、リスクに対しての責任者も決めておこう
- 期間ありきで考えると取捨選択もしやすいだろう
- 対応責任者とは？リスクの度合いを決める人？対応する人？
- 責任者を決めておいた方が進めやすい
- リスクの重要度は顧客に与える影響度で決めるべき。そのプロセスが知りたい
- 現場で確かめる、感じることが大事
- 司令官ってだれだろう
- 顧客の意思決定をする人
- スポンサーって面白いね
- 我々技術者が技術を練磨するためにお金を出してもらえるそういう考え方もできますね
- 名前やパッケージデザインを作ることで、プロダクトに命が吹き込まれる。そして、愛着が湧く
- 石の絵が面白い
- 言いたいことを端的に表している
- やること
- 整理されている→きれいに積んである石
- やらないこと
- 整理されていない→散らばっている石
- ご近所さん
- 顔が分からないと話にくいので挨拶から始めよう
- 4章はなぜ、5章はどうやって の内容だと思う
- 確かめるんだ！はいい言葉。能動的。
- 大きな金槌の話
- そうなんだけど、チームのメンバーが決まったらアーキテクチャが決めるということ。この会社を選んだからにはRubyでいくんだと解釈すること。それでいいと思う。アーキテクチャーは俗人的なものだと理解する。
- 時間を機械的に設定した。
- 黙読は1ページ1分
- 討論は1ページ1.5分
- 発表は2分、質疑応答は3分
- 発表に対してアドバイスすることができた。
- 時間の箱に収めることができた。
- 藩の発表に対して自分の意見を伝えることができた。
- 討論の時間
- 時間を機械的に設定する
- 人が集まる！！
- すべて読むことができなかった
- 予習しようぜ
xx.x → 第5回読書会 → xx.x
Readingagilesamuraiinshimane20120112 ← → Readingagilesamuraiinshimane20120209