前書き どうも、スマートショッピングでプログラマーをやっている桑島です。 昨年末頃からスクラム運用にNotionを使い始めました。まだまだ試行錯誤中ですが、現在の利用方法などについて社内共有もかねて記事としてまとめたいと思います。 弊チームのスクラムのすすめかたについて 社内でもチームごとにスクラムの進め方がちがうので、私のいるチームが普段どうスクラム開発を行っているかまず説明します。 社内のエンジニアチームですが、いわゆるSaaSのロードマップ開発を行っているチームが3つ、ハードと組み込みソフトウェアを開発しているチームが1つ、あとSREチームが存在しています。 その中で私はマッハ（Mach）というロードマップ開発を行うチームに所属しています。 チームメンバーはエンジニアが3人、PdM、デザイナーとなっており、PdMとデザイナーは他チームとの兼任になっています。 開発の流れですが、基本的

こんにちは、株式会社スマートショッピングでエンジニアリングマネージャーを担当しているleafです 先日開催された Findy Team+ Award 2023 にて組織別部門(50人未満の組織規模)とチーム別部門(レビューリードタイムが早い)を受賞することができましたので、Findy Team+ 導入から今までに取り組んだこと、今後の取り組みについてご紹介させていただきます 初めにやったこと 初期に取り組んだことは2点で、正確な現状把握と目標設定です 運用中のリポジトリに計測を導入したため、放置されたPRなどが残っており、開発状況に関係なく数値が上下することがありました そのため、対象リポジトリの放置PRなどを全て棚卸しし、どうしても制御できないPR(自動生成されるものや隣接チームの依存が大きいもの)に関してはタグを設定し除外することでようやく現状が把握できる状態となりました 目標設定に関

こんにちは！電通デジタル開発部のリチャードです。このたび弊社開発部から私を含む2人が以下の研修・およびその後の試験を受け、Scrum Alliance認定スクラムマスター(CSM: Certified Scrum Master)になりました。 20人ほどの組織である弊社開発部には、Scrum Inc.から認定されたスクラムマスターが以前から1人いるので、スクラムマスター有資格者は合計で3人となりました。 個人的には「スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介」という記事を私が書いた時に感じた、 「断片的な知識や経験で乗り切るのではなく、基礎からしっかりとスクラムを学び直したい！」という希望をScrum Alliance公式の研修と認定という形でかなえられたので、大変うれしく思っています。 研修内容紹介冒頭でリンクを貼った株式会

スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介 こんにちは電通デジタル開発部エンジニアのリチャードです。弊社で開発している社内プロダクトEASIではスクラム開発を採用しており、開発部内には認定スクラムマスターも在籍しています。一方で私個人はこれまでスクラム開発を経験してはいたものの、断片的な知識と経験で乗り切っていた部分が強く、改めてスクラムやアジャイル開発の基本を学び直そうと思い立ち、12冊の本を一気読みしました。ちょうど数ヶ月前に電通デジタルへと転職したばかりだったので、よい機会だったと思います。 今回読んだ本の一覧はこちらです！過去に読んで改めて今回読み直した本もあるため、冊数は多くなっています。 初心者向け 1. いちばんやさしいアジャイル開発の教本 2. SCRUM BOOT CAMP THE BOOK 中級者向け 3.

PySpa統合思念体です。Clean Agileという書籍が出版されたので、その読書感想文です。PySpaアドベントカレンダー2020の最終日のエントリーです。 本書の立ち位置と内容 エクストリームプログラミングについて、ケント・ベックとは別の平易な説明を試みた本です。XP自身もいろいろ変化があり、XPのプラクティスは12→13→24(11+13)→19と時代によって変わっていっています。ウェブサイトに残っている情報も、どの時代を参照しているのかによって説明がバラバラだったりしますが、この本は13で、多くの人が「原典」と考えるほとんど初期のシンプルな昔の構成にほぼ戻っているので理解しやすいと思います。12時代と13時代の間では「適切なペース」が増えました。本書では、「コーディング規約」がなくなったのと、「スタンドアップミーティング」が追加されています。 1章がアジャイル宣言を含む歴史の話、

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR（結論）SI案

はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解