Upload
connectstar-co-ltd
View
421
Download
3
Tags:
Embed Size (px)
DESCRIPTION
アジャイルサムライ読書会、第6回はイテレーション(固定した期間)の回し方ついてです。 私達の読書会は、サービス開発に関わる人(プランナー/プログラマー/デザイナーなど誰でも)がよりよいサービス開発のあり方について、お題になった本を通じて、共通認識をもったり知識を交換したり、建設的に議論したりする場です。 2012年4月からは「アジャイルサムライ」を読んでいます。
Citation preview
サービス開発者の読書会 #6
2012.5.29 ConnectStar
アジェンダ
• 前回の振り返り(KPT)•エピックについて(前回の宿題)•イテレーションについてまとめ•まとめ
KPT
エピックについて
Epic?• ユーザー・ストーリーには階層を持たせることもできます。エピックとは、さらに大まかに機能や機能性について説明したユーザー・ストーリーのことです。(中略)例えば図 1 に示す 1 つのエピックは、複数のユーザー・ストーリーに分解されています。
IBM DeveloperWorks http://www.ibm.com/developerworks/jp/linux/library/l-agile-plan/
Epic?
• エピック=大きなユーザーストーリー• マンガをシェアできる(エピック)• マンガ名で検索できる(ストーリー)• 作者名で検索できる(ストーリー)• 一言コメントがかける(ストーリー)• etc...みたいな?
Epic in PivotalTracker
Epic in PivotalTracker• 複数のユーザーストーリーをまとめられる• ポイントのボリュームが相対的になんとなくわかる
• エピック名のラベルが自動的につく
• ストーリー<エピック
• リリース=ただのマイルストン。旗。
• エピック=人が入った時にあるとわかりやすそう。大きい単位で把握したい人のために。
コネクトスターのエピック
• 世の中はそれぞれ定義して使ってる、けど• コネスタでのどういう風に定義するかは、PivotalTrackerをちょっと運用してみて、今ある機能で足りないよねってなったら、決めてこう。
• まずは、エピックなしで、運用してみよう!
イテレーションについて
イテレーションとは• イテレーション=期間を固定したタイムボックス• イテレーション≠リリース• 1~2週間で固定しよう• コネスタでも運用はそれくらいにしてるね。今後、まとまった開発でも1~2週間の区切りを意識しよう。
• 基本単位は1週間で、ストーリーによっては1週間を2回使うというスタンスでいこう!
イテレーションのゴール
• お客さん(クライアント)に価値ある成果を届けること
•自社サービス開発では、誰に価値ある成果を届ければいいの?
誰に「価値ある成果」を届ければいいの?
• 自社サービスにクライアントがいない
• ユーザへ届けるのは「リリース」(リリース=価値あるストーリーのセット)
• 運用では、イテレーション=リリースになりがちだから、ユーザに価値届けている。
• 「価値ある成果」を届ける最小単位はチームメンバーで、その後ユーザだよね!
• クライアントワークだとお客さんと信頼築くのもある。私達はチームメンバーに成果を届けることを意識しよう。
イテレーションで肝に命じること
1. 文書は必要な分を必要なときに
2. コードはきちんと設計してしっかりテストしてばっちり結合した状態に。
3. テストは開発と一緒に。プロジェクト初日から、システムが全体として適切に動作し続けるようにしなくちゃいけない
テストについて• 単体テスト、結合テスト、受け入れテスト• プロトタイプは書かないという主義もあり• 書き方がわかってれば、書いたほうが結果手戻りないからいいかも
• テスト書くスキルも習得しよう• だから、やっていこう!!!
イテレーションのメリット
• プロジェクトの方向性の修正が容易•例えば• 優先順位がかわった• 予期せぬ自体が発生した
イテレーションの流れ
1.ストーリーを分析・設計
2.開発
3.テスト
必要な分を、必要な時に。作業を増やすのは必要になってから。
分析・設計
• 作業の段取りをつけよう• 実装中に次のストーリーの分析・設計しよう• 文書化はチームにとって適正なレベルで• Redmineのチケット→PivotalTrackrへ移行します• Wiki機能は、引き続きRedmineで。他にいい方法がないか探してみよう
システムの設計• エンジニアが一人でやってるけど。。。?• レビューはいいけど、皆でやると思想がばらついて非効率かも• 私達はRailsつかってるからある程度思想共有できてるという前提にある。
• ペアプログラミングで、思想をぶつけあうのはやるといいかも。• プランナーと仕様考える時に設計レベルで共有しながら進めるのはよさそう
• これで、どこが大変なのか伝わるし、リーンにできる部分を話し合える
開発
• 本格的なエンジニアリングのプロセスで•イテレーションが始まる前に、「イテレーションゼロ」をきっちりやろう(開発前のもろもろの準備)
イテレーションゼロ
•実はやらない人多いかも?• でも、そこではまると終わりになってしまう。イテレーションゼロ、意識的にきちんとやっていこう。
• Herokuはイテレーションゼロで必要な作業をやってくれるから、早く作るには便利
テスト• いつでもリリース可能な状態のために、ちょこちょこテストするけど、最後にもう一度
•お客さんが本気で確認するから•いつでもリリース可能を達成できるチームは少ないから
•テスト自動化しよう
KPT