「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
マネージャーの調整力に左右されていた、開発の優先順位 大規模スクラム導入で目指す、組織・チームのありたい姿
「【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから」で話されたのは、LeSSの導入における背景と工夫。Retty株式会社、株式会社アカツキゲームス、atama plus株式会社が導入の背景と知見を語りました。Retty社・マネージャーの池田氏は、LeSSの導入における同社の取り組みについて発表しました。 Retty社・マネージャー池田直弥氏 池田直弥氏（以下、池田）：トップバッターで緊張していますが、RettyのLeSSの取り組みについてお話しします。 先ほどもご紹介いただきました、Retty株式会社のマネージャーを務めている池田と申します。2021年のちょうど今頃から2022年9月までスクラムマスターをやっていました。2022年10月から新しくマネージャーになったので、「マネージャーです」と名乗るのにまったく慣れていません（笑）。 最初
スクラム開発で数スプリント先の未来の落とし穴を回避する - BASEプロダクトチームブログ
はじめに はじめまして。エンジニアの近藤(@kon_engineer)と申します。本記事は BASE アドベントカレンダー 2022 の6日目の記事です。 本記事では、私が苦い経験から学んだ、スクラム開発で未来の落とし穴を回避する考え方について書きたいと思います。具体的には、ユーザーストーリーの優先度を決めるとき、ユーザーにとってどれだけ価値を提供するかという視点だけでなく、プロジェクトとして何がリスクで、それを回避するために何からやっていくのか、しっかりバランスを考えるべきだった、という経験談を記載します。また、本記事で事例として記載するスクラム開発は、1スプリントごとにリリースする形ではなく、スプリントをある程度回して、大きな機能が出来上がったら都度リリースしていたスクラム開発の形式になります。 ユーザーストーリーについて ユーザーストーリーは、システムがユーザーに届ける価値を表現する
スクラムチームを3年リードして得た学びと目線 - yigarashiのブログ
この記事ははてなエンジニア Advent Calendar 20227日目の記事です。 昨日は id:utgwkk さんでした。 さて、今日はスクラムの話です。スクラムの導入とリードは自分のキャリアにおける重要な仕事のひとつで、気づけば3年ほどスクラムと取っ組み合ってきました。ここ1年くらいで、ようやく安定してテンポ良く開発が回るようになって、大仕事に一区切りついたような気持ちでいます。そうして少し肩の力が抜けた結果、最近はスクラムというフレームワークから一歩引いた位置に自分の目線が移動しつつある気がしています。自分の考えのスナップショットを取るには絶好のタイミングと思われるので、スクラムについての学びや、自分のスクラムに対する目線をまとめてみようと思います。 スクラム導入のキモ まずは、自分が経験したり見聞きした様子から、スクラム導入のキモだと思う点を2つほど書いてみます。どちらも越えが
なぜ「りそなのアジャイル」は成功した？ 発注先のチームラボと「フラットな関係」を貫けたワケ
熊倉 広将氏（以下、熊倉氏）：アジャイル推進室が2022年4月に新設された背景について聞かれることがあります。実はりそなグループアプリのDLは500万件を突破するなど最大のチャネルであり、そこに付随するプロジェクトもいろいろ出始めています。 オープン・イノベーション共創拠点「Resona Garage」という場所で開発していますが、今後より体制を強化し、スピードを上げたグループの開発運営を担うために、アジャイル推進室ができました。 後藤 一朗氏（以下、後藤氏）：2018年2月、アプリのリリース段階では、アジャイル開発手法は我が社の中でかなりチャレンジングな取り組みでしたので、組織化するまでの状態ではありませんでした。しかしそれから4年半が経ち、アジャイルプロジェクトの全工数が当社側とパートナー企業側と合わせて100人規模になってきたため、組織的な対応が課題になってきたということです。 では
とあるチームの1週間 | IIJ Engineers Blog
名古屋支社開発チームのスクラムマスターとして日々奮闘中。よいサービス、よいプロダクトは楽しく元気なチームから生まれると思っています！関わる人すべてが笑顔になるために、私は何ができるのだろうか・・・。 今回はとあるチームの1週間をご紹介します。 スクラムの時間割 時間割の紹介です。 スプリント スプリント(※1)を簡潔に表現すると “期間” のことで、スプリント（期間）内に仕様の決定、設計、開発、テストなど、システム開発に必要なほぼすべてのことを実施します。 スプリントはスプリントプランニング（計画）から始まり、スプリントレトロスペクティブ（期間のふりかえり）で終わります。 このチームでは1週間を1スプリントとしています。 （本来であればスプリントレトロスペクティブの後にスプリントプランニングを実施することが理想ですが、諸事情によりこのチームはスプリントプランニングを先に実施しています） 余
スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO
はじめに みなさんこんにちは、CX事業本部Delivery部のかみとです。 受託開発のプロジェクトをスクラムで始める際、アジャイル開発やスクラムのフレームワークに対する認識がお客様とベンダー間で一致していることが望ましいのですが、アジャイルやスクラムの経験有無、理解度の違いなどによって異なった認識のままプロジェクトが開始してしまうことで、後々プロジェクトの進行に影響を及ぼしてしまうことがあると思います。 これがただの小さな認識のズレで、プロジェクト進めていく中で調整可能なものであればいいのですが、そもそもの前提が違うくらいの大きな認識相違となってしまった場合、プロジェクトとしてはもちろんお客様との信頼関係にも悪影響を与えかねません。 そういった状況を避けるためにも、なるべくプロジェクト開始前にお客様との間でアジャイル開発にまつわる、よくある誤解を解消しておくのはとても大切なことだと思います
あなたが学んだアジャイルとテスラの手法は何が違うのか？ 認定スクラムトレーナーが語る、テスラの真の凄さ
「Agile Tech EXPO（あじゃてく）」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベーションの加速のポイントとなる「スプリントの長さ」と「プロジェクトの同時進行」について。 テスラのアジャイル文化を12のステップで紹介 ジョー・ジャスティス氏：本日はありがとうございます。アジャイルハードウェアディロップメントとして、アジャイルをいかにハードウェア開発に適用していくかということを、今回お話しします。 私の経験ですが、マイクロソフトのビル・ゲイツや、スペースカンパニーやAmazonをやって
どういう時に「スクラム」フレームワークを使いたいのか - stefafafan の fa は3つです
我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている） タスクが急遽差し込まれたり、方針が変わったときにスムー
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
スクラムマスターって何をする人なの？ - だいくしー(@daiksy)のはてなブログ
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの？ 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
スクラムのリファインメントをうまく運用するためのポイント - Qiita
私たちのチームでは、今年の4月からスプリントで開発する項目（以下ユーザーストーリーと呼びます）の見積もりをリファインメントにて行なってきました。 今回は、このリファインメントで試行錯誤してきた内容をまとめます。 前提 リファインメントとは？ スクラムガイドより プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメントは、開発チームの作業の 10%以下にすることが多い。 私たちのチーム エンジニア6名、デザイナー3名(1名増えた！)のチームで1週間で1スプリントのペースで実施
ママリ開発チームがスクラムマスターを輪番制にしている理由 | Connehito Tech Magazine
ママ向けQ&Aアプリ／情報メディア「ママリ」の開発チームは、スクラムマスターを固定することなく輪番制を取り入れた1週間のスクラムで開発を進めています。ママリ開発チームの柳村、富田にインタビューをし、スクラムマスターを輪番制にしている目的やどのように進めているのか、などご紹介します。 この記事はコネヒト Advent Calendar 2019 20日目の記事です。 はじめにママリ開発チーム 柳村、富田のご紹介です。柳村（写真左）：エンジニア。組み込み業界からWeb業界に転身し、グリー、Supershipを経て、現在コネヒトで主にママリのiOSアプリの開発を担当。 富田（写真右）：エンジニア。サーバサイドエンジニアからAndroidエンジニアに転身、Diverseなどを経て、現在コネヒトで主にママリのAndroidアプリの開発を担当。 ママリ開発チームは、日々ユーザーの体験、価値向上を目指し
初期のプロダクトバックログの作り方
みなさんこんにちは。@ryuzeeです。 別のところで依頼を受けて作った文書なのですが、皆様の参考にもなるかと思いますので共有しておきます。 まずはプロダクトゴールを検討するプロダクトバックログは、プロダクトゴールの実現のために存在します。 つまりプロダクトバックログを作るには、プロダクトとして実現したいゴール、顧客に提供したい価値などをあらかじめ検討する必要があります。 リーンキャンバス、エレベーターピッチ、ユーザーインタビュー、エスノグラフィーなどのテクニックを活用しながら、プロダクトとして解決したい課題、実現したい価値やゴールを評価しますプロダクトを実際に開発するのはお金も時間もかかるので、本来この時点で仮説検証を繰り返し、ダメなアイデアを早めに捨てる必要がありますある程度いけそうなアイデアが出てきたら先に進みますスプリント開始の条件スクラムでスプリントを開始できるのは、プロダクトバ
「家族アルバム みてね」のSREチームの紹介と取り組み
こんにちは、みてね事業部 開発グループ SREチームの清水 @isaoshimizu です。 この記事では、「家族アルバム みてね（以下みてね）」を支えるSREチームはどんなチームで、普段どんなことをやっているのかを紹介していきたいと思います。チームの行動は頻繁にアップデートされていくので、定期的にブログ記事にできたらと思っています。 みてねのSREチームはこんなチームまずは、みてねのSREチームの紹介と毎日の仕事の流れについて紹介したいと思います。 ちなみに、SREチームは2018年2月1日に作られました。この時のチームメンバーは3名でした。 SREチーム用のSlackチャンネルが作られたときここから徐々にメンバーが増え、2021年6月時点でのSREチームメンバーは5名となっています。 SREチームが作られてから3年以上経過し、当初からスクラムというスタイルで変わらず運用していますが、1
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
アジャイルなチームをつくる ふりかえりのガイド / A Retrospective Guide
2021/02/19 Developers Summit 2021 （https://event.shoeisha.jp/devsumi/20210218/session/3078/） 19-C-9 『アジャイルなチームをつくる ふりかえりのガイド』の登壇資料です。 ふりかえりが少しずつ認知されてから、様々なところでふりかえりの重要性が叫ばれてきました。ただし、どう始めたらいいのか、どう定着までに至るのか、道のりはあまり述べられてきていません。 ふりかえりは、チーム全員で定期的に立ち止まり、チームがより良いやり方を見つけるために話し合いをして、チームの行動を少しずつ変えていく活動です。COVID-19とリモートワークの加速によって、これまで顔を合わせて働いていたチームも、直接会って仕事をする機会は今後も減っていくでしょう。これから新しくチームを作ることも今まで以上に難しくなっていきます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デイリースクラムいらなくなくなくなーい！？
「やらないことリスト」をまず作れ、アジャイル開発で必ず役立つ
プロダクトバックログ Deep Dive
