見積もりをしない。2023/7/27 DMM石垣氏に聞く 見積もりをしない、コミュニケーション負荷を減らすスクラムの実践 https://offers.connpass.com/event/289979/
スクラムを導入してチーム状態を可視化し持続可能なチームを目指す - ZOZO TECH BLOG
こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。 チーム状態の可視化を考えたきっかけ リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。 そんな悩みを抱えていた時、全社に導入されているWevoxのアン
振り返り時間の雑談っていらなくないですか？ - Qiita
はじめに 筆者は初めてアジャイルの開発でスクラムを経験。3ヶ月が経つ。 今回チーム内で出た意見を元に、良い気づきを得ることができたので記事にまとめました。 ★フルリモート環境 ★バックエンドとフロントエンドでチームが分かれている ★私を含む新規参画者はスクラム初心者 ★バック、フロントそれぞれスプリントの振り返りが終わった後、 スクラムチーム全員で共通の振り返りという名の雑談タイムがある。（30m～） 雑談の時間っていらなくないですか？ この議題があがり、スクラムチームの意見をいただきました・・・ 最終的な投票結果では、現状のままで良いという結論に至りましたが 雑談のメリット 改善案 新しい手法の提案 色んな気づきを得ることができたので記していきたいと思います。 この議題が生まれた背景 そもそも、開発状況が芳しくない。という所に 新規参画者の方が目をつけてくださいました。 『進捗率があまり
30分で分かった気になるチームトポロジー
2. 吉羽 龍太郎 (@ryuzee) ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ Scrum Alliance ✤ 認定スクラムトレーナー Regional (CST-R) ✤ 認定チームコーチ (CTC) ✤ 『SCRUM BOOT CAMP THE BOOK』 『スクラム実践者が知るべき97のこと』 『みんなでアジャイル』 『プロダクトマネジメント』 『レガシーコードからの脱却』ほか ✤ @ryuzee / https://www.ryuzee.com/ 2 4. 今日の話: チームトポロジー ✤ 2021/12/1 日本能率協会マネジメントセンター刊行 ✤ マシュー・スケルトン、マニュエル・パイス著 ✤ 原田騎郎、永瀬美穂、吉羽龍太郎訳 ✤ 担当編集: 山地淳さん ✤ Kindle版もあります ✤ まだお持ちでない方、是非お買い求めください ✤ 本スライド掲載の図表は
勝手に注釈付き参考文献 | スクラムガイド日本語版
スクラムガイド2020からは、IT以外の分野にも適用してもらいたいみたいなので、ソフトウェアに特化したものはできるだけ排除する（とはいえ、なかなか難しいね） スクラムガイドでは「我々は1990年代初頭にスクラムを開発した」とあるので、まずは当時の状況を把握しておくとよさそう。おおざっぱに言うと、ソフトウェア業界的にウォーターフォールじゃダメだという雰囲気になっていて、何かいい方法がないものか……とみんなが模索していた時代。 そこで、過去の文献を遡り、当時でも使える概念が発掘された。それが、以下の竹内・野中論文である。Jeff Sutherlandはここから「スクラム」という名前を拝借しており、両名は「スクラムの祖父」と称される。 Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
プロダクトオーナーが最低限守るべき10のこと
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 とある同人誌に寄稿した原稿を知り合いに共有していたのですが、ブログでオープンにしてほしいという依頼を受けたので公開します（同人誌の発行者には許可を取っています）。 怪文書みたいなものですが、感想お待ちしております。 本稿で何を書こうか考えていたところ、Twitterで「これがNASA流の仕事術、「プロジェクトマネージャーが守るべきルール100」が公開される」 という2014年の記事を見かけました。書かれている内容はとても妥当なもので、プロジェクトマネージャーだけでなく、組織のリーダーでもプロダクトマネージャーでもプロダクトオーナーでもあてはまるものでした。 ただ問題は100個という数
フィーチャーチーム
フィーチャーチームは、“組織の既存の枠やコンポーネント等にとらわれず、多くの顧客 のフィーチャーを1つずつ完成させる長寿命のチーム” です。フィーチャーチームは、大規模開発でアジャイル開発を実践するために必要不可欠です。フィーチャーチームがなければ、（その代わりに、コンポートネットチーム、コード所有権に基づく、もしくは１つの機能に基づくグループ、アナリストグループ、プログラマグループ、テストグループ等に分類）あなたの組織は、結果的に逐次的開発サイクル（ウォーターフォール, ...）となり、非常に多くの無駄を生み出したり、部分最適化を行います。フィーチャーチームは、多く無駄を取り除くと同時に、変化と挑戦を求めます。 フィーチャーチームは大きなプロダクト開発で長期間、活躍します。例えば、テレコムシステム（Ericsson）やコンパイラ開発（Microsoft）等。フィーチャーチームが仕事
Regional Scrum Gathering Tokyo 2020のスライドまとめ #RSGT2020 - スクラムマスダーの日記
2020/01/08から、Regional Scrum Gathering Tokyo 2020（以下、RSGT2020）が始まりました！ 2020.scrumgatheringtokyo.org 本ブログでは、RSGT2020のセッションの発表資料をまとめています。 個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄などで教えていただけるとさいわいです。 現時点では、1日目のスライドのみです。 2日目まで追加しました！ 3日目まで更新しました。 1日目（2020/01/08） keynote The Ten Bulls of the Scrum Patterns Hall WEST アジャイルコーチ活用術 slide.meguro.ryuzee.com みなさんのプロダクトバックログアイテムはOutcomeを生み出していますか？ プロダクト生
#RSGT2020 テックリードは未来の話をしよう / Tech Lead in Scrum
https://confengine.com/regional-scrum-gathering-tokyo-2020/proposal/11890/tech-lead-in-scrum
DevLOVE Xのスライドまとめ #devlovex - 名前考えるの苦手
スピーカー60人超！？ 公式 セッション一覧 DevLOVE 新サイト 【Day1】 6/22 6/22 11:00-11:40 新井 剛 普通のエンジニアが10年でニュータイプやスーパーサイヤ人になれるのか？カイゼンさんのジャーニーの巻 松下 雅和スタートアップで培ったアーキテクチャ設計ノウハウ 横道 稔 「嫌われない」を諦めない 小田中 育生(おだなか いくお) ソフトウェア開発に最短経路はあるか 及部 敬雄【勝手に基調講演】アジャイルで目指した坂の上の雲 6/22 11:50-12:30 山口 鉄平 良い感じにイベント・勉強会を 開催するために意識していること 島川 悠太 スモール イズ タノシイデスネ〜小さく回して楽しい開発体験を得るための処方箋をいくつか ちゃちゃき エンジニアがUXデザインを学んでみた10年 篠原 徳隆 ゼロイチ人材の存在意義と生存戦略 中村 洋 「正しいものを
認定スクラムマスターになりました | おそらくはそれさえも平凡な日々
https://www.scrumalliance.org/community/profile/mmatsuki2 アトラクタ社の認定スクラムマスター研修を受け、テストも合格し、晴れて認定スクラムマスターとなりました。だからなんだというわけでもないですが、スクラムに関する交流や雑談などしたいとかあれば、ご相談ください。 受けたのは以下の研修で、Gabrielle Benefieldさんと原田騎郎さんが講師でした。 https://www.attractor.co.jp/info/csm-201905/ 比較的長年アジャイルやスクラムに関わってきたので、良い知識の再整理の機会になりました。ありがとうございました。 私とスクラム 意外かもしれませんが、僕はそれなりにアジャイルやスクラムを経験してきました。とはいえ、今の開発者が押さえておくべき技術分野の一つなので、人並みくらいかもしれません。M
スクラムチェックリスト by Henrik Kniberg @ crisp.se - kawaguti’s diary
注意: この記事より新しい版があります。 Henrik Kniberg氏のスクラムチェックリスト (http://www.crisp.se/scrum/checklist ) を日本語訳してみました。スクラムをうまく行えているかどうかのチェックになると思いますので、ご活用ください。（TracのWiki記法になっておりますが、いずれHenrikさんが元のppt形式に取り込んでくれるかも、です。） (2009/09/01) 原版のフォーマットをHenrikさんからもらいましたので、マージしました。 (元ファイルはGithub: http://github.com/kawaguti/Scrum-Checklist-Japanese/ に置いています) = the unofficial Scrum Checklist = * version: 2.1 (2009-08-17) * http://w
スクラムを1枚で説明する資料7選（2019年版）
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 スクラムの全体像を表す絵は多数出回っています。コーチングやトレーニングを生業にしている人であればだいたい何度も作ったことがあるのではないかと思います。 今日はスクラムの全体像を表す絵のうち、比較的新しいものをいくつか集めてみたので紹介します。 見出しの行か画像をクリックすると、それぞれオリジナルを公開しているページにアクセスできます。 The Scrum Framework Poster | Scrum.org ケン・シュエイバーが設立したScrum.orgのサイトで公開されているもの極めてシンプルなので汎用性は高い一方で、スクラムマスター、プロダクトオーナー、開発チームの記述がでて
スクラムマスターを雇う時に聞いてみると良い38個の質問をやってみた - 海と山が好き
スクラムマスターを雇うときに聞いてみると良い 38 個の質問をやってみた 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」というものがあり、昔から知っていたのだが、改めて自分で考える機会ということで書いてみた。 スクラムマスターを雇う時に聞いてみるとよい38個の質問 | Ryuzee.com ※ あくまで自分の経験に基づく考えなので、使えるかどうか（≒採用に値するかどうか？）はわかりかねます。 スクラムマスターの役割について Q. アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？ ツールやプロセスが大事ではないとは言っていない。あくまで比較の話。 ツールやプロセスは、チームが価値を生むまでの一連の作業に、より集中できる為に必要とされる場合がある。 「いつまでにスプリントが
「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみた
以前、スクラムマスターを雇う時に聞いてみるとよい38個の質問 を読んで面白そうだなと思っていたら、実際にこれに回答をする記事をちら見したので、読みたい衝動を抑えてまず自分で答えてみることにしました。回答したら @Ryuzee さんが点数を付けてくれると聞いて（言ってない）。 回答するにあたって、 「コンテキストに依る」は全てにおいてそうなので禁止問題に対するつっこみはなしを前提に真摯な態度で回答しました。 また、自分はここしばらくキレイなスクラム／スクラムマスターをやっていないので、基本的には「自分だったらどうする？」をベースに回答しているのと、スクラム／スクラムマスター前提の質問に対しては「転生したらスクラムマスターだった件」という気持ちで答えております。 答えてみてスクラムの復習にちょうどいいかもー！！ 復習じゃなくても「自分（たち）だったらどうする？」を考えながら回答していくことで、
スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみた
みなさんこんにちは。@ryuzeeです。 以前書いたスクラムマスターを雇う時に聞いてみるとよい38個の質問という記事に対して、自分も答えてみましたので、以下で紹介します。 なお、既に38個答えた勇者がいるのでこちらも併せて読んでみるとよいと思います。 「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えた@katzchang/回答-スクラムマスターを雇う時に聞いてみるとよい38個の質問それでは、行ってみましょう。 スクラムマスターの役割についてアジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？スクラムマスターの関与の度合いはチームの力量や規律の有無、外部との関係性などによって変わります。 チームが自分で解決できない大きな問題をかかえていたり、チームとして機能していなかった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Scrum Guide 2020 Update Commentary
「いそがしくて業務改善なんてムリ」は言い訳――残業頼みの採用チームを変えたのはスクラムだった | サイボウズ式
Scrum Framework.png - Google ドライブ
サイボウズの採用チームがスクラムを取り入れて改善した話
