2018-01-01から1年間の記事一覧
はじめに c5meru.hatenablog.jp 自分もチームリーダー→プロジェクトリーダー→プロジェクトマネージャーと役割が変わっていった時に、同じようなことを考えたことがあったなと思い出しました。 私の場合 マネージャーはチーム・組織を開発するのが仕事 海外子…
概要 「私たちは毎スプリント、スクラムマスターをローテーションします(“We rotate the Scrum Master role every Sprint” – Serious Scrum – Medium)」という記事の中にある「スクラム秘書(Scrum Secretary)」という表現が面白かったので、悪いスクラムマス…
解説 プロダクトオーナーはプロダクトバックログアイテムに優先順位を定める時、様々な事項を考慮する必要がある。 新機能の追加、技術負債の解消、アーキテクチャ・技術基盤の見直しなど。 無意識のうちに特定の領域を優先してしまうことがないよう、「過去…
はじめに 国内の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つの製品を…
概要 「定期的」に「上司と部下の間」で行う1対1の対話。 対話を通じて部下の行動や経験学習を深めることを目的としている。 詳細 1on1とは 「定期的」に「上司と部下の間」で行う1対1の対話。 「具体的な経験」を思い出し、「内省」し、「教訓を引き出し」…
概要 複数チームで1つのプロダクトを開発する場合、開発対象であるコンポーネントでチームを分けるのではなく、各チームが複数コンポーネントを扱うことができ、単独で価値を提供できるフィーチャーチームを組ませる方が良い。 フィーチャーチームがうまく機…
はじめに スクラム導入の成功事例は近年よく目にするようになり、最近ではLeSS導入の事例も増えてきました。 でもLeSS導入の難しさを紹介した事例はこれまで見かけたことがなかったので、自分がプロダクトオーナー/スクラムマスター/アジャイルコーチの立場…
概要 youtu.be 「UIが無い」などスプリントレビューの参加者にスプリントの成果が見せにくいときのやり方。 成果が「あるとき」と「ないとき」を明確にすることで、何が変わってどのくらい価値が生まれたのかわかりやすくする。 ネタ元 t-and-p.hatenablog.c…
概要 適切なプロダクトオーナーを見つけることはアジャイル開発の成功のために欠かせない。 自分たちの開発形態を踏まえ、正しいプロダクトオーナーを探す努力を続けること。 詳細 3つの開発形態とプロダクトオーナーがどこにいるか プロダクト開発(Product …
概要 開発者が他のチームへ移動、または複数のチームを渡り歩き、スプリントでの困りごとを解決したり、特定の技術や知識についてチームに伝える役割を果たす。 LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。 詳細 アジャイル開発では頻…
概要 複数チームで開発を行なっていると他のチームが何しているのかわからなくなることが多い。 そこで偵察員(スカウト)を送り、情報を集めチーム間で必要な情報が共有されるようにする。 LeSS (Large Scale Scrum)の知識伝搬のためのプラクティスの一つ。 …
はじめに 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)に直接コミットをし、ブランチを切らずに開発を行う。 ブランチを切るという誘惑に打ち勝ち、長い間最新版と離れることで発生するマージに時間がかかる問題や、コードの衝突問題が発生しないようにする。 …
解説 スプリントレビューに招待された人がフムフム聞いてうなづくだけだったり、大人数で質問が活発が出ないときにあらかじめ汎用的に質問を考えておき見えるところに掲示しておく。レビュー後のディスカッションが盛り上がらなかった時にそれを持ち出して話…
概要 LEGOのデジタルソリューション部門における複数のスクラムチームの方向性を揃えるための2日間のイベント開催事例の紹介。 ネタ元はPlanning as a Social Event - Scaling Agile@LEGO。 詳細 2014年のLEGOでは会社トップの施策として年単位の計画や予算…
オープンスペースとは 手軽な準備でディスカッションを開催することができるワークショップ。オープンスペーステクノロジーと呼ばれることもある。 参加者がトピックを提案し、ディスカッションが必要な課題を話し合う。参加者の当事者意識・主体性を引きだ…
模造紙の貼り方 対角線の上をなぞるように貼るとたわまないようになる。 ワークショップにおけるコツの研究(9)模造紙の貼り方 | 経験デザイン研究所 付箋 強粘着を買う 貼って・剥がしてを繰り返していると粘着力が落ちてくるので3Mの強粘着ポストイット一…
概要 JIRAとかRedmineとかVersionOneとかXXXとか。 プロダクトバックログはまだ良しとして、スプリントバックログは絶対に避けること。 拠点分散されていませんか ツールを強制されていませんか PCを向いて話すことになり、ミーティングでの雰囲気が悪くなり…
解説 複数人でプログラムを書いていると実装スキルの差やドメイン知識の差からコード品質にばらつきができてきます。 中・長期で安定した成果を産んでいくにはこまめなリファクタリングが必要ですが、「リファクタリングをこまめにやろう」と呼びかけると終…
概要 複数チームでスプリントレビューを開催する際の解決策の1つ。 プロダクトオーナー、ステークホルダーを会議室に集め、チーム代表者が代わる代わるスプリント成果のデモを行う。この様子をテレビ会議システムなどを使って配信し、開発メンバはそれを視聴…
概要 複数チームでスクラム開発をするときのレビューのやり方の一つ。 プロダクトオーナー、ステークホルダー、開発メンバが参加し、各ブースに自由に立ち寄ってスプリントの成果を確認し、ディスカッションを行う。 コツ 時間を区切り、ブースの説明員を変…