2025年1月25日、野中郁次郎先生が逝去された。私は、先生とアジャイル開発のScrumの創始者の一人である Jeff Sutherland を引き合わせた一人であり、また、先生と共著で『アジャイル開...
ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装
こんにちは！ アジャイルプロセス推進チームの日下（LINEヤフー株式会社）、岩井（LINEヤフー株式会社）、荒瀬（PayPayカード株式会社）です。私たちは、アジャイルコーチとしてPayPayカードのアジャイル開発を支援しており、現在E2E自動テスト（以下、E2Eテスト）の導入を進めています。この導入における戦略、直面した課題、そしてそれらをどのように克服したかについてお話しします。組織にこれからE2Eテストを導入しようと検討している方や、既に導入済みで安定稼働や運用に課題を抱えている方にとって、お役に立てれば幸いです。 また、私たちアジャイルコーチはLINEヤフー株式会社およびPayPayカードのものづくりに深く関わり、プロセス改善や仕組み作り、最新技術の導入を行っています。過去の事例は以下のリンクからご覧いただけます。 SWAT×Agile Coach: 異なるスキルが共創するまでヤフ
tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイル
おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま
これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの
はじめに みなさんは、スクラムでストーリーポイントを付けるときどのような基準でつけているでしょうか? ストーリーポイントの基準は時間にすべきではないと言われています。 しかしながら、 スクラムを初めて導入して今まで時間対の工数見積もりに慣れていたチームや請負型の社外パートナーが入ったプロジェクトなど、現実的には時間を基準にしてストーリーポイントを運用しているプロジェクトも多いでしょう。 また、ストーリーポイントの見積もりを付け始める際の最初の基準として「4時間 = 1ストーリーポイント として考えよう！」というように知らず知らずのうちにそのような運用になっているケースもあると思います。 私は経験から、ストーリーポイントの基準を時間にするのは、プロジェクト管理に大きい悪影響をもたらすアンチパターンであり、すべきではないと結論づけています。 私が経験してきたプロジェクトで、ストーリーポイントの
ちょっとだけ読んでから積む「積⭐️読タイムアタック」で、タワーと化した購入書籍の未読圧のプレッシャーから解放されました
はじめに ポケモンスリープに結構ハマって、仕事は忙しいけど前より健康的になって仕事のやる気が起きない岩間です。8時間寝なくちゃ 今回は、参画しているEASMプロジェクトでスクラム開発(以下、スクラム)を導入した話について紹介します。 現在弊社で開発しているEASMサービスのβ版についての詳細は以下をご参照ください。 https://www.securesky-tech.com/2023/10/26/6723/ ※本記事における意見は、筆者の個人的な意見であり、所属団体や関与するプロジェクト等の意見を代表するものではありません。 スクラムをはじめるキッカケ 当初からEASMはSaaS提供を前提で検討していたため、継続的な開発にマッチした開発手法を選ぶ必要がありました。また、いくつかの開発手法に関する書籍や記事を読んでみて、以下の理由からスクラム開発が適していると感じたため採用しました。 スモ
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
株式会社インテグリティス代表の木村です。（Twitterではけいと呼ばれています。） 最近は受託開発の他、クライアント企業様への内製エンジニアリングチームの立ち上げとコーチングを事業として取り組み始めました。 アジャイル開発における「ストーリーポイントとベロシティ」について考える機会があったので、色々調べてみました。 スクラムの文脈で見積もりの単位としてよく使われる「ストーリーポイント」ですが、元々はXPが起源でした。 XPの創始者の一人であるRon Jeffries氏は2019年5月23日、自身のサイトにて「Story Points Revisited（ストーリーポイントの再考）」と題し、ストーリーポイントに対する考えを述べています。 なにかと誤解があったり、スクラム開発の現場で疑問が生まれることも多い「ストーリーポイント」や「ベロシティ」という概念ですが、Ron Jeffries氏の記
I like to say that I may have invented story points, and if I did, I’m sorry now. Let’s explore my current thinking on story points. At least one of us is interested in what I think. Stories, of course, are an XP idea, not a Scrum idea. Somehow, Scrum practitioners have adopted the idea. Even though the official Scrum Guide refers to backlog items, having backlog items be User Stories is a common
「Agile Tech EXPO（あじゃてく）」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベーションの加速のポイントとなる「スプリントの長さ」と「プロジェクトの同時進行」について。 テスラのアジャイル文化を12のステップで紹介ジョー・ジャスティス氏：本日はありがとうございます。アジャイルハードウェアディロップメントとして、アジャイルをいかにハードウェア開発に適用していくかということを、今回お話しします。 私の経験ですが、マイクロソフトのビル・ゲイツや、スペースカンパニーやAmazonをやってい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く