Author: Jurgen Appelo In the Agile community, there’s a common misconception that agility exclusively involves iterative, incremental delivery, and anything else is dismissed as “waterfall.” However, my Agile Quadrants picture shows a broader spectrum of agility. While not strictly adhering to “hard agile” principles, many products employ “soft agile” approaches, involving feedback cycles through

アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお

初代iPhoneは発売時、今では当たり前のスマホ機能である「コピペ」を実装していなかったことはよく知られていますが、実際に開発を担当していた元Appleエンジニアが今になって、なぜ機能を盛り込めなかったのかをソーシャルメディアで明らかにしました。 他にやらなければならないことがありすぎた？ 元Appleエンジニアで、iPhoneの自動修正を発明したケン・コチエンダ氏（@kocienda）は、初代iPhoneでコピペが使用できなかった理由を下記のように述べています。 初代iPhoneにカット/コピー/ペーストがなかったのは悪名が高いですよね！その理由を手っ取り早く言えば、ちゃんと取り組む時間がなかったからです。キーボード、自動修正、テキストシステムなど、やらなければならないことがたくさんあったのです。デザインチームにも時間がありませんでした。そのため、1.0ではこの機能を見送ることになったの

ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されました。 268% Higher Failure Rates for Agile Software Projects, Study Finds - Engprax https://www.engprax.com/post/268-higher-failure-rates-for-agile-software-projects-study-finds 268% higher failure rates for Agile software projects • The Register https://www.theregister.com/2024/06/05/agile_failure_rates/ 今回の調査はコンサルタント会社「

機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため

ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア

ヤバい、大盛況に終わったRegional Scrum Gathering Tokyo 2024についてのブログも書かぬまま2月も終わりそう！ いろんな人がブログを書いてくれていたりするので、まずは世間の反応を眺めておいてください……。 そのうち書きます。 ところで先日Agile PBLについて取材を受けたのですが、そのインタビュー記事がUZABASEさんのWebメディア「Agile Journey」に掲載されましたのでご紹介します。 agilejourney.uzabase.com ブログで書き散らしたりイベント登壇で話したり、インタビュー中でも放談したりと、そこらじゅうに散らかっていた話がプロの手によって綺麗にまとまりました。 はてな編集部の毛利さん、インタビューしていただいた初瀬川さん青山さん、どうもありがとうございました！ インタビューにあたっては、わたしは大学のPBL教育についての

TL;DR時間がないので大規模アジャイルのヘルスメトリクスだけ手っ取り早く知りたいという方のために、メトリクスは以下です。 ちょうど１スプリントよりも長く存在するバックログの量エンドユーザーが追加説明なしで理解できるプロダクトバックログアイテムの割合開発者1人あたりの1日のコミット数トランクへ直接コミットする割合スプリントで選択されたPBIのうち、前回のスプリントレビュー前には存在しなかったPBIの割合スプリント終了時の着手済みの未完了アイテムスプリントごとに進行中の祖先全チームがオフィスにいる週の日数完成の定義メトリクスを見て興味が湧いた方はぜひ続きを読んで見てください。 大規模アジャイルのヘルスメトリクスについて語る目的講演の中で、通常は特定の指標については話していない、メトリクスに関する組織のダイナミクスと、メトリクスが組織内でどのように使用されているかに興味があるからだと言っていま

この記事は "Regional Scrum Gathering Tokyo & Scrum Fest Advent Calendar 2023" の1日目の記事です。 わたしがAdvent Calendarを立てたので言い出しっぺが1つ目の記事を書きます。 現時点で空きがあるのでぜひエントリーしてね。 adventar.org Global Scrum Gathering参加レポート 10月にオランダのアムステルダムで行われたGlobal Scrum Gathering 2023に参加してきました。 www.gsgams23.com 他にも参加レポートがあった気がしたんだけど、軽く検索したぐらいだとこれぐらいしか見つかりませんでした。ごめんなさい。 Global Scrum Gathering 2023 Amsterdamに参加してきました #gsgams - yudmoのブログ 時間が過

アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分

夜中におもむろに書評を書き出す第2段。 日本企業はなぜ「強み」を捨てるのか～増補改訂版『日本“式”経営の逆襲』～ (光文社新書) 作者:岩尾 俊兵光文社Amazon この本自体はとても面白いし首肯できる部分も多いが、1箇所だけイチャモンをつけたい。 そもそもアジャイルソフトウェア開発という概念自体、マニフェスト（注：アジャイルソフトウェア開発宣言のこと）の発表よりも3年早く、1998年に日本の研究者から提案されている。 南山大学の青山幹雄教授による一連の研究である。 （同書より引用） ここで紹介されている「1998年」の「提案」とは、おそらくICSE1998で青山先生が発表した論文 "Agile Software Process and Its Experience" のことだろうと思う。Agile Software Process（ASP）という、実際に富士通の社内で実践されたソフトウェ

私は牛尾剛と申します。米国でマイクロソフトのクラウドを開発するソフトウェアエンジニアをしています。私は過去にははてなで、今は note でブログを書いていますが、幸いなことに沢山の方々に読んでいただけることが多く、文藝春秋の山本さんから提案されてこの度本を出版させていただくことになりました。新著はブログの文章に大幅加筆をしてビジネス書として一から構成したものですが、背景にある思いをお伝えしたいと思います。今回は私がなぜこのようなブログ、そして書籍を書いているのかをブログに書いてみたいと思います。 実は自分にとってはブログや書籍を書いている理由はもしかすると自分の「復讐」かもしれません。とは言えこの「復讐」は日本で働くことがもっと楽しく、もっと幸せで、そしてプロダクティブになるようなポジティブな「復讐」です。 「のび太くん」みたいだった私　私は子供の頃から、運動も、勉強も何もかもできなくて自

『SCRUM BOOT CAMP THE BOOK』ベトナム語版の出版社であるクアンバンブックス（Quảng Văn）とアジャイルアカデミー（Học viện Agile）共催のトークイベントに出ました！*1 慣れないベトナム語で話してます！ というのは嘘で、英語で話してます。 わたしの発言にはベトナム語の字幕をつけてくださったので、お近くのベトナム人にも広めてください。 www.youtube.com アジャイルそのものというよりスクラムの適用や日本とベトナムのプロジェクトマネジメントの違い、とかが話題だったのですが…… “Scrum is a flexible solution in project management”. As the author of this book, what do you think about this assessment? （「スクラムはプロジェク

韓国語版が出たのは以前書いたとおりですが、その後、台湾語（繁体字）とベトナム語版が出版されました🎉 ロケールが日本だとググっても出てきづらく、わたし自身いつもリンク先探しで手間取るので、出版社のリンクをまとめておきます。 チームに母国語が異なる人がいたらぜひ紹介してあげてください。 韓国語版 출근했더니 스크럼 마스터가 된 건에 관하여 - 예스24 台湾語版（繁体字版） SCRUM BOOT CAMP｜23場工作現場的敏捷實戰演練 ベトナム語版 Trại huấn luyện Scrum | Quảng Văn つい先日ベトナムのトークイベントにも出演したのですが、その話はこちらから。 miholovesq.hatenablog.com SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 作者:西村 直人,永瀬 美穂,吉羽 龍太郎翔

本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している

Gunosy Tech Lab の石川です。 この記事は Gunosy Advent Calendar 2022 の 8 日目の記事です。昨日の記事は今村さんの『EventBridgeとECSでお手軽バッチ処理基盤 (後編)』でした。 最近リモート環境でモブプログラミング開発をチームで行っているので、今回はそのベストプラクティスの一例に触れながら、どのように行い、どのような影響があったかを書きたいと思います。 概要 モブプログラミングとは リモートモブプログラミングのベストプラクティスの一例 チームでの実践 独自のルールや実践例 mob コマンド 課題 まとめ 概要 2020 年始めの COVID-19 の流行拡大以降、在宅勤務の導入が多くの企業に広まりました。Gunosy でも同年の 2 月頃から在宅勤務が導入され、現在でもスタンダードな働き方として継続しています。 そのような状況下で、

プロダクトに備わる機能の64%がほとんど使われないと言う。あるいは、80%という数字が用いられることもある。これが本当だとすれば、ソフトウェア開発に費やしたコストの多くが無駄だったことになる。ソフトウェア開発は常にスピードが求められるものだが、そもそもこのような無駄がなければ、ユーザーや顧客への価値の提供をもっと速くできたはずだ。 ソフトウェプロダクトをローンチし、それから次々とリリースを繰り返しながら追加されていった変更は、いったいどれだけのものが実際に価値があったのだろうか。本稿では、Standish Groupやマイクロソフトの文献を中心に、ヒントとなる数字をいくつか紹介し、その理解を深める。 64%はめったに、あるいはまったく使われない 80%は価値が低い、あるいはまったくない 3分の2は価値がない、あるいは逆に価値を損なわせる 「勝利宣言」からの脱却 64%はめったに、あるいはま