Readingagilesamuraiinhde20130702

「アジャイルサムライ」読書会 in HDE 第一回 の記録

意見交換の記録

• 例えば Web サービスを受託開発している会社にとっては、誰を顧客として見れば良いのか？

  • 発注元の会社、及び E/U などのステークホルダー全員が顧客となりうる？
  • 全員が顧客と考えると、意識が発散してしまう。この場合は開発したサービスを実際に 運営する発注元の会社が顧客(プロダクトオーナー)なのではないか?
  • では E/U のことを考えずに、発注元の会社の指示にハイハイと従っているだけで良いのか?
  • E/U にとって価値の無いシステムを作ってしまえば、それは発注元の会社の不利益となって しまうので、 E/U のことも考えて仕様について意見するべき
  • 関わる人みんながハッピーになれるシステムが理想だよね

• 「保守するのは人間」という部分が印象に残った(3人同じ意見)

  • 動いてるのが仕様という姿勢は良くない
  • 製品の Bad な仕様について「運用でカバーすれば」は酷い！！ (インフラエンジニアの3人が頷く)

• アジャイルを広めるのを妨げる敵にはどう対処すれば良い？

  • 変化を恐れる人
    • 実利的なメリットを提案？ (残業が少なくなるよとか)
    • 少数のアジャイルの意識が高い人たちで実績を作ってみるとか
    • アジャイルを押し付けずに、自分がまずアジャイルを実践しつつ徐々に浸透させるのも有効かも
  • 従来の開発スタイルの"ここ"が良いからアジャイルを受け入れてくれない人もいる？
  • 最近ではアジャイルでやってくれというお客様もいる！
    • そんなプロジェクトはきっと幸せ

• Joel on Software という本に XP はやり過ぎと書いてあった

  • 効率よくコードを書くために、仕様書はやっぱり書かないといけない
  • アジャイル万歳と短絡的に考えずに、チームに合った方法を選ぶのが良いのでは？
  • アジャイルの考え方自体はは余りガチガチではない(１章に書いてある)
    • そもそもアジャイルって何？

読書会自体の振り返り

Keep

• 第一回にしてこれだけ議論が活発。この活発さを維持したい
• 参加人数は MAX 12 人くらいをキープしたい(それ以上いると進行が遅れるリスク)
• 開催時間は今回位で丁度良い
• 付箋を使った意見交換は良かった

Probrem

• 読み進めるスピードが遅い。意見交換の時間を区切るようにすると捗るのでは

Try

• 一トピックについて意見する人を絞って時間短縮するのはどうか (二人までとか)
• 付箋は一人一枚に絞ると時間節約になりそう

その他

• IT カレンダー経由で参加された人が多い