23
サービス開発者の 読書会 #6 2012.5.29 ConnectStar

20120529 アジャイルサムライ読書会第6回

Embed Size (px)

DESCRIPTION

アジャイルサムライ読書会、第6回はイテレーション(固定した期間)の回し方ついてです。 私達の読書会は、サービス開発に関わる人(プランナー/プログラマー/デザイナーなど誰でも)がよりよいサービス開発のあり方について、お題になった本を通じて、共通認識をもったり知識を交換したり、建設的に議論したりする場です。 2012年4月からは「アジャイルサムライ」を読んでいます。

Citation preview

Page 1: 20120529 アジャイルサムライ読書会第6回

サービス開発者の読書会 #6

2012.5.29 ConnectStar

Page 2: 20120529 アジャイルサムライ読書会第6回

アジェンダ

• 前回の振り返り(KPT)•エピックについて(前回の宿題)•イテレーションについてまとめ•まとめ

Page 3: 20120529 アジャイルサムライ読書会第6回

KPT

Page 4: 20120529 アジャイルサムライ読書会第6回

エピックについて

Page 5: 20120529 アジャイルサムライ読書会第6回

Epic?• ユーザー・ストーリーには階層を持たせることもできます。エピックとは、さらに大まかに機能や機能性について説明したユーザー・ストーリーのことです。(中略)例えば図 1 に示す 1 つのエピックは、複数のユーザー・ストーリーに分解されています。

IBM DeveloperWorks http://www.ibm.com/developerworks/jp/linux/library/l-agile-plan/

Page 6: 20120529 アジャイルサムライ読書会第6回

Epic?

• エピック=大きなユーザーストーリー• マンガをシェアできる(エピック)• マンガ名で検索できる(ストーリー)• 作者名で検索できる(ストーリー)• 一言コメントがかける(ストーリー)• etc...みたいな?

Page 7: 20120529 アジャイルサムライ読書会第6回

Epic in PivotalTracker

Page 8: 20120529 アジャイルサムライ読書会第6回

Epic in PivotalTracker• 複数のユーザーストーリーをまとめられる• ポイントのボリュームが相対的になんとなくわかる

• エピック名のラベルが自動的につく

• ストーリー<エピック

• リリース=ただのマイルストン。旗。

• エピック=人が入った時にあるとわかりやすそう。大きい単位で把握したい人のために。

Page 9: 20120529 アジャイルサムライ読書会第6回

コネクトスターのエピック

• 世の中はそれぞれ定義して使ってる、けど• コネスタでのどういう風に定義するかは、PivotalTrackerをちょっと運用してみて、今ある機能で足りないよねってなったら、決めてこう。

• まずは、エピックなしで、運用してみよう!

Page 10: 20120529 アジャイルサムライ読書会第6回

イテレーションについて

Page 11: 20120529 アジャイルサムライ読書会第6回

イテレーションとは• イテレーション=期間を固定したタイムボックス• イテレーション≠リリース• 1~2週間で固定しよう• コネスタでも運用はそれくらいにしてるね。今後、まとまった開発でも1~2週間の区切りを意識しよう。

• 基本単位は1週間で、ストーリーによっては1週間を2回使うというスタンスでいこう!

Page 12: 20120529 アジャイルサムライ読書会第6回

イテレーションのゴール

• お客さん(クライアント)に価値ある成果を届けること

•自社サービス開発では、誰に価値ある成果を届ければいいの?

Page 13: 20120529 アジャイルサムライ読書会第6回

誰に「価値ある成果」を届ければいいの?

• 自社サービスにクライアントがいない

• ユーザへ届けるのは「リリース」(リリース=価値あるストーリーのセット)

• 運用では、イテレーション=リリースになりがちだから、ユーザに価値届けている。

• 「価値ある成果」を届ける最小単位はチームメンバーで、その後ユーザだよね!

• クライアントワークだとお客さんと信頼築くのもある。私達はチームメンバーに成果を届けることを意識しよう。

Page 14: 20120529 アジャイルサムライ読書会第6回

イテレーションで肝に命じること

1. 文書は必要な分を必要なときに

2. コードはきちんと設計してしっかりテストしてばっちり結合した状態に。

3. テストは開発と一緒に。プロジェクト初日から、システムが全体として適切に動作し続けるようにしなくちゃいけない

Page 15: 20120529 アジャイルサムライ読書会第6回

テストについて• 単体テスト、結合テスト、受け入れテスト• プロトタイプは書かないという主義もあり• 書き方がわかってれば、書いたほうが結果手戻りないからいいかも

• テスト書くスキルも習得しよう• だから、やっていこう!!!

Page 16: 20120529 アジャイルサムライ読書会第6回

イテレーションのメリット

• プロジェクトの方向性の修正が容易•例えば• 優先順位がかわった• 予期せぬ自体が発生した

Page 17: 20120529 アジャイルサムライ読書会第6回

イテレーションの流れ

1.ストーリーを分析・設計

2.開発

3.テスト

必要な分を、必要な時に。作業を増やすのは必要になってから。

Page 18: 20120529 アジャイルサムライ読書会第6回

分析・設計

• 作業の段取りをつけよう• 実装中に次のストーリーの分析・設計しよう• 文書化はチームにとって適正なレベルで• Redmineのチケット→PivotalTrackrへ移行します• Wiki機能は、引き続きRedmineで。他にいい方法がないか探してみよう

Page 19: 20120529 アジャイルサムライ読書会第6回

システムの設計• エンジニアが一人でやってるけど。。。?• レビューはいいけど、皆でやると思想がばらついて非効率かも• 私達はRailsつかってるからある程度思想共有できてるという前提にある。

• ペアプログラミングで、思想をぶつけあうのはやるといいかも。• プランナーと仕様考える時に設計レベルで共有しながら進めるのはよさそう

• これで、どこが大変なのか伝わるし、リーンにできる部分を話し合える

Page 20: 20120529 アジャイルサムライ読書会第6回

開発

• 本格的なエンジニアリングのプロセスで•イテレーションが始まる前に、「イテレーションゼロ」をきっちりやろう(開発前のもろもろの準備)

Page 21: 20120529 アジャイルサムライ読書会第6回

イテレーションゼロ

•実はやらない人多いかも?• でも、そこではまると終わりになってしまう。イテレーションゼロ、意識的にきちんとやっていこう。

• Herokuはイテレーションゼロで必要な作業をやってくれるから、早く作るには便利

Page 22: 20120529 アジャイルサムライ読書会第6回

テスト• いつでもリリース可能な状態のために、ちょこちょこテストするけど、最後にもう一度

•お客さんが本気で確認するから•いつでもリリース可能を達成できるチームは少ないから

•テスト自動化しよう

Page 23: 20120529 アジャイルサムライ読書会第6回

KPT