It's in me and It's in YOU.

アジャイル/スクラム/データ分析とシナリオライティングや映画・本・ドラマの感想。つまりは雑記。

MENU

Product Owner(プロダクトオーナー）に関するメモ（２）

Agile Scrum

f:id:yugu9:20131205140213p:plain

プロダクトオーナーに関する勉強メモの続き

（１）はこちら

 

プロダクトオーナーがつくるプロダクトバックログについて

DEEP特性

・適切な詳細さ（detailed appropriately）

・見積もり（estimated）

・創発的（emergent）

・優先順位付け（prioritized）

プロダクトバックログの手入れ

・項目の発見と記述

要件を早い段階で確定するのではなく、プロジェクト全体を通して発見、記述していきます。荒いユーザーストーリーは「エピック」という。

・優先順位付け

優先順位付けはスクラムチーム全体で行うべきです。それは、チームの集合知の形成を促進し、積極的な参加を生み出します

 

個々のプロダクトバックログ項目は小さく、優先順位を付けることは難しいため、まずはテーマの優先順位を決定しておくと便利。次にテーマ内でもしくはテーマを横断して項目の優先順位を付けます。

 

優先順位の要因：価値（新しい要件だけを吟味しない。既存の要件も再検査する）、知識・不確実性・リスク（不明確なリスクがある項目を早急にとりかかるリスク駆動型のアプローチは早期に失敗します。早期に失敗すると、まだ変更の可能性があるうちにチームは報告転換できます）、リリースの実現可能性、依存関係

分割および洗練されたプロダクトバックログ項目

③に近づけていきましょう

サイズ
　↓

      

大きい

①大きくて荒い項目

    

小さい

②小さくて荒い項目

③明確でテスト可能で実現可能な項目

  
 

低い

高い

←詳細のレベル

 

ユーザーストーリーのINVEST

非依存（Independent）

交渉可能（Negotialbe）

価値があり（Valuable）

見積もり可能（Estimatable）

手頃な大きさ（Sized appropriately）

テスト可能（Testalbe）

 

よく書けているユーザーストーリーとは

①顧客にとって何かしらの価値が書かれていること

②エンドツーエンドになっていること

③ストーリーが独立していれば、必要に応じてスコープを柔軟に調整できる

 

④テストできるようになっている

Product Owner(プロダクトオーナー）に関するメモ（１）

Agile Scrum

f:id:yugu9:20131202234605j:plain

 

プロダクトオーナーに関する勉強メモ。このロールはしっかりとやったことがないので、まずは勉強です。来るかもしれない、その日のために（なんて）

 

プロダクトオーナー

プロダクトオーナーとして望ましい特性

  • 明確なビジョンを持った実行家

最終的な製品を心に描き、その明確なビジョンを伝えることができる人物です。同時に、プロダクトオーナーは完成に至るまでビジョンを見続けることできる実行家でもあります。

  • リーダーとチームプレイヤー

ビジョンを伝えるリーダーであり、スクラムチームメンバーと密に恊働できるチームプレイヤーである必要があります

良い製品を開発するためには、適切な意思決定の権限を与えられたプロダクトオーナーが不可欠です。

チームとの恊働

プロダクトオーナーが少なくても毎日１時間、チームとチームルームで一緒に過ごすべきとうルールも提案されている。

スクラムマスターはHow、プロダクトオーナーはWhatの責任を持つ

[NG]集

  • スクラムマスターとプロダクトオーナーの兼務は絶対にやめてください（たいていの場合は利益相反なロール）
  • 働きすぎるプロダクトオーナはボトルネックになる

チーフプロダクトオーナー

大規模なスクラムプロジェクトでは必要。経験から、プロダクトオーナーは通常３つ以上のチームを掛け持ってはいけないことが示唆されています。

階層化されたプロダクトオーナーは自分より下のレベルで行われている仕事の計画、構成、割当て、計測を行います。

※この構成、計測、大切だけどなかなか難しいよね。そのHowはScrumマスターも一緒に考えてあげるべきなのか。うむむ。

プロダクトオーナーがすべきこと、すべきでないこと

すべきこと             すべきでないこと
「何」をすべきかを明確に説明する 「方法」や「期間」を指定する
チームと挑戦する チームをいじめる
ハイパフォーマンスなチームの構築に貢献する 短期的なことにのみ注目する
実際の事業価値で思考を駆動する 当初のスコープとアプローチに個室する
外部の雑音からチームを保護する 実際に問題が発生するまで、闇雲に変更してチームを悩ませる
スプリントの間に組織を改善する スプリント中にタスクの追加や変更を強制する

 

 

 

 

　いってきたよ⇒リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜

Agile KANBAN

f:id:yugu9:20131128192638j:plain

 

http://leanfromthetrenches.doorkeeper.jp/events/7026?utm_campaign=event_7026&utm_medium=email&utm_source=registered_message_4243

行ってきました。もともと本書（リーン開発の現場 カンバンによる大規模プロジェクトの運営）を読んでいた際に、たまたまイベントの存在を知った感じです。

No timeで登録申し込みするよね。そりゃーもう。

 

感想とか

平鍋さんの話しが面白すぎた。なんというか染みる。理論や知識だけの話しではなく、そこに「現場」のリアリティがあるからだろうか。やる気でた。

f:id:yugu9:20131128195410j:plain

そして、絶対解のない現場でどう戦うか、楽しむかのヒントたくさんのイベントでした。

メモメモ

チームで計って、チームで改善する。上から言われてやるんじゃない

うぉー、確かに。最近、チームの状況がわかるＫＰＩを求められているけど、そうなんだよね。そう。チームで計ることが大切。

リトルの法則

WIP(中間在庫）＝Lead Time(できまでの時間）×Throughput(生産性）

Lead Timeが大きくなると、Throughputは下がる

当たり前だけど式にすると腹落ちする。トレードオフの話しでもありますね。

Stop Starting, Start Finishing

まず終わらす。これは忘れてはダメですね。忘れないためのＷＩＰ制限。

実際に導入してみようと思うIdea メモ

・横槍の見える化

緊急のタスクなどは付箋の色を変えたりして、わかりやすくしておき、その数や従来のやるべきこととの比率とかだすといい。

・もっと「人」を中心に考える

人のもつ工夫のモチベーションを活かす。一人ひとりを育てる。「人」の要素がプロセスの中心である

 

 

TQM品質管理入門から学ぶ「品質を改善していくための５つのポイント」

読書

 

TQM 品質管理入門 (日経文庫)

TQM 品質管理入門 (日経文庫)

 

 TQM(Total QualityManagement：総合的品質管理）とは？

トップのリーダーシップのもとに組織が一丸となって、顧客が高度に満足する製品を生産したり、サービスをを提供するための一連の活動です。 

 組織として品質管理をマネジメントしていく上のでポイントをまとめます。

１．当たり前品質を確保することを再認識する

当たり前品質をしっかり確保したうえで、魅力的な品質・質を付加する 

組織によっては「当たり前品質」とはどこまでかを定義する必要もあるでしょうが、まずは最低限のゴールを定義することで出発できます。 

 

２．問題があった場合は「応急」と「再発防止」の２つの策を考える

問題に対して対策をとる場合には、直面している問題そのものを解決するための「応急対策」と、類似の問題が二度と発生しないようにするための「再発防止策の二つの側面から対策をとることが必要です

まずは目の前の火を消す。そのあとに、二度と火があがらないようにはどうすればよいのか考えるようなプロセスにすること。これが改善していくプロセスです。多くの組織は「応急対策」を繰り返しています。どうして改善しないのか？と問えば、「応急対策をしなきゃいけないから再発防止策を考える時間がないんだ」と答えが返ってくる感じでしょうか。「応急対策をしている時間はあるんでしょ？」

 

３．データで語る

「データで語る」ことは創造の第一歩 

データをもとにした対策は結果もデータで確認することができる。データで語るからこそPDCA(Plan,Do,Check,Act)のプロセスを自信もってまわあせるようになる。

 

４．教育・訓練を継続する

よい風土を維持するには？

一度作り上げたよい風土と文化を維持することが重要です。これには、継続的な教育以外に策はありません。スポーツにおいて、基礎体力を維持するには基礎体力のトレーニングを継続的に実践しなければいけないのと同じ理屈です

 

５．プロセスとツール


プロセスの標準化が必要なのは、製品・サービスの品質・質を安定化させるためです。

 

QC７つ道具が定量的なデータを取り扱うのに対し、定性的なデータについては新QC７つ道具が役立つ

 

改善のステップ

  1. 背景、投入資源、日程、あるべき姿等を整理する（背景の整理）
  2. 現状を徹底的に調べる（現状の分析）
  3. 問題の要因を探索する（要因の探索）
  4. 要因の探索結果に基づいて対策を立案する（対策の立案）
  5. 対策の効果を検証する（効果の検証）
  6. 効果がある対策を現場に導入する（導入と管理）

 

Jenkinsからpull requestをつくる方法のメモ

Jenkins

状況

プロジェクト全体の開発ブランチがあって、そこからチームブランチをきってさらにチームブランチから個人ブランチをみんながきって作業しています。

コーディングが終わると個人ブランチがチームブランチにマージされ、チームブランチが開発ブランチにマージされるような流れで作業しています。

問題

最近実施した際に、チームブランチを開発ブランチにマージするときにけっこうなConflictが発生してしまいました。

原因はこまめに最新版を取り込んでなかったから。（他のチームと同じところをいろいろいじっているのもうんぬん）

振返り

その振返りから、毎日、開発ブランチをチームブランチにマージしようという流れになりました。

で、毎日やるんだったら、楽にしたいよね。

じゃー、pull requestぐらい自動でつくって、朝のスタンドアップミーティングの終わりにでも問題なかったらマージする運用にしようといことになりました。

自動化する

前提

・Code管理にAttlassian Stashを利用

前準備

・Stash CLIをJenkins Serverに導入

Jenkinsジョブ

# Jenkisn Job
git clone https://hogehoge.com/scm/hoge/hogehoge.git
FEATURE_BRANCH="feature_Branch" TEAM_BRANCH="Team Branch"
stash pull-request ${FEATURE_BRANCH} ${TEAM_BRANCH} @Reviewer

 

　KANBANに関するメモ

Agile KANBAN

KANBANにについて

  • 作業の流れを見える化すること（作業を分割してカードにして壁に張る、枠に名前をつけてそれぞれの状態を見える化すること）
  • WIP（work in progress)を制限（各ワークフローにおいて進行中にできる作業の数を明確に制限）
  • リードタイム（ひとつのToDoを完了するまでの平均時間。時々、サイクルタイムとも呼ばれる）を測る
  • 「かんばんが少なくても決めていることは、ワークフローは見えているべきで、WIPは制限されるべきだということだ」
  • かんばん　は役割については規定していない（スクラムよりも規定が少ない・・）
  • スクラムはタイムボックス型のイテレーションを基盤にする
  • KANBANは「累積フロー図」を使ったりする 

何で制限したいのか？

  • スクラムのWIP はある期間内に制限される。
  • KANBANのWIP は仕事の状態により制限される。
  • →予測ができるリードタイムがあれば私たちはSLA(service-level agreements:サービス内容合意書)への合意や現実的なリリース計画を作成できる。

どちらも経験に基づく
→だから、試そう

スクラムは優先順位付けされたバックログを規定

  • KANBANボードの左端の列は、スクラムのプロダクトバックログと同じ目的でいつも埋まっている。
  • 優先順位付けされた一覧であろうとなかろうと、チームが最初にやるタスクはなんらかのルールが決められていることが必要だ

スクラムボード vs KANBAN

Scrum
KANBAN
タイムボックス型のイテレーションを規定 タイムボックス型のイテレーションはオプション.
計画のためのケイデンスとリリースプロセス改善を分ける事ができる。 タイムボックスではなくイベントドリブンも可
チームは 特定の期間をイテレーションとして、やることをコミットする。 コミットメントはオプション。
ベロシティを計画やプロセス改善のための標準の指標として使う。 リードタイムを計画やプロセス改善のための標準の指標として使う。
クロスファンクショナルチームを規定 クロスファンクショナルチームはオプション。専門家チームでもいい。
タスクは分割されていなければならない。
1 スプリントで完了できる大きさでなければならない。		 特定のサイズが規定されているわけではない。
バーンダウンチャートを規定 特定の図が規定されているわけではない。
WIP の制限が間接的 (スプリントに対して) WIP の制限が直接的(ワークフローに対して)
見積もりを規定 
実施中のイテレーションにタスクは追加できない		 見積もりはオプション
余裕があれば新しいアイテムを追加できる
スプリントバックログは特定のチームが所有 かんばんボードは複数のチー ムや個人で共有できる
3 つのロールの規定(PO/SM/Team) ロールは規定されていない
スプリントごとにスクラムボードはリセットされる かんばんボードは永続的
優先度付けされたプロダクトバックログを規定 優先度はオプション


KANBANその他メモ

  • １時間以上のタスクのみボードにのせる（それ以下のものはホワイトノイズとした）
  • KANBANの成果の多くは、直観に反していました。WIP （Work-in-progress:進行中（を制限して、作業を引っ張るようなとても機械的なアプローチに見えたことが、実際のところ、人々やどのようにお互いに反?して協力するかということに深く影響を与えています。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

読書 チームビルディング アジャイル

 

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 

 チームで働くために必要なこと。エンジニアとして生きていく上で大切なこと。

そんなことがたくさん詰まった本でした。良書！

  • チームとして信頼しあう関係であるためには、たまには同じを空気を吸う時間と場所を共有することが必要である（前書き）
  • 隠したらダメになる（一章）
  • 過ちから学ぶには失敗を文章化することである（一章）
  • チームの文化、強固な文化をつくると自己選択的になる（２章）
  • ミッションステートメント（いや、マジで）（２章）
  • ミーティングについて。新しいものを設計するのであれば５人以上はいらない（２章）
  • サーバントリーダーとして謙虚、尊敬、信頼<HRT>の雰囲気を作り出さなければならない（３章）
  • リーダーのアンチパターン（３章）
  1. 自分の言いなりになる人を採用する
  2. パフォーマンスの低い人を無視する（成長させるor退席させる）
  3. 人間の問題を無視する
  4. みんなの友達になる
  5. 採用を妥協する
  6. チームを子供として扱う
  • リーダーシップパターン（３章）
  1. エゴをなくす
  2. 禅マスターになる（相談があったとき解決するのではなく手伝ってあげる）
  3. 触媒になる（適切な人を知る）
  4. 先生やメンターになる
  5. 目標を明確にする
  6. 正直になる
  7. 幸せを追い求める
  8. チームのいいところをフィードバックする
  • 短期的なマリットのために文化を妥協する必要はない（３章）
  • 有害な人、その古典的なパターン（４章）
  1. 他人の時間を尊重しない人
  2. エゴ・・合意の決定を受け入れない人、妥協できない人
  3. 権利を与えすぎる（トロルになる）
  4. パラノイア（被害妄想）
  5. 完璧主義→停滞する。コーディングを開始できなくてイライラする
  • 自発的だけど退屈（マンネリ）なメンバーにはモチベーションが必要
  • ユーザーも人間。ユーザーではなく利用を計測する（６章）