本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
ユーザーストーリーマッピング
JaSST 23 Tohoku https://www.jasst.jp/symposium/jasst23tohoku.html
アジャイル開発で役立つセキュリティプラクティス / Agile Security Practice
RSGT2024の発表資料です！
「こうしてスクラムが終わってしまう」前にすべきこと
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
「私考える人、あなた作業する人」の関係をつくっているのはあなたかもしれない
Regional Scrum Gathering Tokyo2023 の中の moyiyuya さんの「私考える人、あなた作業する人」というセッションが大きな反響を呼んでいました。 スクラムを導入してチームとして一体感をもってプロダクト開発をよりうまくやっていきたかったはずなのに、いつの間にか「私考える人、あなた作業する人」という関係性ができてしまっていた、という相談を受けることがあります。 なぜこのような「私考える人、あなた作業する人」という関係性が生まれてしまうかについて、コミュニケーションの観点で考えてみます。 プロダクトオーナーと開発者の堺目 「私考える人、あなた作業する人」のような関係性が生まれてしまっているチームでは、開発者からプロダクトオーナーに対するコミュニケーションが以下のようになっていることが多いです。 プロダクトバックログを出してくれたらつくります 仕様を決めてくれた
私がもはやベロシティについてほとんど話さない理由
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
プロジェクトのスコープ調整を考える - 開発チームが信頼を獲得し変化に対応するためのアプローチ - Agile Journey
日々、懸命に開発にあたっていても、スコープ調整は否応なく発生します。Agile Journeyの読者の方も、「予定していた機能開発を削らないといけない」と判断せねばならない経験をお持ちかもしれません。こうした判断をネガティブなものではなく、「変化への対応」と捉えて前向きにプロジェクトを進めるためには、なによりも信頼が必要、と語るのは、10年以上、アジャイルコーチとしてさまざまなチームに関わってきた安井 力さんです。安井さんが信頼を積み重ね、「変化に対応できる」チームになるために必要なことを解説してくれました。 プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールや
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
スプリントの振り返り大全 〜 チームに最適な手法を見つける15のレトロスペクティブを振り返る - Agile Journey
はじめまして。株式会社イノベーター・ジャパンでフロントエンドエンジニアをしている、うじた（@besburg）です。弊社ではスクラムによる開発を取り入れており、スプリントの最後には毎回スプリントレトロスペクティブという振り返りを行っています。そこで試した振り返りの手法をこの記事ではまとめてみました。 私たちのプロジェクトではタスクの優先度に入れ替わりが多く、今やっていることを可視化するため、2021年8月からスクラムを開始しました。参加メンバーは各プロジェクトのエンジニア全員で、スプリント期間に合わせて1週間ごとに振り返りを行っています。スクラムによる開発が初めてだったこともあり、当初は自分たちに合った手法を見つけることを目標に振り返りを進めました。 週ごとにメンバーが交代でファシリテーターを担当し、試したい振り返り手法を持ち寄ってレトロスペクティブを行いました。そのため基本的には振り返り手
振り返り時間の雑談っていらなくないですか？ - Qiita
はじめに 筆者は初めてアジャイルの開発でスクラムを経験。3ヶ月が経つ。 今回チーム内で出た意見を元に、良い気づきを得ることができたので記事にまとめました。 ★フルリモート環境 ★バックエンドとフロントエンドでチームが分かれている ★私を含む新規参画者はスクラム初心者 ★バック、フロントそれぞれスプリントの振り返りが終わった後、 スクラムチーム全員で共通の振り返りという名の雑談タイムがある。（30m～） 雑談の時間っていらなくないですか？ この議題があがり、スクラムチームの意見をいただきました・・・ 最終的な投票結果では、現状のままで良いという結論に至りましたが 雑談のメリット 改善案 新しい手法の提案 色んな気づきを得ることができたので記していきたいと思います。 この議題が生まれた背景 そもそも、開発状況が芳しくない。という所に 新規参画者の方が目をつけてくださいました。 『進捗率があまり
非アジャイルマニフェスト - kawaguti’s diary
「アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。 アジャイルはアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな？ agilemanifesto.org 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 これをひっく
新卒で飛び込んだフロントエンド刷新プロジェクトが学びだらけだった話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintone フロントエンドリアーキテクチャプロジェクト (フロリア) に所属している 21 新卒の西川 (@nissy_dev) と左治木 (@sajikix) です。 フロントエンド刷新プロジェクトへの配属から約 1 年が経ち、プロジェクトに関わる中で多くの学びがあったので振り返ってみました。 目次 自己紹介 西川です 左治木です kintone フロントエンドリアーキテクチャプロジェクト（フロリア）とは 配属されてみて実際どう？ プロジェクトから学べたこと 小規模なチームでのスクラム開発 Testing Trophy を意識した QA とのテスト設計 アクセシビリティを考慮した UI の開発 現在取り組んでいること いきなり刷新プロジェクトに配属されるのってどう？ チームに任された裁量が大きく、新卒でも技術選定やより良い設計の提案をしながら開発できる 新規開発した機能に
【資料公開】スプリントプランニング Deep Dive
みなさんこんにちは。@ryuzeeです。 8月26日に新刊『エンジニアリングマネージャーのしごと』が発売になったのでぜひよろしくお願いします。 2022年8月26日〜27日までスクラムのコミュニティイベントであるScrum Festが初めて仙台で行われました。 このイベントで「スプリントプランニング Deep Dive」というタイトルで話をする予定だったのですが、急遽体調不良となり、代わりに弊社の@miholovesqに登壇してもらいました。 ただ、資料をそのままにしておくのも勿体ないので、こちらで公開します。 スクラムガイドの複数回の改訂で、スプリントプランニングにも何度か変更が加わっています。 ところが巷のブログなどを読んでいると古い知識をベースにしていたり、特定のツールの従来からの仕様に引きづられた運用になっていたりするのを多く見かけます。 ということで、今回スプリントプランニングに
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
Agile and Requirement : アジャイルな要件定義について考える
アジャイルマニフェストとユーザーストーリーマッピングのお話です。
チームトポロジー を読んだ - 下林明正のブログ
必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす
チームのベロシティを上げる vs. 安定させる - yigarashiのブログ
タイトルの議論はよく見られるもので、スクラムコーチの間ですら（一見すると）意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「（安定させた上で）上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論- / #RSGT2023
スクラムと見積り
