Skip to content

Readingagilesamuraiinchiba20120421

jupitris edited this page Jul 9, 2012 · 8 revisions

アジャイルサムライ読書会 千葉道場 第1回 議事録

読書会の中で話題にあがったものを記録しました。
参加者は、自由に編集してください。

アジャイルサムライ読書会 千葉道場 トップへ

■ 参加人数

  • 4名

■ 実施範囲

  • 第1部(当初は第1章だけだったが、それだけだと物足りなかったので)

■ 会の目的

  • アジャイルサムライを通して、アジャイル開発への理解を深めよう
  • お互いの考えや経験を、自分に生かしてみよう

■ 自己紹介

Q. どうしてこの本を手にとってみたのか?

  • アジャイルをやろうという雰囲気があって、読みやすそうなこの本にきめた
  • アジャイル開発における用語は知っていたけど、どうやって活かせばいいのか、中途半端な知識を保管するために読み始めた
  • アジャイルに興味があった。現場でも取り組みがあった。周りも詳しい。周りがこの本を読んでいたから読み始めた

Q.アジャイルの経験は?

  • スクラムに取り組んだことがある

Q.なんでアジャイルに興味を持ったのか?

  • 本を手にとった理由とだいたい同じ

Q.知りたいこと

  • リファクタリングの重要性をどうやって人にわからせるか
  • ゲーム業界ゆえなのか、リファクタリングする時間が取れない

■ 本を読んでの感想や質問事項

  • 当初の計画からできないとわかった場合、簡単に計画から落とすことができない要件もある

  • 契約違反になる可能性

  • お客さんにとっては、どれもビジネス上重要

  • 信用を失う可能性(次回、契約が取れなくなるかも)

  • できないからって断っていたら、食い扶持がなくならない?

  • 計画から落としてもいいけど、落としてないものについては必ず成果を出すことが前提

  • だしたものがごみくずだった場合は、そもそもアジャイルではない。きちんとうごくものを提出してこそアジャイルと言えるのではないか

  • アジャイル開発チームは、技術力がありモチベーションが高くないと成り立たない

  • モチベーションがあがらない人はどうする?負のオーラを出す人はどうする?

  • 最初からアジャイル開発することを伝えておく(相手が乗り気でなければ契約しない、でも営業がねじ込んでくるときあるからなあ・・・)

  • プロジェクト開始で、アジャイルを宣言しておく

  • マネージャーなりリーダーなりスクラムマスターが、その人の適材適所を探してあげる(アジャイル的には全員が網羅的に役割をこなすんでしょうけど、こういう手段もやむなしだと思う(アジャイルがばっちりハマることが珍しい))

  • そういう人をプロジェクトからはずす

  • 外注であれば契約打ち切り、または更新しない

  • スクラムの絵を貼っておく(http://www.ryuzee.com/contents/blog/4789)

  • スクラムマスターの仕事って?

  • メンバーの特性に合わせた仕事を割り当てることじゃない?

  • ペアプロはどうなの?成果ある?

  • 力量差のあるものが実践するのが望ましいのか?それとも、同レベルのものが実践するのが望ましいのか?結論でず。

  • ゲームプログラムは要求らしいものが明確にはなっていない

  • ゲームプログラムに単体テストがない、また設計がない

  • そもそも単体テストという概念がない

  • テストがしづらい

  • デバイスに影響したりするのでテストできない

  • 一丸となるってどういうことだろう?

  • ウォーターフォールは計画を変更することがあまりできない

  • アジャイルの言葉の意味ってなんなんだろう?なにを達成するとアジャイル?

  • 定期的に成果をだすことがアジャイルか?

  • 定期的にうごくものを提供して行く(ウォーターフォールみたいに、フェーズごとに決められた成果物をだすことが目的ではない)

  • ゲーム開発は開発スパンが短いため、なかなかリファクタリングする時間がない

  • ゲーム開発は面白い面白くないでリリースがきまるため、いくら品質がよくてもそれだけではだめ

  • ゲーム業界でJenkinsはどうなの?

  • ゲームの面白さ優先だから、導入は可能だけど促進されない(要は、リリースしたら終わりなので、継続的ビルドや継続的テストは必要性があまりない)

  • 出せるものを速く出すがアジャイルのいいところ

  • アジャイルって、定期的にサービスを提供し続けるWeb系に向いた手法なのではなかろうか

2章

  • コミュニケーションは大切

  • 気楽にものを言える雰囲気作りは大切

  • フォローがしやすい

  • 失敗を助け合える

  • アジャイルをとりいれてくれない顧客は?

  • その場合は、アジャイルを適用しないほうがよい

  • アジャイルをわかってくれる顧客でないとうまくいかない可能性が高い

  • メンバーを選べる立場にない人はどうする?

  • 上に訴える

  • このメンツでがんばるしかない

  • 可能であれば、アジャイルを受け入れてもらう

  • ゲーム会社は、わりと何でも屋

  • どんな立場(デザイナーでもプログラマーでも)であっても、ゲームの面白さを考えなくてはいけない

  • 最近の開発手法の主流にはのっからない風潮がある(慣れたやり方を好む、プライド)

  • チームを率いる人の影響力は大きい

  • その人によって、やり方が決まることが結構ある

  • チームを率いる人は気をつけたほうがよい

  • 意識の低い「上の人」はどうする?

  • あきらめる

  • プロジェクトからチームごとひきあげる

■ 次回

  • 人数次第でコンテンツを決める
  • 今回、結局第1部を全部やってしまったので、第2部の内容に基づいて話を進める
  • 時期は5/19か5/26あたり

以上

Clone this wiki locally