スプリント1を始める前にどんな準備をするか
みなさんこんにちは。@ryuzeeです。 スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。 なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。 1. はじめに1.1 この記事の目的スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。 つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。 本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察してい
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
スプリントレビューの進め方
みなさんこんにちは、@ryuzeeです。 スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。 今日はスプリントレビューについて、一般的な手順や注意点を紹介します。 なお、あくまで一般的な手順であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 スライドはこちらをご参照ください。 1. スプリントレビューの目的 2. スプリントレビューの参加者 3. スプリントレビューのアジェンダ（例） 4. スプリントレビューの事前準備 5. ステークホルダーへの質問（例） 6. 良いスプリントレビューの特徴 7. スプリントレビューのアンチパターン 1. スプリントレ
先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
スクラムでプロジェクトを始める前にお客様に説明しておきたいスクラムのエッセンス | DevelopersIO
はじめに みなさんこんにちは、CX事業本部Delivery部のかみとです。 受託開発のプロジェクトをスクラムで始める際、アジャイル開発やスクラムのフレームワークに対する認識がお客様とベンダー間で一致していることが望ましいのですが、アジャイルやスクラムの経験有無、理解度の違いなどによって異なった認識のままプロジェクトが開始してしまうことで、後々プロジェクトの進行に影響を及ぼしてしまうことがあると思います。 これがただの小さな認識のズレで、プロジェクト進めていく中で調整可能なものであればいいのですが、そもそもの前提が違うくらいの大きな認識相違となってしまった場合、プロジェクトとしてはもちろんお客様との信頼関係にも悪影響を与えかねません。 そういった状況を避けるためにも、なるべくプロジェクト開始前にお客様との間でアジャイル開発にまつわる、よくある誤解を解消しておくのはとても大切なことだと思います
ログラスエンジニアの村本です。 この記事では、ログラスのスクラムチームで取り組んだ改善事例をご紹介しようと思います。 改善事例を紹介しようと思ったキッカケは、2022年8月から私の所属チームのチームリーダーがEMに昇格し、私がチームリーダーになったことです。 チームリーダーになったことで、これまであまり意識してこなかったチームの成果を最大化する方法を考える機会が生まれました。 そして様々な改善アプローチをスピード感を持って試すことで、効果を実感できた改善もいくつか生まれ、チームがどんどん良くなっていくという素晴らしい経験ができました。 この記事では、効果を実感できた改善の中で特に印象的だった7つをご紹介しようと思います。 この記事を通して、スクラムをやりたいと考えている方や、スクラム開発をやっていて課題感を感じている方、ログラスに少しでもご興味がある方のご参考になれば幸いです。 2022年
こんにちは、エンジニアのちぎら @_naru_jpn です。ミラティブでは開発プロセス改善の一環として、スクラムフレームワークを試験的にひとつの開発チームに導入し、開発を行っています。該当する開発チームでは1週間のタイムボックスでスプリントをきり、導入開始から12スプリント(3ヶ月弱)をこなしてきました。チームのスクラム開発にも慣れが見えはじめ、当初想定していた開発プロセスの改善も実感が湧くようになってきました。今回は、スクラム導入の背景や内容、今後の展望などをご紹介します。 スクラム導入前の開発体制とモチベーション スクラム導入前の開発イメージ スクラム導入前の開発の流れは上図のようです。仕様書と工数の概算をもとにしてガントチャートにスケジュールがひかれ、フェーズごとに開発を進めていきます。もちろんすべて天下り式に開発を進めている訳ではなく、デザインがある程度できた時点でエンジニアも含め
「みんなのPython勉強会」では、Pythonを中心としてプログラミングを様々なシーンに生かす方法を一緒に学んでいます。今回は初級、中級のサーバーサイドエンジニア向けに、開発現場のアドバイザーでもある長沢氏がアジャイルとDevOpsについて話しました。後半はアジャイルとDevOpsをどう取り入れればいいかについてです。 従来の開発計画とアジャイルの計画の違い やっと本題のうちの1つ、アジャイルの話に入ります。アジャイル開発自体の成り立ちの話は今日はしません。今日話しておきたいのは従来型、わかりやすく言うとウォーターフォールに近いものの開発のやり方とアジャイルのやり方はだいぶ考え方が違うというところをお伝えしたいです。 従来の開発の計画の仕方というのは基本的にはすべてのスコープをはっきりさせます。ウォーターフォールは要件定義を最初にやりますよね。要件定義で全部決め、すべての要件が固まって見
ノーコードAI開発ツールNode-AIの紹介 - NTT Communications Engineers' Blog
はじめに 初めまして！イノベーションセンターでノーコードAI開発ツール「Node-AI」のプロダクトオーナーやXAI・因果分析の研究をしております、切通恵介（@kirikei）です。 Node-AIは2021年10月11日にリリースされたNTT Communicationsの内製開発サービスで、その名の通りブラウザ上からノーコードでAIモデルを開発できるサービスで、製造業のお客様を中心に異常検知やプラント運転支援などの様々な領域で活用されています。（ニュースリリースはこちらやこちらやこちら） いつもはサービスの営業的な紹介をすることが多いのですが、今回はEngineer's Blogでの執筆ということで、エンジニアの方向けの技術、プロダクトマネジメント、チームビルディング、スクラムなどの様々な観点でお伝えできればと考えています。とはいえ、Node-AIに関しては詳細に書きたいことが山ほどあ
株式会社ラクスが開催するエンジニア向けのイベント「RAKUS Meetup」。今回は「ソフトウェア開発の原則/法則」をテーマに、「楽楽精算」の開発エンジニアである紀井美里氏が、SaaSを開発するに当たって、人が集まっているだけのグループから自律した「チーム」になるまでに大切にしてきた3つの開発原則を紹介しました。講演資料はこちら SaaSを支える3つの開発原則 紀井美里氏：それでは「開発グループが開発チームになるまでの歩み」と題しましてお話しいたします。 まずは簡単に自己紹介いたします。私は紀井と申します。新卒で株式会社ラクスに入社しまして、入社してからずっと楽楽精算の開発に携わっています。一時期、子会社のラクスベトナムのメンバーと一緒に、オフショア開発をやっていた時期もあったのですが、現在は楽楽精算の国内開発チームで、PMのような役割を任されています。 そして本日お話しするのは、今日のR
この記事は freee Developers Advent Calendar 2020 の3日目です。 こんにちは。freee でスクラムマスターをやっているichy(Takeru Ichii)です。この記事がfreee developers blogの初めての記事になります。拙い部分もあるかと思いますがお手柔らかにお願いいたします。 みなさま、スクラム開発ってご存知ですか？やっている方も多いかと思いますし、やっていたという方も多いかと思います。先に紹介したとおりスクラムマスターをやっているので私は現在進行系でスクラム開発をやっています。私が感じている世間的な印象ですが、スクラム開発は上手く行かないといわれることが多い気がします。チケット駆動開発をしているところは多いかと思いますが、スクラム開発となるとなかなか運用に手間がかかるのは事実ですし、手間のわりに改善したように感じない印象を持つ方
新しい会社に入社してから7ヶ月でスクラムマスターとしてやったこと - だいくしー(@daiksy)のはてなブログ
いよいよ RSGT2022が迫ってきましたね！ これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの？」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた｜ハイクラス転職・求人情報サイト AMBI（アンビ）
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた スクラムは多くの開発現場で取り入れられており、その原則を学ぶのは簡単です。しかし原則を現実に実行しようとすると、さまざまな課題が……。アジャイルコーチの吉羽龍太郎さんにスクラムの基礎から、ありがちな課題への対処法をたっぷり聞きました。 スクラムは軽量で理解が容易、だけど実際にやるのが難しい 【スクラムの基礎知識】3つの役割を理解する 【スクラムの基礎知識】5つのイベントを理解する 【スクラムの基礎知識】3つの作成物を理解する スクラムを“現実的に”実践する手法 見積もりは誰のもので、誰が作るのか フィボナッチ数列よりも「Tシャツ見積もり」。素早く見積もりを作る手法 スプリントの期間は1週間が計画しやすくておすすめ スプリントプランニングの極意。タスクの粒度は小さければ小さいほど扱いやすい タスク管理
2022 年 7 月から株式会社ログラスに業務委託として関わっている近藤です。 ログラスではスクラムによる開発体制を採用しています。この数ヶ月でスクラムイベントの 1 つであるスプリント・レトロスペクティブ（ふりかえり）の改善に取り組みました。この記事では主に次の対象者向けに、改善した内容について紹介します。 スクラムに取り組んでいる人 ふりかえりのやり方、効果に悩んでいて、改善したい人 ファシリテーションに興味がある人 ※ 以下、記事中ではレトロスペクティブのことを省略してレトロと呼びます。 経緯 改善前、レトロでは Miro を使った KPT[1] を次の流れで行っていました。 スプリントで完了したチケットの確認（Jira の Backlog 確認） KPT 作成の非同期ワーク[2]（以下、KPT ワークと呼びます） 各参加者が KPT 内容を発表 付箋のグルーピング Try について
スクラムじゃなくても良かったのだ - ちなみに
この記事は クラスター Advent Calendar 2022 (2枚目) 2日目の記事です。 クラスターではサーバーエンジニアをしている id:Sixeight です。 まだ入社エントリも書いていないのですが、アドベントカレンダーの空き枠があったので慌てて筆を執りました。 1枚目のカレンダーにもエントリーしているので、そちらで入社エントリを書く所存です。 さて表題ではあえて強めの言葉を使いました。 これまで所属していた会社ではスクラムを採用していることが多く、それどころか私自身がスクラム推進派でした。 しかしながら転職してからスクラムのスの字も出てこない環境で働いているのですが、これまでよりも調子良く働いているうえに組織の生産性は高く感じています。 この記事ではなぜそう感じるのかということをさらっとまとめたいと思います。なぜなら突然思いついて時間がないからです。 スクラムとは スクラム
ミラティブのプロダクト開発体制と組織を解説する: The Mirrativ Model, Autumn 2021 - Mirrativ Tech Blog
はじめに みなさまお久しぶりです、前回記事を書いたのが1年前というよこて @n0mimono です。今回はミラティブのプロダクト開発の体制的な話を書いてみようと思います。 ミラティブではMirrativというサービスを作り、運営していますがこれをどういう体制で作っているのかというお話です。開発フローとか技術的な話というより、どういう組織構造で作ってるのか、あるいは開発するものをどう決めているのかというあたりを語ります。（開発フローってどうなってんの？みたいな話は他の誰かが書いてくれるはず！） 先にネタバレするとこの記事はこの本の影響を受けています。 www.amazon.co.jp 本の影響を受けて開発体制をつくったというわけではなく、少しずつ改善していって後から振り返ったら「あれこれ似たようなことやってるな・・」という感じですね。 プロダクト開発と体制 The tribes ミラティブの
新任エンジニアリングマネージャーが新規事業で果たした役割と今考えていること - KAKEHASHI Tech Blog
はじめに こんにちは！エンジニアリングマネージャーの小田中（@dora_e_m）です。 この記事はカケハシ Advent Calendar 2023 の 12日目の記事になります。 https://adventar.org/calendars/8587 今年はPart2もあるのでぜひそちらもご覧ください！ https://adventar.org/calendars/8728 この記事ではタイトルのとおり、新規事業のプロダクト開発チームにおいて新任のエンジニアリングマネージャー（以下、EM）がどのような役割を担うのか、私自身の実体験をもとに紐解いていきます。 前提: カケハシに存在するEM、開発ディレクターというロール カケハシにはEMに加え、開発ディレクターというロールがあります。カケハシでは基本的にどのチームでもスクラムを採用しており、開発ディレクターはスクラムマスターとイコールで考え
プロダクトバックログアイテムはいつ見積もればいいですか？
スクラムガイド2020には以下のように記述されています。 1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。 プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。 これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。 多くの場合、属性は作業領域によって異なる。 最初の文が意味するところは、以下のとおりです。 スプリントで選択するプロダクトバックログアイテムは1スプリント内で完成する大きさになっていなければいけない1スプリントに収まるサイズになっていれば、スプリントプランニングで選択の準備ができていると言える選択のための準備は、通常リファインメントの活動のなかで行うリファ
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（後編）。Developers Summit 2019
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（後編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。 本記事は「スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019」の続きです。 プロダクトオーナーをスケールする ここまではスクラムマスター側をスケールさせる話をしてきました。 その反対側のプロダクトオーナー側はどうでしょ
スクラム開発未経験からスクラムマスターになってみた - 弁護士ドットコム株式会社 Creators’ blog
この記事は「弁護士ドットコム Advent Calendar 2023」の 14日目の記事です。 前日の記事は @astkhs さんの「イマジナリーキャットと暮らしたい」でした。 とても真剣に猫を追求する内容がとても面白く興味深かったです！ タイトルだけで面白いのずるいです（笑） 弁護士ドットコム株式会社で、電子契約サービスであるクラウドサインの開発に携わっているエンジニアの神達です。 入社して2年経ったのですが、業務にて入社前には未経験だったスクラム開発をすることになったので、その過程と大事だと思っている内容をまとめてみました。 内容としてはマインド面の要素が多く、具体的なテクニックのようなものは少ないです。 まだ経験値は浅いのですが、似た境遇の方に参考にしていただいたり、単純に読み物として楽しんでいただければ幸いです。 対象読者 要約 前提知識 スクラム開発ってなに？ ん？？アジャイル
ビジュアルリグレッションテストにChromaticを導入したらデザインレビューが捗った話 - Money Forward Developers Blog
マネーフォワード関西開発拠点エンジニアの @uenoY4 です。 現在、私のチームではフロントエンドに Next.js を使用したプロダクトの開発をしています。 その中でリファクタリングなど既存実装に修正を加えた際に、意図しないUIの崩れが起きることを防ぎたいという思いから、ビジュアルリグレッションテストを行うようにしました。今回はビジュアルリグレッションテストを行うために導入したChromaticについてお話しします。 目次 ビジュアルリグレッションテストとは Chromaticとは Chromatic導入のきっかけ 実際導入してみて まとめ ビジュアルリグレッションテストとは ビジュアルリグレッションテストとは、ページの見た目をテストする仕組みで、変更前のページやコンポーネントの画像と変更後の画像を比較して検証を行います。要素のサイズや配置などのピクセルレベルの変更やテキスト色、背景色
モバイルアプリ開発チームのスクラムってどんな感じ？ - Chatwork Creator's Note
こんにちは！モバイルアプリケーション開発部でスクラムマスターをしている折田 (@orimomo)です。 私たちの部署ではiOSエンジニア・Androidエンジニアが混在する2つのチームを作り、それぞれでスクラムによる開発をおこなっています。 私自身もともとはiOSエンジニアなのですが、現在は専任のスクラムマスターとして両チームに関わらせてもらっています。 最近では各々の継続的な改善が実を結び、スクラムチームとして少しずつ、しかし確実に成長ができているなと感じられるようになりました。 「スクラムが楽しくなってきた！」「いいチームになってきた気がする！」という話をメンバーから聞くことも増え（嬉しい🙌）、ここまで色々あったなぁ…長かったなぁ…と感慨深く思っています。 今回は、そんな私たちが具体的にどのようにスクラムを回しているのか、また以前と比べてどのように変化してきたのかについてご紹介ができ
スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの
「Scrum Fest Osaka」はスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる様々な人々が集まる学びの場です。徳冨氏は、アジャイル開発20年続けて得た学びについて発表しました。全2回。後半は、ホンモノのスクラムを学んだ方法について話しました。前半はこちら 映画『ベスト・キッド』のような開発現場 徳冨優一氏（以下、徳冨）：次はスクラムを叩き込まれた話です。ホンモノのスクラムをインストールされたというお話をしようと思います。 「スクラムに全力で取り組むことを誓うか」が契約の条件だったんですよ。こんなの聞かれたことないですよ。みなさんもいろいろなところで面談を受けると思いますが、こんなのないでしょ？ 今思えばすごく不思議な面談でした。まるで『スター・ウォーズ』のワンシーンですね。記憶が美化されているかもしれませんが、ヨーダと『スター・ウォーズ』のワンシーンのような
atama plusの大規模スクラム(LeSS)リモートイベント見学レポート【前編】 - アジャイルコーチの備忘録
以前から大規模スクラム(LeSS)の書籍を繰り返し読み、コミュニティに参加し...と大規模スクラムの理論を学んできましたが、「理論は素晴らしいけど、現実で上手くいくのだろうか？」とどこかで感じてもいました。 そんな折、認定LeSS実践者研修で知り合い、大規模スクラムを実際に導入したatama plusのスクラムマスター河口さんから、「良ければウチの現場を見学しない？」と言葉を掛けていただき、ようやくこの目で大規模スクラムを見学することができました! 今回は、前編と後編に分けて、見学レポートをお届けします。 前編ではスクラムイベントの流れや、atama plusが独自にplusしている工夫を書いていきます。*1 こんな方にオススメ atama plusと組織構成 大規模スクラムとは? 見学したスクラムイベント スプリントプランニング スプリントプランニング第1部の流れ(1h) スプリントプラ
本記事は『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発』の「基礎編 スクラムって何？」の一部と、「実践編 どうやればうまくいくの？」の「Scene No.00 開発したいものの概要と人物紹介」を抜粋したものです。掲載にあたり一部を編集しています。 はじめに ソフトウェアを作るのは簡単ではありません。 最初にどんなものを作るかをきちんと考えて作り始めても、いざ進めてみると途中でほしいものが変わったり、さまざまな要望が出たりします。 ソフトウェアを作るのに時間がかかりすぎてそれ自体に意味がなくなってしまったり、たくさんお金がかかってしまったり、なんとか完成させても実際に手にしてみたらほしいものとは違っていたり、といったことが起こります。 ソフトウェアを作るうえで本当に重要なことは何でしょうか？ それは、できあがったソフトウェアを実際に
スクラムショーワークショップとは yycr2019(アジャイルコーチとスクラムマスターの宴、通称：よなよなコーチングリトリート)で生まれた、スクラムを短い時間で理解するためのワークショップの紹介です。 発起人は森一樹(@viva_tweet_x)と吉羽龍太郎(@ryuzee)です。 スクラムショーワークショップは、スクラムの説明をショー（寸劇）形式で行うワークショップです。 内容はご自由に使っていただいて構いませんが、利用する場合はクレジットをどこかにご明記ください。また、SNS等で利用した旨を共有いただけますと、ワークショップの作成者皆が喜びます。 なお、この記事はイベント中にモブブロギングによって作成されました。 記事の内容は06/19AMに行ったワークショップのリハーサルによって、時間や細かな流れなどカイゼンが行われる予定です。 記事の内容は06/19AMに行ったワークショップのリハ
スカウト返信率50％超え！エンジニアから選ばれる企業になるためにhokan・前島治樹が実践した「エンジニアtoエンジニア」の採用戦略
エンジニアの採用活動を加速させるためには、自社の開発環境やプロダクトの魅力を深く理解し、自らも開発に取り組むような「キーマン」となるエンジニアの協力が欠かせません。一方で、エンジニアが採用活動に直接携わることに関するノウハウや、その意義や必要性を知ることができるコンテンツは、まだまだ世に足りないようにも感じます。 そこで今回は、現役エンジニアでありながら、スカウトサイトなどを駆使して優秀なエンジニアの採用を急ピッチで実現している、hokanのエンジニアリングマネージャー・前島治樹さんを招き、採用活動で実践していることをお聞きしました。 保険業界のアップデートを目指し、「InsurTech（保険×テクノロジー）」の分野で保険代理店向けのSaaS開発を進めるhokan。業界理解が難しい領域ではありますが、前島さんが採用に携わり、わずか2ヶ月で内定受諾率60%超え、スカウトメールへの返信率も50
こんにちは。EMの加川(@shinpr_p)です。 本記事は、開発プロセスの変更を残したADRを眺めながら、スクラムの適用など開発チームの改善と向き合ってきた2-3ヶ月を振り返ります。 はじめに 前提知識としてADRについて説明します。 ADRは Architecture Decision Records の略で、アーキテクチャの決定を記録したドキュメント群です。 「意思決定の過程を残すこと」が特徴で、「検討したが導入しなかったもの」や「運用を進めることで適切ではなくなったため廃止したもの」、「技術選定の過程で選ばれなかった選択肢」など、よく歴史的経緯と言われがちな過程の情報が残ることが好きで、私はここ数年よく利用しています。 cloud.google.com 実際のADR 実際のADRがこちらです。 意思決定の関係者はby nameが含まれるので、公開用に加工しています。 以下、それぞれ
スクラムマスター研修参加と資格を取得して得られた知見について共有します！ - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2023 DAY 13 の記事です。 はじめに 転職会議事業部でエンジニアとして働いている@ishitan-livと申します。 現在、スクラムマスターも兼任しています。今回は、受けたスクラムマスター研修に関するエピソードを共有したいと思います。 はじめに 今回書いた内容 スクラムマスター研修参加してきた話 研修概要 日程: 3日間 参加人数: 約20人 講習内容 研修で得たフィードバック CSM（認定スクラムマスター）試験結果 エンジニアがスクラムマスターを兼任することで得た知見 兼任はしないほうがいいけど…そうもいかないよね チームやプロジェクトの全体像が見えるようになった ファシリテーション力やまとめ力が高まり他のミーティングなどで活用できた 議題の本質を考えるようになった 最後に おまけ 今回書いた内容 目次通り、この記事で
Scrum Inc. Japan #TeamworkMakesTheDreamWorkScrum@Scaleガイド - Scrum Inc. Japan #TeamworkMakesTheDreamWork
Scrum@Scaleガイドの序文 スクラムは、もともとスクラムガイドで説明されているように、単一のスクラムチームが、持続可能なペースを維持しつつ、最適な価値を提供できるようにすることを重視している。スクラムガイドの発行以降、スクラムの利用はプロダクト、プロセス、サービスなどの開発といった複数チームの協力が求められる領域まで広がりを見せている。 現場では、組織内のスクラムチーム数の増加に伴い、2つの重要な問題の発生が繰り返し見られた。 複数のチームの間での依存関係や作業の重複、コミュニケーションのオーバーヘッドなどの問題により、チームごとのアウトプット（動作するプロダクト）の量、スピード、品質が低下し始めた。 従来の組織構造はビジネスアジリティの実現に十分な効果を上げられなかった。優先順位の競合や、市場の変化に対応するようチームを素早く転換させることができないなどの問題が発生した。 こうし
念願だったScrum Allianceの「認定スクラムマスター(CSM)」に合格したので、研修の申し込みから試験合格までの流れを紹介しようと思う。 これから「認定スクラムマスター(CSM)」を受講・受験しようと考えている人の参考になれば幸いだ。 スクラムの認定制度の種類 日本において、スクラムの認定制度は以下の二種類がある。 認定の名前 認定機関 日本における主な研修主催者 受講料 なぜスクラムの認定制度が二つあるのか経緯はわからないが、どちらもスクラムの考案者の一人であるJeff Sutherland氏が関わっているので、どちらが上とか偽物とかいうことは無いようだ。 ただ、Scrum AllianceのCertified Scrum Master(CSM)の方が歴史が長いため、日本においてはこっちの方が知名度が高いと思う。 Scrum Inc.のFAQには以下のような記載があるので、今後
How Scrum boosts your innovation in Japan 1. Scrum Inc. Japan 株式会社 取締役 平鍋健児 2 ⽇本のイノベーションを 加速するScrum 2. 平鍋健児 (株)Scrum Inc, Japan 取締役 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO アジャイルジャパン初代実⾏委員⻑ • アジャイルを⽇本に広めたい • システムズエンジニアリングツール astah* 開発、起業 3 3. COO Toyota Research Institute - Advanced Development, Inc. ⾍上 広志 5 4. こちらからご覧ください https://scruminc.jp/scrum-consulting-and-coaching/casestudies/tri-ad/ 5. 9 6. ⽇本の⽼舗
はじめに はじめまして。 Musubi 開発チームで SRE を担当している、家事育児 🧹🍳👧 の負担率がイレブンナインの大山です。 この記事はカケハシ アドベントカレンダー🗓 part2の 12 日目の記事です。 そして入社してそろそろ 2年になりますが初投稿です。 この記事 is 何 ゆるふわスクラムをしていた私（38歳）がはじめてガチのスクラムにチャレンジし、継続的に課題を解決しながらスプリントを走った備忘録です。 また課題に対するカウンターや、スプリントを 4回ほどこなしたイマココの所感をまとめています。 記事のタイトルにあえて年齢を入れたのは下記の対象読者に向けた意図がありました。 対象となる読者 しっかりめにスクラムをすることに興味がある方 年齢を理由に何かをはじめることにためらいがある方 スクラム未経験🐤 〜 ゆるふわスクラム時代 早速ですがスクラムの話です。 まず
ゾンビスクラムの4つの症状
4つの症状を紹介し、「外の世界との接触を望まない」という症状について詳しく説明する この記事は、Zombie Scrum Resistanceのブログ記事「The Four Symptoms of Zombie Scrum」を日本語訳したものです。翻訳に快諾していただきありがとうございます。 訳がおかしいところがありましたら、お気軽にご連絡ください。 また、現在『Zombie Scrum Survival Guide』を誠意翻訳中です。 来年には出版される予定ですので、楽しみにお待ちください。 ステークホルダーを招待するの忘れた ああ、そうですか この投稿は、私たちが書いている本、『Zombie Scrum Survival Guide』から抜粋したものだ。これは、小さなインクリメントを提供し、ステークホルダーである読者のみんなを巻き込む方法である。みんなからのフィードバックや励まし、斬新
今回紹介するプラクティスは朝会と名付けしていますが、上記に上げたどのイベントやプラクティスでも共通する内容となっています。 朝会でありがちな問題と解決の糸口としてのパターン ここから先は朝会とデイリースクラムを厳密には分けずに話を進めようと思います。多くの現場で朝会が行われているもののマンネリになり、最終的には「意味がない」と結論付ける現場も見たことがあります。私が直面した現場でも以下のような現象が見られました。 朝会というイベントが形骸化して、その目的を失っている状態になってしまっていると感じ、朝会を行う目的を再考するためにScrum Patternsで公開されているデイリースクラムパターンを確認しました。 デイリースクラムパターン デイリースクラムは Scrum Patternsとして公開されている ので、その定義を見てみましょう。以下は筆者がデイリースクラムを翻訳して要点を抜き出した
【AWS DevDay Tokyo 2019 セッションレポート】レガシーコードからの脱却 #AWSDevDay | DevelopersIO
10/05追記 本日スピーカーの吉羽さんご本人がスライド資料付きの登壇内容ブログを公開されましたので、そちらをご確認された方が良いかと思います。 【資料公開】レガシーコードからの脱却 セッション概要 クラウドを活用することで調達のリードタイムは過去に比べて圧倒的に短くなり、ビジネスの変化にも柔軟に対応できるようになりましたが、このクラウドの特性を享受するためには「アプリケーション」自体も信頼性が高く、変化に対応できることが必要です。 一方で、機能を変更すると他の場所が壊れる、影響範囲が大きすぎて新しい機能の開発に時間がかかるといった、レガシーコードに起因する問題に悩まされている開発チームが多いのも事実です。 本セッションでは、そもそも最初からレガシーコードを作らないようにどうすれば良いかについて9月発売の同名書籍の内容を踏まえて解説します。 スピーカー 株式会社アトラクタ CTO 吉羽 龍
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
見積もりをがんばらない - forest book
「こうしてスクラムが終わってしまう」前にすべきこと
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
スクラムで問題(バグ)対応するときのアプローチ - やっとむでぽん
ゼロから始めるシステム障害対応フロー - Qiita
スクラムチームの成果を最大化させた7つの改善 ~ 新米リーダーの挑戦 ~
開発組織にはじめてのスクラムを導入する - Mirrativ Tech Blog
アジャイルもDevOpsも費用対効果より機会損失で考える DASAアンバサダーが贈るこれからの開発現場へのアドバイス
“OODAループ”“心理的安全性”“銀の弾丸などない” 「楽楽精算」のPMが大事にする3つのSaaS開発原則
私のスクラム開発。もしくはペペロンチーノの作り方。 - freee Developers Hub
50分のふりかえり（スプリント・レトロスペクティブ）の議論時間を 2 倍に改善した話
不確実なスパイクを確実にDONEする試み in スクラム
契約条件は“スクラムに全力で取り組むことを誓う” まるで『ベスト・キッド』の現場で得たアジャイル開発の学び
スクラムってどんな開発手法？ 基本ルールや必要な役割を人気ロングセラーの改訂版から紹介
スクラムの理解を深める「スクラムショーワークショップ」のご紹介 - Qiita
開発プロセス版ADRで振り返る開発チームの改善活動 - DROBEプロダクト開発ブログ
認定スクラムマスター(CSM)に合格したので試験合格までの流れを紹介する - Qiita
How Scrum boosts your innovation in Japan
38歳、はじめてのスクラム - KAKEHASHI Tech Blog
朝会カイゼンのコツー5本指朝会 | オブジェクトの広場