現代的システム開発概論2023年度リクルート エンジニアコース新人研修の講義資料です
完了予定も出せないから、いつまで経ってもお前のチームは社内受託なんだよ
はじめに すまんタイトルは釣りだ。めっちゃ煽った 前提 SaaS企業の内製開発 数十億円調達済みの大きめな会社 スクラム開発をしている 相談者は社内受託感が強まっているのがご不満 ある日相談された 「壁の向こうから締切とプロジェクトが降ってくる」 「プロジェクトが降ってくるのはいいとして、着手前に密室でマネージャーだけで 勘と経験と度胸 ベースで完了目標の日付を決めるのはやめてほしい」 「ほぼ間違いなく、完了目標の日付をオーバーしてしまう。守れない日付をほぼ「締切」として指定しないで欲しい」 「期間とスコープを指定されるのは社内受託感が強い」 という相談を受けました。 前提として SaaSの内製開発をしているWeb企業である スクラム開発をしている 中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない 結論から言おう さて僕からの答えはこれです 正確にいうとマネ
スケジュールの見積もりを適当に答えたらコミットメントにされる問題について｜きゅーい / koyo
こちらのエントリを読んでいたら、なるほどとてもわかるとなった。そしてこの問題については何らかの解を持っておくべきだと思ったため、ちゃんと考えることにしたのがこのエントリの趣旨である。 上述のエントリには、ソフトウェア開発者がスケジュールのコミットメントを求められた場合、精緻にスケジューリングするためのタスクやスケジュールに余裕を持たせるためのバッファを積むしかなくなり、結果としてソフトウェア開発が遅くなってしまうという話が書かれている。 ソフトウェア開発を実際に行ったことがある人であればこの話には凡そ同意できるとは思うが、それ以外の人には理解に苦しむ話となる。 それゆえに、現代においても「この機能はいつまでにリリースするの？出来なかったらどうするの？」といった質問が横行し、それに対して特に意味のないスケジュールを答えるという虚無の応答が多くのチームでいまも行われている。 ビジネスサイドの仕
アジャイル、とりわけスクラム開発をやるときに立ち向かわなければならない壁の話 - freee Developers Hub
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
あなたが学んだアジャイルとテスラの手法は何が違うのか？ 認定スクラムトレーナーが語る、テスラの真の凄さ
「Agile Tech EXPO（あじゃてく）」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベーションの加速のポイントとなる「スプリントの長さ」と「プロジェクトの同時進行」について。 テスラのアジャイル文化を12のステップで紹介 ジョー・ジャスティス氏：本日はありがとうございます。アジャイルハードウェアディロップメントとして、アジャイルをいかにハードウェア開発に適用していくかということを、今回お話しします。 私の経験ですが、マイクロソフトのビル・ゲイツや、スペースカンパニーやAmazonをやって
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由 - Qiita
「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由チーム開発プロジェクト管理マネジメント はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率性の価値観が異なると、新しい効率性に関して理解をする前に「もったいない」と感じてしまい、新しい文化を取り入れづらくして
見積もりについて勉強したことを色々スライドにしてみた - だいたいよくわからないブログ
見積もりについて思ってることとかをまとめてみました。 マネージメントの実戦経験というよりソフトウェア開発手法について学んだ結果のアウトプットみたいなノリでみていただければ幸いです。 社内勉強会で話したので会社のスライド使ってますが、会社が今こうというわけではなく一般的な話にとどめています。（あとstudy_lean_agileっていう名前の勉強会なんですが、このスライドはリーンもアジャイルもあまり意識していません） 前半は自分なりの考え方、後半は具体的にはこうしたらいいんじゃないかと思っていることという風に分けています。 誰のための見積もり・何のための見積もり part1 from matsu_chara Matsubayashi www.slideshare.net 誰のための見積もり・何のための見積もり part2 from matsu_chara Matsubayashi www.s
DeNA流Scrumとcommのチームビルディング
Scrum Alliance Regional Gathering Tokyo2013でDeNA貝瀬、高坂、坪田が発表した際の資料です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もなか on Twitter: "「なぜスクラムが支持されているのか」をミもフタもない切り口で説明している文章って、意外と無いねぇ。 要するに「エンジニアってのは時間の見積もりが甘い、安定した生産性をキープすらもできない、哀しい生き物なのよ」っていう諦観が根っこにあるのよね…。"