More Related Content
What's hot
Viewers also liked
Viewers also liked (18)
Similar to 読書会Vol6
Similar to 読書会Vol6 (20)
More from Mari Takahashi
Recently uploaded
Recently uploaded (15)
読書会Vol6
- 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...みたいな？
- 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