tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

最低なスクラムマスターの言動集

www.youtube.com スクラムマスターとして不適切な言動をテンポよくまとめた動画です。 それはこのスクラムイベントで話すことではない。 今日の振り返りでは開発を改善する10のアイデアを話したいんだ もっとアウトプット増やしたいからたくさんのことに着手…

(スクラム)チームに人を連れてくる

ひとさらいしたい! はじめに Regional Scrum Gathering Tokyo 2019のOpen Space Technologyで「隣の部署から借りているあの人を3ヶ月でもらう方法」というお題が出て参加してきました。 「ひとさらいしたい!」の文字が印象的ですが、本当にさらったことが…

Regional Scrum Gathering Tokyo 2019に参加しました

RGST2019参加証 はじめに 2019.scrumgatheringtokyo.org 初参加です。参加者同士の交流色が強い、活気あるイベントでした。 聞いてきた話と個人的なメモ Outcome Delivery: delivering what matters コーヒーの絵 「最高のコーヒー」と聞かれると豆や入れ方…

アジャイルプラクティスを整理する : Agile Landscape v3とOpen Practice Library

はじめに Regional Scrum Gathering® Tokyo 2019に参加してきました。 初日の基調講演を行なったGabrielle Benefieldさんのスライドで紹介されていた「アジャイル開発に関するプラクティスは多すぎる」という意味合いで引用されていたAgile Landscape v3と、…

プロダクトバックログリファインメントに関する10の改善案(10 Experiments With Product Backlog Refinement)

はじめに medium.com 昨年公開されたブログ記事で、プロダクトバックログリファインメントをより良くするために行なった10の施策が面白かったので紹介します。 「10の改善案」とありますが、続きものもあるのでアイデアとしてはもう少し少ないです。 10の改…

CourseraはいかにしてGoogleやFacebookに対抗して才能ある人材を採用しているか

firstround.com John Ciancutti氏による最高の人材を採用するやり方を紹介した記事の私的まとめです。 はじめに:採用活動の"おわり"を意識する 採用活動の最初期から候補者とのやり取りの間中ずっと、採用活動の”おわり”を常に意識して動く。 候補者もまた…

エンジニアリング組織論への招待 の私的まとめ

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング作者:広木 大地技術評論社Amazon 昨年読み「経験から感じていたことが、言語化されてまとまっている素晴らしい書籍だ!」と感じました。 が、「具体的に何を学んだか?」と…

報告のやり方を揃える

概要 アジャイル開発・スクラムで開発スケジュールの確認、進捗を測る方法としてはバックログ・バーンダウン(アップ)チャート・ベロシティ・スプリントレビューと様々なやり方が存在する。しかし旧来組織の中で一部チームだけがアジャイル開発に取り組んでい…

Re: エンジニアリングマネージャーでいるのがつらくなったときは

はじめに c5meru.hatenablog.jp 自分もチームリーダー→プロジェクトリーダー→プロジェクトマネージャーと役割が変わっていった時に、同じようなことを考えたことがあったなと思い出しました。 私の場合 マネージャーはチーム・組織を開発するのが仕事 海外子…

あなたのチームのスクラムマスター、「スクラム秘書」になっていませんか?

概要 「私たちは毎スプリント、スクラムマスターをローテーションします(“We rotate the Scrum Master role every Sprint” – Serious Scrum – Medium)」という記事の中にある「スクラム秘書(Scrum Secretary)」という表現が面白かったので、悪いスクラムマス…

バックログアイテムを4象限に分類する

解説 プロダクトオーナーはプロダクトバックログアイテムに優先順位を定める時、様々な事項を考慮する必要がある。 新機能の追加、技術負債の解消、アーキテクチャ・技術基盤の見直しなど。 無意識のうちに特定の領域を優先してしまうことがないよう、「過去…

Re: FOLIO を支えるエンジニアリング組織の七転八倒記: 2018年冬

はじめに 国内のLeSS事例をまとめている際に見つけた大規模スクラムにおけるプロダクトの定義 - TechとPoemeの間の筆者さんがFOLIOのアドベントカレンダーで、会社の開発体制・組織構造の変遷について下記の記事を公開されていました。 t-and-p.hatenablog.c…

スクラム開発を取り入れるためにパイロットプロジェクトを作るべきか

概要 結論から言うと「無い」。 開発・組織・社内全体をアジャイル開発・スクラム開発に切り替えるためであっても、複数のプロダクトを、複数のチームで別個に開発する限りは一気に取り入れた方が良い。 詳細 パイロットプロジェクトの目的 weblioの説明が短…

機械学習を含む開発をアジャイルに取り組む

機械学習のイメージ 概要 機械学習・ディープラーニングなどアルゴリズム検討を含めてうまくアジャイル開発を回すやり方を考えたい。 Spotifyで機械学習に取り組むDavid Murgatroyd氏がSlideshareに公開している資料をベースとしている。 Agile Deep Learnin…

「プロダクトオーナーの役割に関する誤解」が組織に与える害について、また避けるために何をすべきか。

www.youtube.com 概要 YouTubeにアップロードされている"How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It"の意訳。 詳細 「プロダクトオーナーの役割」はどう開発に作用するか 小さなチームで1つの製品を…

1on1

概要 「定期的」に「上司と部下の間」で行う1対1の対話。 対話を通じて部下の行動や経験学習を深めることを目的としている。 詳細 1on1とは 「定期的」に「上司と部下の間」で行う1対1の対話。 「具体的な経験」を思い出し、「内省」し、「教訓を引き出し」…

スキルマップ

概要 複数チームで1つのプロダクトを開発する場合、開発対象であるコンポーネントでチームを分けるのではなく、各チームが複数コンポーネントを扱うことができ、単独で価値を提供できるフィーチャーチームを組ませる方が良い。 フィーチャーチームがうまく機…

Re: スクラムを大人数で運用したところ💩な結果になった。

はじめに スクラム導入の成功事例は近年よく目にするようになり、最近ではLeSS導入の事例も増えてきました。 でもLeSS導入の難しさを紹介した事例はこれまで見かけたことがなかったので、自分がプロダクトオーナー/スクラムマスター/アジャイルコーチの立場…

スプリントレビューでデモしにくい時 → 551メソッド

概要 youtu.be 「UIが無い」などスプリントレビューの参加者にスプリントの成果が見せにくいときのやり方。 成果が「あるとき」と「ないとき」を明確にすることで、何が変わってどのくらい価値が生まれたのかわかりやすくする。 ネタ元 t-and-p.hatenablog.c…

プロダクトオーナーはどこにいる?

概要 適切なプロダクトオーナーを見つけることはアジャイル開発の成功のために欠かせない。 自分たちの開発形態を踏まえ、正しいプロダクトオーナーを探す努力を続けること。 詳細 3つの開発形態とプロダクトオーナーがどこにいるか プロダクト開発(Product …

トラベラー

概要 開発者が他のチームへ移動、または複数のチームを渡り歩き、スプリントでの困りごとを解決したり、特定の技術や知識についてチームに伝える役割を果たす。 LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。 詳細 アジャイル開発では頻…

スカウト

概要 複数チームで開発を行なっていると他のチームが何しているのかわからなくなることが多い。 そこで偵察員(スカウト)を送り、情報を集めチーム間で必要な情報が共有されるようにする。 LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。 …

LeSS Conference 2018 New Yorkの発表資料

はじめに 9月にNYで行われたLeSS(Large Scale Scrum)のカンファレンス資料がどこかで見れないか、SlideshareやSpeakerDeckをずっと探していたけど、公式サイトで公開されていた。 LeSS Conference 2018 New York - Large Scale Scrum (LeSS) 左のサイドバー…

バックログアイテムの分割

概要 チームのアウトプットを安定させるには、取り組むバックログアイテムが適度な大きさになっていることが望ましい。しかし新機能の実装など長い時間・大きな工数を要する開発項目が出てくることは避けられず、分割して複数スプリントにまたがって開発を行…

テスト自動化のバックログを作る

概要 通常のバックログにテスト拡充を含めると優先順位付で新機能追加に負けてしまいがちである。そこでバックログそのものをわけ、並び替えの基準も「手動テストの工数を踏まえて自動化した時のメリットが大きいもの」を優先すると良い。 詳細 「塹壕より S…

チーム名をつける

概要 開発対象でチームを呼んでいると、チーム名に仕事が引っ張られるようになる。 詳細 機能・コンポーネント・ライブラリ名をチーム名としていると、開発対象が変化・拡大した時に混乱が生じます。 酷い場合はチーム名から類推される仕事をマネージャーが…

バグを毎日配る

概要 スクラムでスプリント区切りの開発をしているとスプリント期間中に見つかったバグの扱いに悩むことになる。 スプリント期間内で直す、プロダクトバックログにバグ修正をストーリーとして積み直すことが定石だが、各チームにあらかじめ割り振るという手…

コンポーネントコミュニティー & コンポーネントメンター

概要 複数チームで1つのプロダクトを開発していると、あるコンポーネントが特定の所有者を持たないことになる。 「事前に設計をやりすぎない」というアジャイル開発の進め方と合わさるとコンポーネントの設計がぐちゃぐちゃになる。 開発チームをフィーチャ…

複数チームでのスプリント計画

概要 LeSS(Large Scale Scrum)で行う、複数チームで1つのバックログに基づいてスプリント計画を立てる時のやり方。 詳細 第1部 プロダクトオーナー、チームの代表者1〜2名(スクラムマスターでなくてもよい)が参加し、どのチームが何のストーリーを担当するの…

ワントランク開発 / トランクベース開発

概要 開発者が1つだけ存在する最新版(trunk/master)に直接コミットをし、ブランチを切らずに開発を行う。 ブランチを切るという誘惑に打ち勝ち、長い間最新版と離れることで発生するマージに時間がかかる問題や、コードの衝突問題が発生しないようにする。 …