えぇ！？はじめてのスクラムマスターでも新卒研修で最高のスクラムチームを作れるようになれるって本当ですか？ | BLOG - DeNA Engineering
スクラムチームの構成 私たちのスクラムチームは以下のような構成で開発を行いました。 開発者 4人 プロダクトオーナー 2人 スクラムマスター 1人（私） プロダクトオーナーが2人というのは通常のスクラムで考えるとあまりないのですが、今回ビジネスサイドから参加したメンバーが通常業務との兼任だったため、なかなか時間を割きにくいという特殊な事情もあり、このような体制をとっていました。 スクラム開発で起こった問題 「スクラムわからん」 これが僕たちのチームに最初に立ちはだかった、最大にして最難関の壁でした。 スクラムの講義やスクラムガイドに目を通しただけではスクラムを理解することは難しく、何を取り組むにしても「これはスクラムのやり方に則っているのだろうか？」という疑問にぶつかってしまい、みんながモヤモヤしているし、物事も前に進まないということがスプリント1では起きていました。 スプリント1のスプリ
Warning: Undefined array key "footer-widget-center-2" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 190 Warning: Undefined array key "footer_widget_copyright" in /home/nagasawa/servantworks.co.jp/public_html/wp-content/themes/emanon-premium/inc/template-cache.php on line 213
｢顧客起点｣のアジャイル開発をめざして トライアンドエラーで生まれたチームの変化とは - パナソニック コネクト
――具体的にどのようなソリューション開発にアジャイルの手法を取り入れているんでしょうか？ 森：最近の例でいえば、倉庫や物流拠点で使われるヤードマネジメントシステム（YMS）ですね。｢積荷を運搬するトラックが敷地内で無駄な移動をしたり、指定とは違う停車場に駐車したりすることで、タイムロスや冷凍品の劣化が発生している｣という相談をアメリカの物流会社からいただきました。その問題を解消するために、カメラでトラックの動線を検知したり、物体検知技術を応用したり……と、どんな技術がお客さまの課題解決につながるのか、アジャイルで探っているところです。 先日現場にカメラを設置したのですが、その際には画像認識技術の研究開発を行っているメンバーにも同行してもらい、お客さまからいただいたフィードバックをその後の研究開発に役立てています。不確実性が高く、現場に必要なソリューションを定義しづらい今の時代には、先進技術
デザイナーの帽子をかぶりながら、チームとの関わり方を考えつづけている話/How does a designer fit in a Scrum Team?
スクラムフェス大阪2023登壇資料 プロポーザル：https://confengine.com/conferences/scrum-fest-osaka-2023/proposal/18545
その人の人生を狂わせるくらいの巻き込む能力が必要 吉羽龍太郎氏（以下、吉羽）：2つ目の「ヒトを巻き込む」という話も出ました。このペースでしゃべったら絶対終わらないので、そろそろ次のテーマにいきたいと思います。 次が今、及川さんから振りがあった、「ヒトを巻き込む覚悟」ですね。ちょっとこっちについて話していきたいと思うんですけど。 これもいろいろな話がありますよね。人といっても、自分のチームのメンバーも人じゃないですか。それから、ステークホルダーも当然巻き込む対象になってくると思うんですけど。 ユーザーに関しては、下で触れようと思うので1回置いておいて、チームとステークホルダーという観点でいうと、どんな覚悟が必要ですかね？ 及川卓也氏（以下、及川）：人の人生を狂わせちゃうかもしれないわけで。 吉羽：（笑）。 及川：スタートアップは、「俺の会社でこのプロダクトを作って世界を変えようぜ」と言って、
顧客、ユーザーの片側だけにアプローチをしているケースが多い 吉羽龍太郎氏（以下、吉羽）：あと15分ぐらいみたいなんですけど、あと2つですかね……あっ、3つだ。「ユーザーを巻き込む覚悟」「未完成なプロダクトを人に使ってもらう覚悟」「プロダクトや機能を終了する」という話にいきたいと思います。 触れているところもだいぶ多いと思うので、ちょっと順番にいきたいと思います。ここまでは人を巻き込むといっても、ステークホルダーやチームメンバーという話でした。今度はユーザーというところにいきたいと思います。 顧客とユーザーは意外と混同されがちですよね。顧客とユーザーは、toBかtoCかによってけっこう変わってきますけど、これはどういうふうに考えるといいんですかね？ お金を払ってくれる人はもちろん大事だし、使ってくれる人も大事。ここでは、ユーザーを巻き込むと言っているんですけど、お金を払ってくれる人はそれなり
チームのメンバー変更が良い機会だったので、スクラム改善を進めた話 - クラウドワークス エンジニアブログ
crowdworks.jpでEMをしている久村です。 2023年5月より1つのチームのスクラムマスターをすることになりました。 私は開発者としてスクラムの経験はありましたが、スクラムマスターの経験はなかったです。 この記事では、直近チームで改善したことの内容と、そこからの学びを記事にしようと思います。 チーム説明 私がスクラムマスターとして関わっているチームは以下です。 エンジニアメンバーの異動・退職があり人数が減少し、プロダクトオーナー（PO）もメインとサブ（入社年次が浅い）で2名いましたが、サブの方が独り立ちしてメインで担当されるように変更になりました。 そのタイミングでスクラムマスターとして私がメンバーに加わりました。 メンバー変更した当初の状況としては、1週間のスプリント期間で以下のスクラムイベントは実施しておりました。 デイリースクラム リファインメント レトロスペクティブ プラ
正しいものを正しくつくる 不確実性を飼い慣らす 〜 アンチフラジャイル型プロダクトマネジメント 〜 Ichitani Toshihiro 市⾕聡啓 Toshihiro Ichitani All Rights Reserved. 市⾕ 聡啓 Ichitani Toshihiro 「正しいものを正しくつくる」⽀援、 「組織を芯からアジャイルにする」⽀援 (株式会社レッドジャーニー) 特に専⾨は 「仮説検証、アジャイル開発、組織アジャイル」 過去のスライド https://www.docswell.com/user/papanda Toshihiro Ichitani All Rights Reserved. 2 https://www.docswell.com/user/papanda
これらの数値は、数多くの開発チームを分析しクラスタリングした上で、ハイパフォーマーの特徴として抽出されたものです。ここでの重要な問いとして、「Four Keysといった数値を高めたら、自分たちが目指す強い開発組織の状態になるのか？」というと答えは、NOです。 特に開発生産性の可視化は、管理や監視のために測定するのはアンチパターンで自分たちのケイパビリティー向上のために使わなければ、逆効果になるケースもあります。よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です。自分たちのために計測していれば極端にハックする意味がないことは明白ですが、開発生産性を存在価値のために数値を提供すると、ある事象が起きやすいので気をつけたいところです。 こういった事象を「グッドハートの法則」と言います。または「キャンベルの法則」という類似の法則もあります。どちらの法則も、組織や制度
タスクマネジメント_基本編 | ドクセル
レッドジャーニー(https://redjourney.jp/) 所属のアジャイルコーチ 元ギルドワークス 所属 様々な規模のSIerでのシステム開発を経て今に至り、約10年で40の組織、80のチームを支援している。 「ええと思うなら、やったらよろしいやん」を口癖に、社内のみならず社外のチームがより良くなるお手伝いなど日々活動中。 ・認定プロフェッショナルスクラムマスター(CSP-SM) ・認定プロダクトオーナー(CSPO) ブログ：サウスポーなエンジニアの独り言
決済プロダクトのマジ価値を最速で届けるためのバックエンドQAの事例 - freee Developers Hub
こんにちは、freeeで決済プロダクトのQAエンジニアをしているrenです。freee QA Advent Calendar 2023 - Adventarの11日目です。 この記事では、決済プロダクトでアジャイルQAを実践するために取り組んでいる、バックエンドQAの事例を紹介します。 決済プロダクトで取り組んでいるアジャイルQA 決済プロダクトの開発はスクラムで行なっており、QAを含むOneTeam*1で行っています。 そのため、QAエンジニアもスクラムイベントに出ており、開発と併走できるQA活動を目指して日々仕事に取り組んでいます。 このようなQA活動をfreeeではアジャイルQAと呼んでいます。詳細な経緯や意図については、ymty-sanの記事を参照ください。 developers.freee.co.jp スクラムのイテレーティブな開発にあわせてイテレーティブにアジャイルQAを行うこ
スクラム知識0のチームが3ヶ月スクラムを回してみたらめちゃくちゃ良かった話 - freee Developers Hub
こんにちは Enabling SRE team(通称hayabusa)に所属しているSREのchoreです！ この記事はfreee Developers Advent Calendar 2023 - Adventar 2日目です。 内容としてはスクラムが右も左も分からないチームがスクラムを回していってどうなったかを書いています 対象読者 チーム運営が上手くいっておらずスクラムってどうなん？って思ってる人 話さないこと スクラムについての基本的な知識の説明 話の結論 まずはスクラムガイドに従ってセオリー通りにスクラムをしてみて、上手く行かないと感じた部分はスプリント終わりの振り返りで改善していこう！ 定期的にスクラムチームの成熟度がどうなっているかを検証するフローを組んでいこう！ スクラムはいいぞ〜〜〜 背景 Enabling SRE team*1が発足したのは今年の7月からで、4~5人のS
アジャイル勉強法
Next.jsとKtorとLaravelの周辺知識について書きます。最近は「負債になりにくい設計」「どうすればアプリケーションの品質を高められるか？」「どうすればアプリケーションを安定かつ安全かつ効率的に動かせるのか？」に関心があります。 アイコン▶︎Twitter@amon_mikio。
スライド概要 書籍「組織を芯からアジャイルにする」を補完し、拡張する内容です。こちらはMVP版です。Full版はスライド末尾に案内を載せました。
「解像度をあげる」とは、より見分けられるようになるということだ。同じようなものと捉えていたことを明確に区別できる。理解の「密度」が高くなる。だから、言葉でより説明ができるようになる。 それはただ単に細かいことをあげつらうということではない。区別できるようになった上で、さらに統合する。共通するところと、異なるところを比較して、区別する前の「全体」として言えることをまた生み出す。個別だけではなく、全体として解釈できるようにする。 このことを前提として何を言いたいかというと、「つくる」ということについてだ。具体的には、ソフトウェア開発とプロダクト開発は、未分化のまま捉えることもできるし、明確に区別することもできる。 思えば、仮説検証型アジャイル開発（正しいものを正しくつくる）とは、ソフトウェア開発（業）が育ててきた前提、認識を、プロダクト開発に移行するための手立てとも見ることができる。 ここで、
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
現代社会は多くのものがソフトウェアで成り立っており、絶えず変化するニーズに応じられる柔軟でスピーディな開発が求められている。その一方、何が正解（ゴール）なのかがわからない、という不確実性の時代でもある。不確実性に対処するには「アジャイル開発」が最も有望だが、その成功裏の実践には、従来の常識の解体と再構築が必要である。アジャイル開発の実践方法を、理論、課題、動向も踏まえ、実例を交えながら幅広く解説する。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Santiago on X: "Scrum is a cancer. I've been writing software for 25 years, and nothing renders a software team useless like Scrum does. Some anecdotes: 1. They tried to convince me that Poker is a planning tool, not a game. 2. If you want to be more effi
リーダーのための「スクラムガイド」手引き | サーバントワークス株式会社
「チームの理想の状態は“巻き込み巻き込まれ”になっていること」 及川卓也氏が語る、プロダクトマネージャーの「ヒトを巻き込む覚悟」
「自分がセールスとなってプロダクトを売り込めますか？」 プロダクトマネージャーが営業のマインドセットを持つべき理由
不確実性を飼い慣らす 〜アンチフラジャイル型のプロダクトマネジメント〜 | ドクセル
生産性が低いチームを強くするには？ うまく成長するための「順番」がある
組織をシンからアジャイルにする (MVP Edition) | ドクセル
「つくる」の解像度をあげる｜市谷 聡啓 (papanda)
品質コミュニティがつなぐ、QAチームと開発者の新たな可能性
不確実性の時代に、アジャイル開発で向き合っていこう - ZDNET Japan