ウォーターフォールの反省とアジャイルの成功に必要なもの - Qiita
この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負開発にある 請負開発で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負開発 なぜ請負開発は失敗しやすいのか？ ベンダーは「システム開発だけ
アジャイル専門部隊の一構成員が敢えてウォーターフォールを語るぞ - Qiita
アジャイル開発の浸透？なんだそれは。 アジャイル開発という概念が世に出て二十余年（2001年「アジャイルソフトウェア開発宣言」による）、最早、この技術も最新とは言えない、成熟したものとなりました。あなたの職場でも「アジャイルに進めよう」的な、凝り固まらず柔軟なプロジェクト体制にして行こうという流れ、プロダクト開発の長大化を防ぎアウトプットを細かく出していこうという意識変革が内外から求められているかと思います。 しかしプレイヤーとしての皆様は、とはいえ作るものは変わっておらず納期が決まっているので大変になるだけ、だとか、現場ボトムアップな提案は通らずトップダウンにやることが降ってくるからやる意味なくね、だとか、果ては作るもの・仕様が決まってないけど予算がついたからいい感じにアウトプット出してね、の意味だとか、都合よく「アジャイル」を使われて疲弊することもあるでしょう。多くは会社の通例や予算検
「象・死んだ魚・嘔吐」をやってみた振り返り - JX通信社エンジニアブログ
こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法（原題: The Airbnb Story）の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう？ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。
実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】
TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング
現職と前職で感じたスクラムの違い - Qiita
前置き この度、ご縁あってこちらの記事の内容でFindyさん主催の 『「脱！なんちゃってスクラム」実践事例から学ぶ Lunch LT』 に登壇しました！ もし、よろしければアーカイブご視聴ください！ 当日、発表で使用したスライドも載せておきます。併せてご確認いただけるとより理解が深まると思います。 はじめに 今の会社に転職してきて２ヶ月が経ち、まだまだ分からないことも多いですが少しずつ環境にも慣れてきたので頭の中を整理するためにも今感じていることをアウトプットしたいなと思い書きました！ 現在、私が参画しているチームはスクラムをベースとして開発を行なっており、前職もスクラムでの開発を経験していたので、その違いを整理していきます。 前職 スクラムを導入するまでの背景 前職では、美容医療・精神科クリニックを運営している会社で、クリニックスタッフが使用する社内システムの開発に携わっていました。働き
スクラムとデッドライン壊れゆくチームをつなぎとめるもの/Scrum and Deadlines
見えづらい活動の成果の伝え方は日頃からめちゃくちゃ悩んでるけど、実際こんな取り組みをしな がら温度感を合わせにいってるよ / Conveying Hard-to-See Results
アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります（内容が具体的になっていればもう解決までそう遠くありません）。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの？」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません（その場合は適宜用語を読み替えてください）。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか？」 です。この確認をしないうちに「スクラムイベントは全部やっているか？」とか「プロダクトバック
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
mikanデザイナーの"スクラムで回す1週間"を覗いて行きませんか？｜Ayaka Nagataki
はじめにこんにちは！株式会社mikanでデザイナーをしているayataki（@ag_ayakan）です。 主に英語アプリ「mikan」の体験設計やUIデザインの作成を行なっています。 カジュアル面談などで話す際に、「mikanのデザイナーさんてどんなことをやってるんでしょうか？」という質問をよくいただくようになりました。 社外への発信が少ないこともあり、イメージを持ってもらいづらい状況にあるのではないかなと感じています。 そこで今日は、mikanのデザイナーとして働くわたしの1週間のスケジュールについてご紹介します！実際にあった直近のスケジュールを具体例に出していきます。 mikanのデザイナーに少しでも興味のある方に、具体的なイメージを持ってもらえたら幸いです🍊 それでは行ってみましょう！ [前提] 仕事の環境ほぼリモートワーク mikanのメンバーは基本的にフルリモートワークで働いて
東京都初のアジャイル型開発はいかにして導入され、実践されたか – 調達、スクラムの工夫、展望を聞いた - Agile Journey
「初！都庁職員、アジャイル型開発に参加する」 東京都デジタルサービス局デジタルサービス推進部の公式note（2023年1月公開）には、かつて“試みたことのない開発手法”であったアジャイル型開発を東京都が採り入れ、複数のソフトウェアを開発した経緯が綴られています。 これまでAgile Journeyでは、さまざまな組織、企業のアジャイル導入事例を紹介してきましたが、それぞれの組織がそれぞれのモチベーションを持ち、課題に向き合いながら、導入に取り組んできました。では、それが自治体の場合では？ 東京都がアジャイル型開発を導入し、運用していくための動機、準備、事業者との契約の方法、そして実践のありようを、東京都デジタルサービス局の石川秀之さん、下家昌美さんに聞きました。 コロナ禍で浮き彫りになった、「迅速」の重要性 「システムをアジャイル型開発で作ってみませんか」メールで呼びかけ、アジャイル型開発
開発だけアジャイルな状況を越えて顧客のアウトカムにつなげる一歩/next step in agile development agile japan 2023
「めちゃくちゃ勉強してソフトウェア開発も、アジャイルな開発もできるようになってきた! ところがせっかくうまくできるようになったけど、顧客への貢献にはなかなか繋がらない…」こんな悩みををよく聞きます。 この10年間でスクラムなどのアジャイルに関する情報やノウハウは増え、社会的な理解も広がり、その結果アジャイルははじめやすく、習熟もしやすくなっています。開発チームは急速に学習し、能力が高められやすい状況にあります。 ところがプロダクト価値の観点から見ると、開発チームも社内の他部署も、そして顧客も不満を持っていることがあります。せっかくアジャイルな活動ができるようになっても、プロダクト価値に繋げるまでにいたっていないことが多々あります。 本セッションでは、プロダクトという観点からアジャイルを捉え直し、開発チームや社内の他部署、顧客も満足するためのお話をします。 プロダクトマネジメントなど過去の登
見積もりをがんばらない - forest book
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
(翻訳) ストーリーポイント再考 - forest book
本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している
なぜアジャイルは日本で広がらないのか？現状に関する考察と将来の展望
私はこれまで６年間日本で働いてきましたが、昨年11月にプロフェッショナル・スクラム・トレーナーになってから、日本のスクラムやアジャイル開発の現状と今後の展望についてよく質問を受けるようになりました。そうした質問に触発されて私自身もこのテーマについて掘り下げて調べたり考えたりするようになりましたので、この記事にまとめました。（English version here） スクラムとアジャイル開発の現状 1986年、当時 一橋大学教授であった野中郁次郎氏と同大学の竹内弘高氏は「The New New Product Development Game」(Harvard Business Review) という非常に有名な研究論文を発表しました(1)。この論文は日本企業による新製品開発プロジェクトの成功事例を紹介すると共に、これらのプロジェクトに共通する特徴として「自己組織化されたチーム」「開発フェ
Re: スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている - terurouメモ
この記事を読んだ。 note.com よーある話だなと思いつつ、「業務委託はダメで、社員ならOK」という話はちょっと話が雑だなあと思ったので、コメントを書く。 スクラムチームで人の出入りが激しいとキツイ これはそう。 ただ、スクラムかによらず、出入りが激しいとキツイけど… 業務委託では、高パフォーマンス人材は単価つり上げがきつく、結果契約打ち切りになる 実際の事象としてはよくある話。ただし、業務委託のみの話ではなくて、社員でも「会社に不満があったからやめた」は良くある話。 たぶん、ここが気になるのは、このあたりの違いだとは思う。 報酬の見直し頻度 社員だと給与体系の見直しが年1回であるのが普通 業務委託だと契約期間ごと（業界慣習的に3カ月単位が多い認識） 条件交渉者が本人なのか営業なのかの違い 営業の仕事は売上を上げることなので、当然ガンガン言ってくる 対して社員が自分の雇用条件について、
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ
最初に タイトルは煽りで釣りです。ごめんね。 この記事の結論を先に書くと タイトルは釣り スクラムチームは導入当初はスムーズに成功できるように感じる。しかし途中でどこに進むべきかの方角を見失い、迷走してスクラムバットに陥る スクラムに求める効能はベロシティの安定が必須なものが多いのに、ベロシティの安定を意識すらしないままスクラムをやるので、迷走に陥る じゃあどうしてそうなってしまう？という話を個人の経験をもとに書いていこうと思います。 前提として この記事を書いた人はWebサービスの内製開発をしているアプリケーションエンジニアだったので、基本的に内製開発のWebサービスでのスクラム導入について語ります なぜこの記事を書いたか やっとむさんのツイートを見て思いつきました。 スクラムの導入をしたいというチームは数多く見ますが、かなり中途半端なところでスクラムのレベルアップをやめて、小手先の「改
情報システムってなんなん
この間情報システム部ですって人がいた。 「今、会社でスクラムを導入する大きなプロジェクトを任されてて、、、」みたいなこと言ってた。 なんかこれみよがしに分厚いスクラムの本読んでた。スクラムマスターになるんだって。 なんか夜はそれのコースみたいなのやって大変なんだって。 君情報システムやんな？ 携帯とかWIFIとかセットアップする人やんな？ システム全部外注やんな？ なんでスクラム必要なん？ ここでスクラムの説明をすごく簡単にしときます。 まずそもそもスクラムというのはIT界隈でシステム開発を進める際のお仕事のやり方です。私も詳しく知らないのでラーメン屋で例えます。 ラーメン屋で新しいラーメンを開発するときに、スープの開発、チャーシューの開発、麺の開発、メンマの開発があるとします。 そしてそれぞれ担当者が割り当てられるとします。 スープ担当が開発を始めるとチャーシュー担当はこう言いました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10年ちょっとやってきた僕のアジャイル開発の現在地
Agile and DevOps の歴史をチェリーピック
