fc2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

アジャイルサムライ読書会 横浜道場 「イテレーションの運営:実現させる」に参加しました

2013/3/5(火) アジャイルサムライ読書会 横浜道場 「イテレーションの運営:実現させる」に参加してきました。

DoorKeeper(告知サイト)
http://yokohama-dojo.doorkeeper.jp/events/2911

以下の書籍をターゲットとした読書会なのです。

アジャイルサムライ−達人開発者への道−アジャイルサムライ−達人開発者への道−
(2011/07/16)
Jonathan Rasmusson

商品詳細を見る


場所はいつもの横浜、アットウェアさんで、参加者は20人くらいでしょうか。
今日は第9章「イテレーションの運営:実現させる」から読書でした。

ウチのチームは5名で、ディスカッションのホワイトボードと付箋はこんなカンジ。
20130305_横浜道場

以下、チームでのディスカッションした内容を中心に、自分用メモ。


■テストは開発と一緒になって進めていく必要がある。

■必要な分だけを必要なときに

■必要なときに分析する
 → ストーリーの実装を予定しているイテレーションの1つ前のイテレーションで分析する
   (イテレーション(n)で分析して、イテレーション(n+1)でストーリーとして開発する)

■1つ前で分析するのは、シナリオのレベル。
 → そのイテレーションの先頭で、1つ前で分析したシナリオをタスクに分解する。

■やりすぎないことが肝心。後になって状況がガラッと変わることもよくある話。

■大事なのは創意と工夫。

■イテレーション・ゼロ
・イテレーション・ゼロで実施することを、イテレーション・ゼロの前に分析する必要がある。
 (何が事前準備として必要かを、事前に検討する)
・開発環境とステージング環境をイテレーション・ゼロで合わせておく。
 (後々になって環境の差異で泣かされることがないように)
・イテレーション・ゼロは最初の1回だけでなくても良いのでは。必要になったらまたやる。
 (例えば本番前に、本番環境の準備として再度イテレーション・ゼロ)を設けるとか。
・↑はイテレーション・ゼロじゃなくて、スパイクを必要なときに打てばいいんじゃないか。
・テスト自動化の仕組みはプロダクトコードが無いイテレーション・ゼロの段階から準備しておく。
・イテレーション・ゼロでプロト的にストーリーを1つ実装して、お客さんに価値を届けるのもアリ。
 (開発することで、開発環境や構成管理、各種プロセスの認知・共有に繋がる)

■「スパイク」という用語について
・調査用のプロトタイピングの事を、エクストリーム・プログラミングでは、特に「スパイク」と呼ぶらしい。
・開発作業の中で見積りや技術検証などに試行錯誤するタスクのことを「スパイク」と呼ぶらしい。
・早期にアーキテクチャを検証することを、アーキテクチャスパイクとも呼ぶらしい。

■受入条件を事前に明確にしておく。(Doneの定義)

■ストーリーボードとカンバンは違う。
・ストーリーボード: 11章で。
・カンバン: 以下参照。

■カンバン
・WIP(Work In Progress)に上限を設けている。
・イテレーション(タイムボックス)は必要ない。気にかけるのは作業リストにある優先順位の高い作業だけ。
・即対応が求められたり、決まった長さで作業できないような、運用・サポートのチームならカンバンのほうが向いている。

■成果を届けるための秘訣は、機能の切り口をエンドツーエンドにして薄くスライスするにはどうしたらよいかを考え抜くこと。

■手作業はDoneの定義がゆるくなる。(妥協が入りやすい)

■自己組織化に関連したものにCMMIがある、という話題が出た。
 → CMMIは成熟度を測る指標だが、監査の要素が強いのでストレスの要因になる。

■タスクは横(メソッド単位)でなく縦(機能単位)に切るべき。
 (横に切ると、開発者がなぜそれが必要なのかわかりにくくなりモチベーションも上がらない、という意見あり)


★感想:

あらためて9章を読み返してみると新しい気付きがたくさん得られて、ちょっとした驚きでした。
読み返して再認識し、新しい点に気付き、ディスカッションで更に深みに入るというか。
今回は4回のスプリントでちょうど9章全体を読めましたし、スコープもちょうど良い感じでした。

あと、今回は初参加の方が比較的多かったようです。
ウチのチームも5人中、2人が初参加でした。新しい風が入るのは良いですね。

あとゲーム会社のエンジニアさんとかのお話を聞いていると、作業開始からリリースまでに1ヶ月しかない、なんて話も結構あるようで、そうなるとチームのプロセスの改善やリファクタリングが後回しになってしまう状況も見られるようです。
確かにリリースまで1ヶ月じゃあ、プロセス改善の効果が染み入る前に終わってしまうので、改善作業の優先度が落ちてしまうのはある程度、納得です。
更にソーシャルゲームのように製品が短命だと、リファクタリングする効果も薄れますし。

技術的負債を解決する工数とタイミングのバランス、この辺は難しい問題だなぁ、と思いました。。。。

次回はまどマギ編ということで、それまでに全話見れるかなぁ。。。

最後に道場主さん、運営者さん、参加者の皆さん、ありがとうございました。

-->