アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
ヤフーのスクラム開発実践者の経験年数ごとの学習方法の紹介
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ アジャイルコーチの荒瀬です。 ヤフー、および関連会社のアジャイル開発支援や研修を担当しています。 今回はヤフーのスクラム実践者の学習方法についてお話しします。 イベントや研修の中で、スクラムの勉強方法をいろいろな方から質問されることが多かったので、記事にするとより多くの人の役に立つのではないかと思い執筆することにしました。 また、せっかく書くのであれば、ヤフーの中にいるさまざまなスクラム実践者の話も交えると、経験年数別に、より参考になりそうな書籍、セミナーや研修を紹介できるのではないかと考え、ヤフーのスクラム経験者にも協力いただいています。 スクラムを始めた頃の自身のことを考えながら、こういう記事があるといいのにと思
前職のスクラムが神がかっていたので忘れないうちにまとめる｜Yuito Sato
どんなエントリ？コニチハ、経営管理クラウド ログラスのエンジニアの佐藤です。 前職（ビズリーチ）チームのスクラムが社内でもトップクラスの完成度だったので忘れないようにまとめようと思います（事実上の退職エントリ）。 スクラムの知識を前提としてスクラムイベントで気をつけていたことを順番に書いていきます。 注意: ここで書かれていることはあくまで前職のチームでは、ということなので、公式のスクラムガイドで明確に定義されていることから逸脱している可能性があります。 リファインメントリファインメントは1週間スプリントに対して週2時間固定で行います。POとステークホルダーであるデザイナーとチームメンバーが参加します。 リファインメントのゴールは以下の3つでした。 1. PBI（チケット）の受入基準を明確化する 2. ストーリーポイントを見積もる 3. 3pt以上のPBIを可能な限り分割する リファインメ
複数のスクラムチームをまわすときのアンチパターン - OPTiM TECH BLOG
こんにちはOptimal Bizチームの伊藤です。 直近のプロダクトで開発メンバー約20名を3つのスクラムチームに分け、同時に回すことでプロダクトを開発しています。 複数チームのスクラムにはLeSSやNexusなどのフレームワークがありますが、私たちのチームはそのようなノウハウもないまま「短い期間にどんどん人数が増えていく」というプロセスをたどりました。 このときにぶつかった問題やその対処方法をいくつか紹介したいと思います！ 1. 複数のスクラムイベントに参加しなければならない人がでてくる 複数のチームのイベントに参加してしまう人がいると各チームのベロシティやリズムが崩れてしまいがちです。 しかし、私達のチームでは職能・スキルの関係でどうしても複数のスクラムチームにまたがっている人が存在してしまいました。 (実際にそういった現場も多いのではと思っています。) 対処: 所属を明確にし、スプリ
MBWA(Management By Walking Around)歩きまわることによるマネジメントとウロウロスクラムマスター - Training for D-Day
MBWA(Management By Walking Around)とは、歩きまわるマネジメント、簡単に言うと、「マネージャーが現場をウロウロする」ということです。 これは非常に理にかなっています。 なぜなら、現場のことは現場が一番知っているからです。席に座って報告を待っているだけのマネージャーはダメで、自ら情報を取りに行く(pull)必要があります。 MBWAはそのことを端的にあらわしていると思います。 優れた成果を出すためには、最高のチームが必要です。最高のチームは、人間関係が良好で最高のコミュニケーションが取れます。 それには対話を通じたマネジメントが必要です。文書（電子メールも含む）より、対話をより重視しないといけません。 現場を歩きまわり、メンバーと対話をし、状況を確認するのです。メンバーとの関係が非常に蜜になります。メンバーはマネージャーが気にかけてくれていると安心します。 報
スケールする大規模スクラム開発「LeSS」の実践例＠Timers - Tech Blog
はじめに CTOのあまど ( @amado_tech )です。 Timersでは2013年頃から長らくスクラム開発を中心に据えてプロダクトを作ってきました。初期の頃はなんちゃってスクラムだったり、人が増えるにあたって自己組織化するのが難しくなったり、たくさんの課題や問題を乗り越えてきました。 現在16名程度のアプリ開発チームが2つのスクラムチームと1人のプロダクトオーナーの体制で、2週間のスプリントを効果的に回しながら生産性高く＆納得度高くプロダクト改善が出来ており、我々のコアプロダクトである「家族アプリFamm」は順調に改善され事業成長もしています。 そんな開発体制を支えているのが、「LeSS(Large Scale Scrum)」という大規模スクラムのフレームワークです。本記事ではLeSSの紹介と実践する上でのノウハウを共有します。 LeSS(Large Scale Scrum)とは
旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。 20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。 最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。 最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。 この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。 アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが ・最近アジャイル？流行ってるんでしょ ・無限に要件変更できるんでしょ ・アジャイルにすると早く安くできるんでしょ などと仰せになった結果だと聞
仕事納めとスクラムの話 - imog
今日で仕事が納まった。それと同時にチームメンバーが一人チームを去ることになった。送別会もしたのでお別れはまあそれなりにしたんだけど、結構自分に影響を与えたのでなんとなくブログとして残しておくことにした。 うちの部署は複数のスクラムチームで構成されているスクラムオブスクラムという形を取っている。僕がこのチームに配属されたのは二ヶ月前くらいのことだ。部署内の別のチームからこのチームに異動したのがきっかけだ。チームメンバーの一人であり、今回お別れした人は認定スクラムマスターを持つエンジニアであり、このチームはちゃんとアジャイルなチームになろうとしているという話を事前に聞いていた。(以降、この人を彼と呼ぶ) 前職でもスクラム開発はやっていたつもりだったし、以前のチームでもスクラムを行なっていたのでなるほどなるほどという感じでチームのやり方に乗っかっていくことにした。見積もりをして、計画で洗い出し、
開発チームで実運用しているスクラムを画像いっぱいでまとめてみた - SMARTCAMP Engineer Blog
スマートキャンプの郷田です。 私はBiscuet（ビスケット）という新規SaaSのプロダクトマネージャーをしております。 Biscuetでは開発プロセスに課題を感じていたため、外部からアジャイルコーチの天野さんをアドバイザーとして召喚し、スクラムの導入を進めています。 そこで今回は、Biscuetチームで先月から導入を進めているスクラムの現状を、たくさんの画像を用いてまとめてみたいと思います！ スクラムの役割 開発チーム プロダクトオーナーチーム スクラムマスター スクラム全体像 スクラムのセレモニー PBL（Product Backlog） SBL（Sprint Backlog） 朝会（Daily Scrum） モブプロスペース KPT（Sprint Retrospective） その他 最後に スクラムの役割 開発チーム 開発チームはエンジニアの3人が中心となって開発を進めています。
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
スクラムの理解を深める「スクラムショーワークショップ」のご紹介 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? スクラムショーワークショップとは yycr2019(アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート)で生まれた、スクラムを短い時間で理解するためのワークショップの紹介です。 発起人は森一樹(@viva_tweet_x)と吉羽龍太郎(@ryuzee)です。 スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。 内容はご自由に使っていただいて構いませんが、利用する場合はクレジットをどこかにご明記ください。また、SNS等で利用した旨を共有いただけますと、ワークショップの作成者
デベロッパーとして生きていく ー 認定スクラムデベロッパー になりました！ - ikuo’s blog
先日、 David Bernstein 氏の 認定スクラムデベロッパー研修に参加し、Certified Scrum Developer（CSD）を取得しました。 www.jp.agilergo.com ５日間に渡る研修で、たくさんのことを学びました！ TL;DR これでした！ 今まで学んできたことが１つのストーリーのもとつながり、明確な目的を得ることができました。 何より、デベロッパーとして生きていく自信と勇気を、その方法と一緒にもらったように感じています！ お急ぎでない方向け：詳細 Agile, Scrum, XP 価値、原則、プラクティスのフラクタル構造 XPにおいて、価値、原則、プラクティスは以下のように説明されます。 価値（values）：達人が良し悪しを判断する高度な感覚。ある状況における好き嫌いの根源にあるもの プラクティス（practice）：疑う余地のない、簡単に実施できる
認定スクラム開発者研修(CSD)にいってきました｜seya
認定スクラム開発者研修(CSD)なるものにいってきました。名前の通りスクラムが関わるのですが、スクラム自体の知識の研修はほぼなく、実際に本当の意味でのスクラムを体験してみようというのが本研修の内容です。 なので実際に講師の方々がPO役やスクラムマスター役を担い、プランニングからレトロスペクティブまでを行います。また、内容はスクラムだけではなく、スクラムと親和性の高い開発手法 ATDD, TDD, masterブランチ一本開発などについても体験できるようになっています。 この記事ではそんなCSD研修についての振り返りを書いていきます。 ちなみに研修のページはこちら。(回し者ではございません) https://www.odd-e.jp/ja/service_01/index.html 想定読者- 未来の俺。 最初は「CSD研修の内容が気になる方」というターゲット設定で書き始めてみたところまとま
組織の拡大に伴うアジャイルなプロダクト組織構築 - KAKKA is not 閣下
Drivemodeというスタートアップにジョインしてから4年が経ちました。ジョインした（入社すると決めた）当時はまだシードラウンド以前であり、ファウンダー4人+エンジニア2人という状態でした。ですが今となっては組織も数十人規模まで大きくなってきています。 組織が大きくなるにつれ、様々な組織やマネジメントの問題に遭遇するようになり、今後もこれらと真剣に向き合わないといけません。 本記事では、これまでの経験を踏まえて、組織の成長に伴ってどのようなアプローチで組織や文化を構築すれば良いか、考えをまとめて書きます。 常に管理されたプロダクトバックログの重要性 いきなりですが、まずプロダクトバックログの話をします。 常に管理されているプロダクトバックログというものは非常に大切です。プロダクトバックログとは目的地に向かうための道筋であり、そこが空になっていたり、でたらめな状態だと、車（プロダクト）は暴
誰がプロダクトオーナーをやるとよいのか？
みなさんこんにちは。@ryuzeeです。 最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。 プロダクトオーナーとは？まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド（2017）で確認しましょう。 5ページ：プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映する
不安ゾーンにいた開発チームがラーニングゾーンに入るまで - ねこのひたい
はじめに こんにちは。@oturu333 です。私はフリーランスエンジニアとしてモチベーションクラウドの開発チームに参画しています。 もともとEMをやっていたので、参画当初よりEM業務（組織やプロセスの改善など）に携わらせていただき、現在は複数ある開発チームの1つのPO業務も経験させていただいています。 今回はそのチームが2ヶ月で「不安ゾーン」を抜け「ラーニングゾーン」に入っていったお話をしたいと思います。 最初「自分たちは何でも屋なんで」と言っていたhotfixチームが、スクラムを取り入れ「もっとベロシティを上げられないか」「仕事を楽しめている」と言えるチームになるまでを語ります。 「不安ゾーン」「ラーニングゾーン」については、以下のブログが参考になります。 note.mu 「hotfixチーム」と言われたチーム モチベーションクラウドには複数の開発チームがあり、それぞれのチームに名前を
割り込みにどう対処するか - kawaguti’s diary
アジャイルコーチとして社内でスクラムを始める人のサポートをちょくちょくやってきたのですが、一番多い質問の一つが「緊急の割り込み仕事が多くて予定が立たない」です。作業をどうやって安定させるかはスクラムの本線なのでチームで考えるとして、結構ストレスなのが、割り込みたい人への対処だったりします。 むしろ緊急にして持ってくる人がいる 割り込みを持ってくる人は断られないようにむしろ緊急にしてから持ってくる傾向があります。列に割り込んで一歩でも前に出られたなら承認欲求が満たされるケースとか。私が責任者だから私の意見が通らないといけないと思っているとか。 透明性を担保して相手も理解できるようにする 透明性と心理的安全性を確保して、早めに相談する方が得な環境を作れるといいんじゃないかなぁって思います。スクラムだと、プロダクトバックログを透明に保って、誰でも見られるようにして、その上で何番目にその案件を位置
自分のプロジェクト管理に関する考えのまとめ - アジャイルSEの憂鬱
ここ最近は色々とあってプロジェクト管理、スクラム開発について勉強していたので、それを整理するためにまとめた。 スクラムガイド スクラム現場ガイド SCRUM BOOT CAMP THE BOOK スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) Regional Scrum Gatheringの2018, 2019の全スライド ryuzee.com の2017, 2018のスクラムに関する記事 あたりを読んで勉強したので、スクラムに関する理解はそれなりになっているはず。 ただ、評価や役割に関するところは自分の好みで少し脚色があるので、これが「スクラム開発なのか！」みたいに勘違いしないように注意。 ソフトウェア開発の前提（スクラムはあまり関係ない） 「なぜソフトウェア開発をするのか？」という前提の話を最初に書いておく。 多くの企業の目的は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最高のScrumキメた後にスケールさせようとして混乱した話
スクラムマスターを全員でやってみた
