スクラム開発が全然しっくりこないまま スクラムマスターになってしまった僕が取り組んだこと
はじめに こんにちは、土屋と申します。バニッシュスタンダードで社内システム保守とスクラムマスターを担当しています。最近の趣味は早朝にゼルダの伝説ティアーズオブキングダムをプレイすることです。なかなかハイラルが平和になりません。トーレルーフ!! ところでみなさんスクラム開発しっくりきてますか?完璧ですか?心酔してますか? 僕は開発メンバーとして何度かスクラム開発を経験してきましたがどうもしっくりきませんでした。ウォーターフォールやデスマーチしていたあの頃に戻る気はないけど、とはいえ良さが理解できない。こんな印象が拭えないままスクラムマスターになってしまいました。 でも。こんな僕でもスクラム開発とちょっとだけ仲良くなれた気がしてきました。スクラム開発と仲良くできない、しっくりこない、そんな方に向けて1つの情報になれば幸いです。 スクラムマスターになった経緯 昨年末、スクラムマスターだった dk
プロダクトマネージャーの役割は「プロダクトマネジメントをすること」だけではないかも - Qiita
はじめに 今回プロダクトマネージャーの動きを行っていく中で、新しい気づきがあったので記事としてまとめました。 プロダクトマネジメントをプロダクトマネージャーだけで行わない プロダクトマネジメントとは、プロダクトを成功に導く考えであり、これはプロダクト作りに関わる人であれば必ず必要になってくるものです。 つまり、プロダクトマネジメントとは特定の誰かが行うアクションではなく、チームや組織全体で行っていくものだと考えています。 プロダクトマネージャーの役割 プロダクトマネージャーの主の役割とは、もちろんプロダクトマネジメントを行うことです。 しかし、プロダクトマネジメントが行えている状態を組織として目指すためには 「プロダクトマネジメントをすること」だけではなく「プロダクトマネジメントができる組織づくり」も行う必要があると考えています。 そのためには、プロダクトマネージャーとして、「プロダクトマ
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
スプリントゴールって何なんだ!? 「スクラムガイドを読み解いてみよう」に参加しました - Qiita
概要 2020年9月13日の「スクラムガイドを読み解いてみよう」にイベント参加しました。2回目の参加となります。 前回の参加レポートはこちら。 スクラムガイド変わるってさ:「スクラムガイドを読み解いてみよう」に参加しました どのような会か スクラムガイドを読み、パーソナリティの皆さんが読んだ部分について議論されています。 Zoomで行なわれ、参加者もチャットから質問が可能です。 記事内容 本記事では、パーソナリティが話されていた内容と僕の感想や意見を織り交ぜて書いております。 今回のイベントで話されていたのはスクラムガイド「スクラムイベント」の章でした。 この記事では主に以下について主に書きます。 スクラムのスプリントのタイムボックスについて スクラムのスプリントゴールについて スクラムのスプリントの中止について イベントのタイムボックス スクラムの中心はスプリントである。これは、「完成」
『みんなで小さく区切ってやる』ガイド｜kawanotron
『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
ぼくらのスクラム奮闘記 - SmartHR Tech Blog
こんにちは、プロダクトエンジニアのa2cとプロダクトマネージャーのdaisukeです。 本稿では、2024年1月に組成され、スクラムを採用した私たちのチームが最初の3ヶ月間に直面した課題とその改善策、それによってもたらされた変化を共有します。スクラムに参加するエンジニアとPMの多様な視点を取り入れ、実際の経験に基づく具体的な事例をオープンに紹介します。 なお、この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。ぜひ他の記事もご覧ください。 チームの紹介 PM1名・プロダクトエンジニア3名の計4名がコアとなり、価値提供に責任を持ちます。そのコアチームに兼任のプロダクトエンジニア(チーフ)1名・兼任のプロダクトデザイナー1名が加わりチームを構成しています。専任のスクラムマスターはいません。 担当しているプロダクトとプロジェクトは、SmartHR Plu
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
GitHub Projectsを使った（プロダクト/ スプリント）バックログ管理 #スクラム | DevelopersIO
★ はGitHubによって作られるものです。 以降、ビュー名はアルファベットで表記します。 New Item Product Backlog Item (PBI)候補の新アイテム一覧を表示します。新アイテムはリファインメントの度に確認され、Product Backlogへ移るため、本ビューは空が基本の状態となります。 クエリ no:size -ready:"Drop" Product Backlog PBIの一覧を表示します。優先順位順に並んでおり、プロダクトオーナーの合意の下で並び替えを行うことができます。 クエリ is:open -no:size -ready:"Drop" Sprint Backlog 今スプリントの対象となっているPBIとその進行状況を表示します。 クエリ sprint:this レーン概要 statusカラムの値ごとに整理されます。 TODO 進行中ではないアイテ
デイリースクラムの進め方
みなさんこんにちは、@ryuzeeです。 今日はデイリースクラムについて、概要や注意点を紹介します。 なお、あくまで一般論であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 1. デイリースクラムの目的 2. デイリースクラムの参加者 3. デイリースクラムのタイムボックス 4. デイリースクラムの事前準備 5. デイリースクラムのファシリテーション・進行 6. デイリースクラムのアンチパターン 1. デイリースクラムの目的 スクラムを利用するとき「フレームワークで決められているから」というだけの理解で進めてはいけません。これは全てのイベントに当てはまります。 スクラムのイベントはすべて、検査と適応が行われるように明確に設計されています。 デイリースクラムの最大の目的は、
意識も理想も高いけど実現には至れない人｜FromAtom
これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの
スプリントレビューの進め方
みなさんこんにちは、@ryuzeeです。 スクラムにおいてはフィードバックが重要です。プロセスに対するフィードバックはスプリントレトロスペクティブ、プロダクトに対するフィードバックはスプリントレビューを活用します。 今日はスプリントレビューについて、一般的な手順や注意点を紹介します。 なお、あくまで一般的な手順であることに注意してください。スクラムの基本は「透明性・検査・適応」です。自分たちで随時やり方を検査して、もっとうまくできるように適応していかなければ効果はあがりません。 スライドはこちらをご参照ください。 1. スプリントレビューの目的 2. スプリントレビューの参加者 3. スプリントレビューのアジェンダ（例） 4. スプリントレビューの事前準備 5. ステークホルダーへの質問（例） 6. 良いスプリントレビューの特徴 7. スプリントレビューのアンチパターン 1. スプリントレ
「プロダクトオーナーが誰かわからない」「うまくいっている気がしない」 “失敗しないアジャイル導入”のカギとなる「理解の共通化」
「プロダクトオーナーが誰かわからない」「うまくいっている気がしない」 “失敗しないアジャイル導入”のカギとなる「理解の共通化」 Agile Center of Excellenceの必要性を考える中で自身のアジャイルを再構築する #1/2 登壇者の自己紹介とアジェンダの紹介 島崎純一氏：よろしくお願いいたします。本日は、Agile Center of Excellenceの必要性を考えるといったところから、自身のアジャイルを再構築するというお話をいたします。 お話の前に、本セッションの注意点を共有させていただきたいなと思います。 本セッションは、Agile Center of Excellenceをキーワードにお話ししますが、A-CoEの成功例ではなくて、そのお話に至るまで、自分のアジャイルを企画の観点から見直したというセッションです。 本日のスピーカーの紹介といったところで、私、島崎純一
上下関係を大切にする官公庁内でアジャイルを浸透させるために 「改善の繰り返しを許容する組織」を作る上で工夫したこと
GovTech東京 エキスパートの杉井正克氏と東京都デジタルサービス局の下家昌美氏が、東京都庁でアジャイルを実践するための「都庁アジャイルプレイブック」を紹介しました。前回はこちら。 体験してもらえないとアジャイルの良さはわからない 杉井正克氏（以下、杉井）：最後にご紹介させていただくのは体験からの反応です。2022年にプロジェクトを4つやったのですが、プレイブックには参加されたみなさんのインタビューが載っています。（スライドを示して）こういうかたちで気づきや学び、「こういうのが楽しかったです」みたいなところとか、満足度を掲載しています。 これを抽出すると、「やってみたらわかりました」とか「実際に開発を進めてみて」とか「実際の会議の中で意見交換をして」みたいなことがけっこうコメントとして上がってきたのがおもしろくて、気づきだったなと思っています。 良さを体験してもらえてよかったなというとこ
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
「『50%の時間を技術的負債返済に』はぜんぜん駄目だった」 カミナシ社・原トリ氏が語る、試行錯誤の過程
「負債にも50パーセントの時間を使ってください」は機能しなかった 西村賢氏（以下、西村）：最初にやったことに価値がありました。そして、次は第2段。 原トリ氏（以下、原）：この説明会やった時に、6月は一回止めますと（話しました）。完全に機能開発を止めて、サポートから流れてくるチケットに関してはオンコール体制を組んできちんと対応するけれど、機能開発はしないというのを戦略として……。 西村：これ、カミナシの歴史で初めてですね。 原：たぶん、初めてだと思います。 西村：そこは「大丈夫なのかな？」とかなかったんですか？ 原：「この1年大きい機能、出てないよね？」みたいな共通認識は、全社にあったから経営の中で意思決定が早かったんです。 西村：なるほど。なにか技術的にうまくいっていないというのがあった。 原：そうです。プロダクトがうまくいっていないという認識がまず全社にあって、かつ、これがカミナシの底力
「ウオーターフォール」が好きな企業、「アジャイル」に失敗する企業の特徴
関連キーワード アジャイル | 開発プロセス 代表的なシステム開発手法として、上流工程から下流工程へと順番に開発を進める「ウオーターフォール」型開発と、小規模な変更を短期間のうちに繰り返す「アジャイル」型開発がある。 従来、企業が採用する開発手法としてはウオーターフォール型が主流だったが、近年では“アジャイル移行”に目を向ける企業の動きが広がる。その背景や、移行で企業が直面する課題について解説する。 ウオーターフォールを好む企業、アジャイルに失敗する企業 併せて読みたいお薦め記事 連載：2大開発手法を比較 前編：いまさら聞けない「ウオーターフォール」と「アジャイル」の基本的な違い 中編：「ウオーターフォール」ではなく「スクラム」との相性が良い開発とは？ アジャイルに関する記事 アジャイル型開発の「カンバン」には“あれ”がない？ スクラムとの主な違い アジャイルの次に考えるべき「プロダクト思
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ipa.go.jp/digital/hjuojm000000gwoo-att/000065606.pdf
経験に複利を効かせろ！ふりかえり研修2024
アジャイル勘違い集 (2024) | Agile Studio
大規模なアジャイル開発の現場と技術負債 / Technical Debt
