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

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

2. アジェンダ
• 前回の振り返り（KPT）
• エピックについて（前回の宿題）
• イテレーションについてまとめ
• まとめ

3. KPT

4. エピックについて

5. Epic？
• ユーザー・ストーリーには階層を持たせることもでき
ます。エピックとは、さらに大まかに機能や機能性に
ついて説明したユーザー・ストーリーのことです。
（中略）例えば図 1 に示す 1 つのエピックは、複数の
ユーザー・ストーリーに分解されています。
IBM DeveloperWorks http://www.ibm.com/developerworks/jp/linux/library/l-agile-plan/

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

7. Epic in PivotalTracker

8. Epic in PivotalTracker
• 複数のユーザーストーリーをまとめられる
• ポイントのボリュームが相対的になんとなく
わかる
• エピック名のラベルが自動的につく
• ストーリー＜エピック
• リリース＝ただのマイルストン。旗。
• エピック＝人が入った時にあるとわかりやすそう。大きい単位で把握し
たい人のために。

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

10. イテレーションについて

11. イテレーションとは
• イテレーション＝期間を固定したタイムボックス
• イテレーション リリース
• 1∼2週間で固定しよう
• コネスタでも運用はそれくらいにしてるね。今後、
まとまった開発でも1∼2週間の区切りを意識しよ
う。
• 基本単位は1週間で、ストーリーによっては1週間を
2回使うというスタンスでいこう！

12. イテレーションのゴール
• お客さん（クライアント）に価値ある成
果を届けること
• 自社サービス開発では、誰に価値ある
成果を届ければいいの？

13. 誰に「価値ある成果」を
届ければいいの？
• 自社サービスにクライアントがいない
• ユーザへ届けるのは「リリース」（リリース＝価値あるストー
リーのセット）
• 運用では、イテレーション=リリースになりがちだから、ユーザ
に価値届けている。
• 「価値ある成果」を届ける最小単位はチームメンバーで、その後
ユーザだよね！
• クライアントワークだとお客さんと信頼築くのもある。私達は
チームメンバーに成果を届けることを意識しよう。

14. イテレーションで
肝に命じること
1. 文書は必要な分を必要なときに
2. コードはきちんと設計してしっかりテストして
ばっちり結合した状態に。
3. テストは開発と一緒に。プロジェクト初日か
ら、システムが全体として適切に動作し続ける
ようにしなくちゃいけない

15. テストについて
• 単体テスト、結合テスト、受け入れテスト
• プロトタイプは書かないという主義もあり
• 書き方がわかってれば、書いたほうが結果手戻りな
いからいいかも
• テスト書くスキルも習得しよう
• だから、やっていこう！！！

16. イテレーションのメリット
• プロジェクトの方向性の修正が容易
• 例えば
• 優先順位がかわった
• 予期せぬ自体が発生した

17. イテレーションの流れ
1. ストーリーを分析・設計
2. 開発
3. テスト
必要な分を、必要な時に。
作業を増やすのは必要になってから。

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

19. システムの設計
• エンジニアが一人でやってるけど。。。？
• レビューはいいけど、皆でやると思想がばらついて非効率かも
• 私達はRailsつかってるからある程度思想共有できてるという前提
にある。
• ペアプログラミングで、思想をぶつけあうのはやるといいかも。
• プランナーと仕様考える時に設計レベルで共有しながら進めるの
はよさそう
• これで、どこが大変なのか伝わるし、リーンにできる部分を話し合える

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

21. イテレーションゼロ
• 実はやらない人多いかも？
• でも、そこではまると終わりになってしま
う。イテレーションゼロ、意識的にきちん
とやっていこう。
• Herokuはイテレーションゼロで必要な作
業をやってくれるから、早く作るには便利

22. テスト
• いつでもリリース可能な状態のために、
ちょこちょこテストするけど、最後にも
う一度
• お客さんが本気で確認するから
• いつでもリリース可能を達成できるチー
ムは少ないから
• テスト自動化しよう

23. KPT