今回の記事は特に私の意見であり、所属会社の意見ではないことをお断りしておきます。 最近になってまたウォータフォール vs アジャイルの議論を見かけることが多くなってきたので、私が勤務する米国の世界規模のクラウドプロバイダーでは2024年現在どんな開発をしているのかをご紹介したいと思います。私はこれが「正解」といいたいのではなく、何らかのポイントが皆さんの何らかの参考になったらいいなと思って筆をとりました。 ちなみに、2016年時点で私のウォータフォール開発に対する考え方は下記のブログの通りで今も変わっていません。ただ、2024年現在だからといってアジャイルをやるべきと思っているわけでもありません。 もし、今ウォータフォールをやっている人がいたら「そんなこと言ってもどうしたらええねん」となると思うので、自分なりの解決方法も考えてみました。 最初に自分的な結論を書いておくと「2024年の開発と
tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
コードを書き始める前からテストをずっと考える ─ 継続的テストモデルとシフトレフトなテスト活動をアジャイルにどう取り入れるか - Agile Journey
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か？ 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
スタートアップ企業が実践する「身の丈スクラム」の現在地 / Current State of 'Right-Sized Scrum' Practices in Startups
Scrum Fest Osaka 2024で発表した内容です。 https://www.scrumosaka.org/ https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20059 ■リンク 後回しにされがちな…
「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」 - Qiita
「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」アジャイル要求ユーザーストーリー はじめに ◆この記事は何？ アジャイル開発における「要求」や「ユーザーストーリー」を細分化する記事です。 ◆対象は？ 要求やユーザーストーリーを整理する方 アジャイル開発に関わる方 ◆ねらいは？ アジャイル開発に関わる方が、何気なく使っている「要求」や「ユーザーストーリー」の解像度を上げること エンジニア人生に影響を与えたフレーズ 「システム構築はどこから始めるべきだろうか。システム構築が終わったらこうなる、というストーリーを語るところからだ。」は、書籍『テスト駆動開発』に出てくるフレーズです。 そして書籍『テスト駆動開発』の中で、私が最も印象に残っている文章です。 この文章に出会ってから、私は「言われた通りにシステムを作る」から脱却して、「
価値のある機能をユーザに早く届けるための大企業エンジニアの挑戦 / Achieving Faster Delivery of Customer Value Features in a Siloed Organization
024年6月28日に開催された 開発生産性Conference 2024 の講演資料です。 講演詳細についてはこちらをご覧ください。 https://dev-productivity-con.findy-code.io/2024
大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫 | MEDLEY Developer Portal
2024-07-02大規模プロジェクトの課題を解消する、たった1時間で行うふりかえりの工夫はじめにこんにちは。CLINICS カルテの QA 担当をしております QA エンジニアの かみむら です。 医療プラットフォーム本部 CLINICS 開発チームでは、2年以上に渡り自社レセコン1の開発を行っています。プロダクトは公開済みであるものの鋭意追加機能の開発を続けており、今後も継続して開発する予定になっています。 QA エンジニアの大切な役割の1つとして、プロセス改善があります。ふりかえりはプロセス改善のアイデアを関係者全員で話し合うための肝となるアクティビティですので、規模の大小問わず取り入れたいものです。 この記事ではレセコン開発におけるプロジェクト体制構築時の黎明期から現在の成熟期に至るまでに行った、四半期毎のふりかえり手法や効果について、かいつまんでご紹介します。 プロジェクトの状況
先日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を最後まで読
こんにちは! SmartHR プロダクトエンジニアの @sakata と @hypermkt です。 SmartHRではほぼすべてのチームでスクラム開発を行っています。スプリントプランニングとスプリント進行中における課題に対し、私たちのチームでは「予言の書」という取り込みを行っています。本記事では、この「予言の書」の概要とその効果についてご紹介します。 予言の書が必要な背景 スクラム開発で、チームが消化できるキャパシティからタスクを選定したにも関わらず、すべてのタスクの消化ができなかったという経験はありませんか？ 私たちはたくさん経験したことがあります。そこにはスプリントプランニングにおける計画とスプリント進行の難しさがありました。 すべてのタスクが終えられるか不安がある まだ作業タスクには何も着手していないので当たり前ではありますが、チームが消化可能なキャパシティからタスクを選定し、優先
『設計ナイト2024【オフライン】 - connpass』に参加してきたのでそのメモです。 各発表の感想 ※資料スライドは見つけたら貼ります。 ロジックから状態を分離する技術 今日の登壇資料です。 ロジックから状態を分離する技術/設計ナイト2024 by わいとん @ytnobodyhttps://t.co/XxBNAYiKXS #sekkeinight— わいとん (@ytnobody) 2024年6月14日 感想 純粋関数の話を基軸にいかに容易にしていくのか、という話 入力から必然的に出力が決まるロジック類をDomainとしておこうという発想はよかった 純粋関数の構成デザインパターンの分け方すごくいいなぁと思ったのと、このあたりの話を提唱している人いないのがびっくり 関連リンク 純粋関数とは - 意味をわかりやすく - IT用語辞典 e-Words Flux パターンが解決した課題 -
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイルかどうかとは関係
スクラムが「上手くいってる」「上手くいってない」の頭の整理 - Mitsuyuki.Shiiba
この記事を見かけて、やっとむさんだなーやさしく伝えたんだろうなーって思いつつ。「上手くいく」「上手くいってない」って幅がありそうだよなと思ったので、頭の中の整理をしてみることにした。来週の発表の準備が煮詰まっているから気分転換しているだけともいう。 yattom.hatenablog.com やっとむさんの記事を読む 「スクラムで開発を進めている」という状況で 「問題が多い→ならば→スクラムは合わない」のか？という問いに対して やっとむさんの回答は「問題がある→ならば→スクラムは上手くいっている」 と書いてある。「合わない」は「うち（の会社）には合わない」の意味。 最初にことわっておく ふだんからいろいろとお話をされている関係性の中で伝えていて、その前後にいろんなお話をしているんだろうなと想像している。 だから、僕がここで書くようなことは、その関係性の中ですでに共有されていることだと思って
対話したいわ 〜認知バイアスを知り、円滑な対話を〜 / I want to have a dialogue -Knowing cognitive biases and having a smooth dialogue
スクラムフェス大阪 2024にて登壇 https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/20273
フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy
フィーチャー開発から ホールプロダクト開発へ ~ 顧客価値へ向き合い続ける挑戦 ~ @itohiro73 #開発生産性con_findy
ソフトウェア開発で目撃したものを説明するために、私は造語を作る習慣があります。 便利な用語が少ないので、ソフトウェア開発の分野の書き手はこのようなことをよくやります。 造語を作るときの問題は、意味の希薄化により本来の意味が失われ、別の意味が追加されてしまうことです。 意味の希薄化が発生するのは、個人やグループが作った用語があり、適切に定義されていたにもかかわらず、歪められた定義がコミュニティに広まったときです。 これにより、用語の定義が完全に失われる危険性があります。 また、それに伴い、用語の利便性も失われてしまうでしょう。 私が本記事を書こうと思ったのは、「アジャイル」と「Web 2.0」に意味の希薄化が発生しているからです。 いずれも数年前に作られた用語であり、しっかりとした定義があります（アジャイルにはアジャイルマニフェストがあり、署名者たちが執筆した書籍や記事も多数あります。Web
デイリースクラムあるある早く言いたい
それデイリーやない。レイニーや。 はじめに こんにちは。学園アイドルマスターにハマっているスクラムマスターの池永です。 レバテック開発部ITSプロダクト開発グループに所属しており、日々チームが強く、楽しくなれるように試行錯誤しております。 先日、以下の記事を投稿したのですが、他のスクラムイベントにもあるあるはあるよなと思い、デイリースクラムのあるあるも早く言いたくなりました。 こちらも何か参考になる情報がありましたら幸いです。 話すこと スクラムにおけるデイリースクラムのあるある あるあるに対して自分がやったこと そのアプローチをとってどうなったか 話さないこと スクラムにおけるデイリースクラムの詳細な目的 デイリースクラムの具体的な進め方 では早速... 例に漏れずあるあるを早く言いたいので、挙げていこうと思います。 1. ただの進捗報告会になりがち スクラム導入間もないチームでは、デイ
「稲作」のメタファーで「現在・未来」の「ゲイン・ペイン」に注目したら、とても前向きにふりかえりできた - Money Forward Developers Blog
こんにちは、クラウド会計の開発チームでスクラムマスターをしているasatoです。 自作のふりかえりフレームワークがいい感じに機能したので紹介します 🙌 その名も「稲作（Rice Cultivation）」です。 背景 私はスクラムマスターとして、チームのふりかえりをファシリテーションする機会が多いです。当然のようにお気に入りのふりかえりフレームワークがあります。その辺は、個人のブログで語っています。 ブログでも語っている通り、私は「象・死んだ魚・嘔吐」が好きです。メタファーが想像力を掻き立ててくれます。 象🐘：誰も言わないので言いにくいと感じているが、大きな障害物だと思っているもの（英語の慣用句 “Elephant in the room” より） 死んだ魚🐟：今はそこまで気にならないが、放置すると大きな障害物になりそうなもの 嘔吐🤮：その他、自分の中でモヤモヤしているもの い
Scrum Fest Osaka 2024 https://confengine.com/conferences/scrum-fest-osaka-2024/proposal/19867
2024年6月29日(土)にHOKKAIDO x Station01をお借りしてえにしテック15周年記念カンファレンスを開催しました。 当日はたくさんの方々にお越しいただき、おかげさまで、とても特別な15周年を迎えることができました。参加いただいた皆さま、あたたかいメッセージをいただいた皆さま、登壇いただいた高橋さん、角谷さん、大場さん、平鍋さん、美味しいコーヒーを出していただいた猫廼舎さん、運営をつつがなく取り仕切ってくれたメンバーのみんなに感謝します。ありがとうございました。 正直、まだあの場がなんだったのかをきちんと飲み込みきれておらず、きちんとした総括はできない感じなのですが、何かを書いておかないと先に進めない気がしているので、一旦カンファレンスのことを書き残しておこうと思います。 15周年の節目、何をしたいかと考えて出てきたのは、一番に初心に返って勉強会がしたいなという気持ちでし
新卒1年目エンジニアだって Tech イベントの運営リーダーをやってみたい！ - NTT Communications Engineers' Blog
こんにちは、クラウド & ネットワークサービス部の井口です。普段は OpenStack を利用した SDPF クラウドの仮想サーバ開発/運用をしています。 昨年 12 月に開催された学生向けの技術広報 1day イベントにて、私は当時新卒 1 年目で運営リーダーとして携わりました。 この記事では、運営リーダーを務めた経験から得た学び・知見を紹介します。 Tech Workshop とは NTT Com が主催する企画の 1 つに「Tech Workshop」1というものがあります。主にエンジニア志望学生向けに、現場で活躍する社員とともに手を動かしながら NTT Com の技術や業務を理解できる 1day イベントとなります。大きな特徴として、メンバーの大半が現場のエンジニア社員で構成されており、本業務の傍ら企画・運営を行ない、イベントを主催しています(以降運営チームを Tech Event
とある新卒研修のお昼の小噺にて。 プロフィールやお問い合わせはこちらからどうぞ！ https://agile-monster.com/profile/ https://agile-monster.com/contact/
スクラムマスターの 「真のリーダー」を考える
J.K (コサカ ジュンキ) スクラムマスター / Agile Japan EXPO 代表理事 Agileで日本から世界を楽しく！ 三島から日本を楽しく！ Agileの世界とエンジニアコミュニティにどっぷりハマっている元製造業の人。三 島のアジャイルオタク。三島サテライトオフィス長(New) ソフトウェア開発でプロセスやコミュニケーションに課題を感じていたところア ジャイルに出会い、以降、アジャイルの世界へのめり込む。 開催した研修から200名の有資格者を輩出。現在はAgileとScrumの専門家と しての知識や経験を活かしながら組織開発に従事。カンファレンス運営などを 通じ、日本にAgileが楽しく広まることを夢見て日々活動中。
0.はじめにどうも、すべての経済活動をデジタル化したい、LayerXの牧迫（@35_mki）です。法人支出管理サービス「バクラク」シリーズを提供しているバクラク事業部で事業部長を務めております。 最近は5月にオフィス移転し、東銀座・築地の民になりました。ご近所の皆様よろしくお願いします。美味しいごはん屋さん・居酒屋の情報もお待ちしております。 タイトルに「運営技法」という仰々しいテーマを書いていますが、これまで複数サービスを立ち上げて来た経験や、直近新たに立ち上げを行っている中での雑感をまとめてみようと思います。 [注釈] 以降の前提や書きぶりがSaaSやB2B事業に寄っていますが、B2Cでもだいたい同じだと思います。 ■ この記事で主に取り扱うこと： - チーム運営Tipsや心持ち（心持ち多め） ■ この記事で主に話さないこと： - 市場・ターゲット選定や事業の登り方といった戦略・戦術っ
[B-4-1] アジャイル開発は本当に必要なのか、何を解決するのか | AWS Dev Day 2023 Tokyo #AWSDevDay
アジャイル（主にスクラム）の語源は「素早い」や「敏捷」などの意味がある「Agile」です。 文字通り捉えると「アジャイル開発すればすぐにリリースできるんだ！」と考えるのは当然だと思います。 でもいざやってみると「むしろ前より遅くなった」という声もよく聞きます。 このセッションでは、「スクラムの始め方」と「アジャイルの価値」にフォーカスして述べていきます。 ◆スピーカー： 吉田 祐樹 ◆吉田 祐樹プロフィール： Sr.AppDev ConsultantとしてAWS Japanに勤務。アジャイルやクラウドネイティブアプリ開発の支援をしています。「明日楽をするために今頑張る」がモットー。好きなAWSサービスはAmplify/AppSync/CodeCatalyst ◆セッションに関する情報： ・セッションタイプ：ブレイクアウトセッション ・テクノロジートピック：DevOps / Infra
![[B-4-1] アジャイル開発は本当に必要なのか、何を解決するのか | AWS Dev Day 2023 Tokyo #AWSDevDay](https://cdn-ak-scissors.b.st-hatena.com/image/square/1714fe62dbc17b528e14b708af495ff73e2b246c/height=288;version=1;width=512/https%3A%2F%2Fi.ytimg.com%2Fvi%2FHaP0CIZKZcQ%2Fhqdefault.jpg)
はじめに 株式会社Hajimariが展開するプロパートナーズサービス（フリーランスと企業様のマッチング支援事業を展開しています）を利用していただいている、 稼働者・企業担当者の双方に提供している自社開発の稼働管理ツール【Haijmari Works】のテックリードやってます。 野澤です。 Hajimari Works開発チームではスクラムを採用して開発を進めています。 今はもう6月ですが、4月に新卒メンバーがチームにジョインしてくるということで、オンボーディング資料を作成したのですが、 この資料のアジャイルやスクラムの部分に関して、公開してみたいと思います！ スクラムを採用してプロダクト開発をして2年弱、この考え方、この価値観は大切にしたいよねと思ったことをまとめています。 誰かの役にでも立てば幸いです！ アジャイル、スクラムについて Hajimari Works開発チームはアジャイルやス
スクラムフェス大阪2024で「キョムリリースをやめて、プロダクトと向き合う！」登壇したのでふりかえる #scrumosaka - #あすみかんの上にあすみかん
speakerdeck.com asumikamです。ツイッチョ！ツイッチョツイッチョYeah 2024/6/21〜6/22で開催されたスクラムフェス大阪2024で「キョムリリースをやめて、プロダクトと向き合う！」というタイトルで登壇してきました。 ふりかえっていく〜🐸 www.scrumosaka.org スクラムフェス大阪2024 「スクラムフェス大阪」は全国各地で行われる*1 文脈を知らない方は「？？？？？」となる表現でしょうw（私もそうだった） 2020年頃コロナ禍でさまざまなイベントが中止になるなか、オンラインでやってみよう、と初めて試したのがスクフェス大阪のようでした。 そのタイミングで、「各地のスクラムカンファレンスも同じように開催形態に悩んでいるだろうから、"各地トラック"として一緒にやったら良いのではないか？」となり、各地トラックという形態が生まれたらしいです。 近年は
Test Talkで紹介されていた探索的テストの会をヘンリーでもやってみたら、早速、品質向上の効果が出た！ - 株式会社ヘンリー エンジニアブログ
LEADING QUALITYの輪読会後の雑談中様子 株式会社ヘンリーCEOの逆瀬川です。 4月から製品企画の責任者として開発ロードマップや要件開発を行っています。 特に今後、電子カルテを開発するチームでは人数も増え、これから大きな機能開発も増えていくため、これまで以上に品質向上への取り組みを強化しています。 具体的には、品質と信頼性を上げるための施策会議（品質と信頼性の会）や、不具合分析の定例会を開始しました。 本日は、品質と信頼性の会で出てきた施策のひとつである探索的テストを学び、早速実行したところ、大きな効果が出たので共有します。 弊社の品質の守護神 Aさん依存体質からの脱却！！ 探索的テストに取り組むことになった背景としては、QAのAさんへの依存です。 元々医療事務出身のAさんがQAやテストを学び、チームの全てのテストを担っていました。ドメインエキスパートでもある彼女はスクリプトテ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウォータフォールはやめて2024年の開発をやろう！｜牛尾 剛
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
スプリントプランニングの未来予測： 予言の書 - SmartHR Tech Blog
『設計ナイト2024』に行ってきたよメモ - コード日進月歩
意味の希薄化 - Martin Fowler's Bliki (ja)
キョムリリースをやめて、プロダクトと向き合う！
えにしテック15周年記念カンファレンスのこと - snoozer05's blog
我々はなぜテストを書くのか / Why we write test codes
新規事業立ち上げチームの「運営技法」｜maki@LayerX
開発チームで大切にしていること（アジャイル、スクラム色強め） - Qiita