tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっている所まで整理できたので解説します。更に、変化の時代、環境変化に対し、ハードウェア開発をどう進めるべきか？ いまどきの取り組みを現場の開発者たちの声と共にお届けいたします。本内容は、スクフェス三河「初代プリウスにみるアジャイル開発の要素と現代の環境での進め方について」の続編という位置付けになります。 / We will introduce passionate and occasionally candid discussions by the developers of our lege
Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している話
いぐぞー ✈️ 旅するプログラマー @igz0 旅とプログラミングをこよなく愛します。 アメリカ大陸🇺🇸を横断しました！！小学生からプログラミング→新卒SIer→Webに目覚め個人事業主兼会社員。テレビ出演経験あり。 Webサービス制作者。読書・IT関連を中心にツイートします！！ネタツイート有。アイコンは@ixy先生に利用許諾済み。Amazonアソシエイト参加。 note.com/igz0/ いぐぞー ✈️ 旅するプログラマー @igz0 Microsoftの専門家「ウォーターフォールは一切メリットがないのでやめておきなさい」 > アメリカでは、アジャイルやスクラムの進め方が「常識」としてソフトウェア開発の場で浸透している これマジ？？ 日本のIT企業が、米国では「時代遅れ」のウォーターフォールを未だに信奉してるってコト！？ pic.twitter.com/jRofJKmAKM 202
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が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/ 今回の調査はコンサルタント会社「
アジャイルでも、ウォーターフォールでもない。リクルートの新決済システムは「異色のコラボ」で作られた - はてなニュース
アジャイル・スクラム開発とウォーターフォール開発──開発手法を巡ってしばしば対立項に置かれるこの二つのスタイルは、考え方はもちろん、段取りやマネジメントの方法もまるで異なります。そんな全く異なるスタイルをとる二つのチームがコラボレーションし、開発プロジェクトを推進していくことは現実的に可能なのでしょうか？ そんなコラボレーションを、決済というミッションクリティカルな領域で実現し、新たなシステムのリリースにこぎ着けた実例がリクルートにはあります。 英語や英会話の学習を支援する『スタディサプリENGLISH（以下、スタサプENGLISH）』では、今や主流となりつつあるサブスクリプションモデルに決済システムが対応できていないという課題がありました。そこで、決済・金融関連のシステムを開発するチームと共同で、新たな決済システムの開発に取り組みました。 『スタサプENGLISH』のチームは、内製の開発
トヨタはハードウェアアジャイルをどう強みにしているか？ 自動車開発におけるスクラムとモブの実践 - Agile Journey
アジャイル開発に関心がある人にとって、トヨタ自動車と聞いてすぐ思い浮かぶのは「TPS（トヨタ生産方式）」でしょう。 かんばん、ジャスト・イン・タイム、リーンなど、そのクルマ作りにおける考え方は多くのアジャイル開発手法の源流にもなっています。 一方、現代のアジャイル開発が主眼としているのは、変化への迅速な適応が求められるソフトウェアシステムの開発です。 自動車やその部品（ユニット）のようなハードウェアを開発する際の手法としてアジャイル開発手法を採用するケースはまだ決して多くありません。 そのような中、トヨタ自動車のエンジンを含む駆動系の技術開発を担うパワートレーンカンパニーでは、アジャイルなハードウェア開発への取り組みを2021年ごろから本格的に進めています。 さらに2023年9月のスクラムフェス三河や、2024年1月のRSGT 2024（Regional Scrum Gathering T
1. アジャイルについて マネージャーが知るべき 97 のこと 株式会社アトラクタ 取締役CTOアジャイルコーチ 吉羽龍太郎 (@ryuzee) 2. イントロダクション 吉羽龍太郎 / YOSHIBA RYUTARO ▸ アジャイル開発、DevOps、クラウドコンピューティング、 インフラ構築自動化、、組織改革を中心にオンサイトでの コンサルティングとトレーニングを提供。著書訳書多数 2
受託開発におけるアジャイルに限界を感じた私が、「納品のない受託開発」を始めるまで - 倉貫義人の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社ソニックガーデンの代表をしている倉貫義人と申します。 私はもともと大手システム会社でプログラマとして働いていました。そのとき出会ったアジャイル開発に魅了され、これこそ自分にとって理想の姿であると確信し、それ以来アジャイル開発を広めるための様々な活動を社内外で行ってきました。 最終的に、本当に自分の理想とするソフトウェア開発と、それを実現する組織をつくるためには、自ら会社を経営する立場になるしかないと考え、起業することになりました。そうしてできたのが株式会社ソニックガーデンです。 ソニックガーデンでは「納品のない受託開発」というサービスを提供しています。従来的な受託開発から、そもそものビジネスモデルを見直したことで、今では「アジャイル開発」を意識せずとも、自然とそれに取り組める組織として機能しています。 思い返すと、私のアジャ
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
DXの流れも相まって、アジャイル開発に取り組む会社が増えてきています。自社にも取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことありませんか？正しいアジャイルって...
アジャイルの「理論」や「理想」だけではない、 実際に実践したからこそ見えてきた「現実」に役立ったヒントを紹介したのは、マネジメントソリューションズ社の渡会氏。「Rebuild our Agile!」をテーマに掲げた「Agile Japan 2023」で、アジャイルのRebuildについて発表しました。全2回。前半は、「選択肢のRebuild」と「ロールのRebuild」について。 開発の考え方をウォーターフォール→アジャイルにRebuild 渡会健氏：みなさん、こんにちは。マネジメントソリューションズの渡会と申します。これから、「アジャイルで実際に困ったからこそアジャイルをRebuildした話」ということで講演させていただきたいと思います。よろしくお願いいたします。 （会場拍手） 最初に、私の自己紹介。この自己紹介の中にも、けっこうRebuildしたことが入っています。 最初の20年は、プ
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
アジャイル開発の浸透？なんだそれは。 アジャイル開発という概念が世に出て二十余年（2001年「アジャイルソフトウェア開発宣言」による）、最早、この技術も最新とは言えない、成熟したものとなりました。あなたの職場でも「アジャイルに進めよう」的な、凝り固まらず柔軟なプロジェクト体制にして行こうという流れ、プロダクト開発の長大化を防ぎアウトプットを細かく出していこうという意識変革が内外から求められているかと思います。 しかしプレイヤーとしての皆様は、とはいえ作るものは変わっておらず納期が決まっているので大変になるだけ、だとか、現場ボトムアップな提案は通らずトップダウンにやることが降ってくるからやる意味なくね、だとか、果ては作るもの・仕様が決まってないけど予算がついたからいい感じにアウトプット出してね、の意味だとか、都合よく「アジャイル」を使われて疲弊することもあるでしょう。多くは会社の通例や予算検
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
自分がニッチだと思っているテーマについて発表する「Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜」。ここで株式会社ノーススターの古谷氏が登壇。個人開発の“つらみ”を解消するアジャイル開発・スクラム開発のエッセンスについて話します。 古谷氏の自己紹介 古谷聡希氏：「個人開発のつらみを経営計画とスクラムの手法で乗り切る技術」です。よろしくお願いします。 今日のテーマはニッチな技術ですが、私は（ニッチな技術と言いつつも）どちらかというと王道技術のニッチな活かし方なのかなと思って発表します。なので、そのように念頭に置いて聞いてもらえたらうれしいです。 あらためまして、古谷と申します。中小企業診断士で、いわゆる経営コンサルの国家資格と認定スクラムマスターを持って活動しています。 会社員としては三井物産株式会社のIT医療の領域の関連会社の株式会社ノーススターでエ
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
🐳この記事は「ログラスサマーアドベントカレンダー2023」の28日目の記事です。 次はデザイナーチームの高瀬さんです。 こんにちは、ログラスの松岡です。 ログラスのプロダクトチームでは、ドメイン駆動設計とアジャイルプラクティス（スクラム、エクストリームプログラミング等）を併用していました。 その中で、「アジャイル・フルーエンシーモデル」(以下、省略時には「フルーエンシーモデル」と表記)という概念が多くのプラクティスを取りまとめ、全体感を把握してチームの成長余地を考えるのに役立つものなので、この記事で紹介したいと思います。 アジャイル・フルーエンシーモデルの面白いポイント 面白いポイントはいくつもあるのですが、この記事で紹介するポイントは二つあります。 ポイント①: 技術的負債への対策が組み込まれている 一つは、「技術的卓越性によってアジャイルの持続可能性(サステナビリティ)を高めるという
先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。 The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。 その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも十分である』というようなまとめになっていました。 ではImpact Engineeringってなんなんだよと元記事268% Higher Failure Rates for Agile Software Projects, Study Findsを最後まで読
「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である - mtx2s’s blog
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
Developers Summit 2024 Summer での登壇資料です https://event.shoeisha.jp/devsumi/20240723/session/5111
後輩に提案されたスクラムにうまく適応できなかった私が開発チームのアジャイルを先導できるようになるまでに考え実践したこと - Agile Journey
アジャイルに興味を持った1人あるいは数人から始めることは、アジャイルの導入においてよくあるストーリーです。とはいえ昨今では、例えばスクラムを導入する開発チームも増えているでしょうし、ほかのメンバーが主導した取り組みとしてアジャイルを受け入れる方も多いでしょう。そんな経緯でスクラムに触れ、既存の開発プロセスとの違いに戸惑い、むしろ積極的にアジャイルを学ぶことで克服した過程を、岸田篤樹（パウリ）さんに寄稿いただきました。 Agile journeyをご覧のみなさま初めまして。株式会社ビットキーでEM（エンジニアリングマネージャー）・スクラムマスター・技術広報をしているパウリ（@pauli_agile）です。私は2015年に新卒でプログラマーとしてキャリアをスタートしました。 その頃の世の中ではすでに、アジャイル開発がさまざまな開発組織に浸透しつつある状況にあったかと思います。ただ、実際に配属さ
大学のアジャイル教育に奮闘した10年からの学び─短期の集中授業でアジャイルをどう実践するか？ - Agile Journey
ソフトウェア開発において、アジャイルという考え方はかなり浸透しています。多く出版物やWebコンテンツ、さまざまなコミュニティやセミナーが存在し、アジャイルの情報には触れやすい状況になってきました。一方で企業においてアジャイルを導入しようとする際に開発チームのどこを変えるべきか、組織固有のルールとどう折り合いを付けるかなどに頭を悩ませる方も多いでしょう。 『SCRUM BOOT CAMP THE BOOK』などの著作で知られ、アジャイルコーチとして企業の組織づくりを支援する永瀬美穂（@miholovesq）さんは、これまで複数の大学で授業におけるアジャイル導入も支援し、その成果を発表する「Agile PBL祭り」を主催してきました。永瀬さんによると、学生は前提知識もないところからソフトウェア開発を学ぶため、社会人エンジニアより自然とアジャイルに取り組める面もあるそうです。 大学はなぜ教育にア
登壇者の自己紹介 司会者：ここからは、クロージングに入ります。クロージングは、Scrum Inc.、アヴィ・シュナイアーさま、JJ・サザーランドさま、Scrum Inc. Japan、クロエ・オニールさまによるご講演とディスカッションです。それでは、モデレーターのクロエさま、お願いいたします。みなさま、拍手でお迎えください。 （会場拍手） アヴィ・シュナイアー氏（以下、シュナイアー）：おはようございます。Agile日本！ クロエ・オニール氏（以下、オニール）：今日、アヴィが英語で登壇してくれるので、私が日本語に訳します。よろしくお願いします。 （会場拍手） 始める前に、Agile Japanのみなさんに感謝したいと思います。ここに呼んでくれてどうもありがとうございます。 コロナが明けてからみなさんが集まるのは初めてだと思います。以前、私も日本でトレーニングをしていたので、今回は見覚えのある
デブサミ2023夏でスポンサー枠を取って「見えない壁を越えよう！アジャイルやマイクロサービスを阻む「今までのやり方」」という講演をしてきました。資料はこちら。 「アジャイルやマイクロサービス」という「これからのやり方」に取り組む時、苦労するのは「今までのやり方」とのギャップです。これは「ウォーターフォールやモノリス」との手法的な違いというよりも、その裏側にある組織やITの仕組み、さらには文化に起因するものです。 なぜなら、今までは「安定して効率的に対応し続ける」ことが正解であり、そのために仕組みを作り上げてきたからです。このような「今までの組織やITの仕組み」のままで、ただ単に「これからのやり方」に取り組んでも失敗してしまうのです。 「今まで」と「これから」のギャップ 失敗1：半島型 新しい手法を試すにあたり、これまでの仕組みとは意図的の距離を置く必要があります。そうしないと、これまでの仕
そもそも、アジャイル開発とは何か。片山氏は「正解がわからない状態で、正解に近づくためのアプローチであり、手法としてはインクリメンタル（徐々に増加する）とイテレーティブ（反復）、つまり、少しずつ繰り返しながらビジネス価値を上げて提供するアプリケーションを開発する点が特徴です。その考え方は複雑だったり、難しかったりするわけではありません」と説明する。 また、ウォーターフォール型開発との違いについて、片山氏は「ウォーターフォール型開発では決められたゴールを目指して直線的に進んでいくのに対して、アジャイル開発では試行錯誤を繰り返しながらゴールに近づくことを目指します」と解説する。 「ある程度の規模を持つシステムを開発する場合、アジャイル開発のほうが工数もかかることがあります。アジャイル開発の特徴が決して『早い』『安い』ではないと理解しておくことが非常に重要です」（片山氏） 片山氏によると、実際のア
アジャイルソフトウェア開発宣言では、 よりよい開発方法を見つけだそうとしている とあり、またこれに付随する「アジャイルソフトウェアの12の原則」では 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されますチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整しますとあります。 これらが意味するのは、どんな形で開発するといいのかはチームごとに違うこと、それぞれのチームが自分たちの状況にあわせて改善していくことに価値があるということです。 つまり、アジャイル開発標準を作って、それを強制することは、アジャイルの価値観そのものを毀損することになります。 誤解を避けるために繰り返しますが、アジャイル開発の標準を作ること自体は役に立つ可能性はあります。 ですが、この利用や遵守を強制してはいけません。強制したところで標準化自体が生産性や成
Oracle Database で機械学習を始めよう! Oracle Machine Learning
はじめに DX（開発体験）の向上によって、チームやプロジェクトの持続的なパフォーマンスにプラスの影響を与えると考えられています。また開発体験とは、以下の4つの要素で構成されると言われています。 Fitting architecture（アーキテクチャの適合） Great tools（優れたツール） Processes to back that all up（すべてをバックアップするプロセス） Nontoxic team culture（毒のないチーム文化） この記事では、2番目の優れたツールについて、弊社の開発で使っているものを紹介します。 導入ツール Google Workspace 有名なグループウェアですが、メールやドキュメントよりも、各サービスへアクセスするSSO認証としての側面が強いです。 Slack こちらも有名なチャットサービスです。特にハドルが実装されて以降、社内の場合はわ
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイルかどうかとは関係
アジャイルやスクラムに関するよくある質問
アジャイルコーチングや各種トレーニングの際によく聞かれる質問についてまとめました。 なお、内容については十分注意を払っておりますが、有効性等は状況によって変わります。お客様の自己責任にてご利用ください。 https://assets.attractor.co.jp/wp-content/uploads/2023/11/0098.webp 675 1200 admin https://assets.attractor.co.jp/wp-content/uploads/2019/12/logo_attractor_medium-300x138.png admin2023-11-10 21:00:162023-11-11 22:16:21Q. プロダクトバックログアイテムはいつ見積もればいいですか？ https://assets.attractor.co.jp/wp-content/upload
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明
アジャイルについてマネージャーが知るべき97のこと
アジャイル勘違い集 (2024) | Agile Studio
アジャイルを導入したものの続けられなかったあなたへ 誤解や理解不足で起こる“もったいない”を解消するヒント
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
アジャイル専門部隊の一構成員が敢えてウォーターフォールを語るぞ - Qiita
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント
個人開発が続かない理由は「時間」「戦略」「気力」「孤独」 4つの“つらみ”を解消するアジャイル開発・スクラム開発のエッセンス
アジャイル・フルーエンシーモデルでアジャイルに技術的負債対策を組み込む
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
「国民性にはアジャイル要素があるのに、ビジネス文化になると合わない日本」 多くの人に忘れられがちなトヨタ生産方式のポイント
アジャイルやマイクロサービスを阻む「今までのやり方」 - arclamp
アジャイル開発はなぜ失敗するのか？ ガートナーが絶対押さえるべき6つのポイント解説
社内でアジャイル開発標準を作るときの注意点を教えてください
大規模なアジャイル開発の現場と技術負債 / Technical Debt
アジャイルでの開発体験をよくするための優れたツール集