はじめに すまんタイトルは釣りだ。めっちゃ煽った 前提 SaaS企業の内製開発 数十億円調達済みの大きめな会社 スクラム開発をしている 相談者は社内受託感が強まっているのがご不満 ある日相談された 「壁の向こうから締切とプロジェクトが降ってくる」 「プロジェクトが降ってくるのはいいとして、着手前に密室でマネージャーだけで 勘と経験と度胸 ベースで完了目標の日付を決めるのはやめてほしい」 「ほぼ間違いなく、完了目標の日付をオーバーしてしまう。守れない日付をほぼ「締切」として指定しないで欲しい」 「期間とスコープを指定されるのは社内受託感が強い」 という相談を受けました。 前提として SaaSの内製開発をしているWeb企業である スクラム開発をしている 中期的な完了予定の予測を出すことはできない。まだスクラムチームはそのレベルにない 結論から言おう さて僕からの答えはこれです 正確にいうとマネ
前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか？どうすればいいんですか？」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
ソフトウェア開発手法の一つである「アジャイル」は、いまやプロダクト開発に関わるあらゆる人がカジュアルに使う言葉になった。
アジャイル手法提唱者が涙ぐんだ「日本発の論文」 論文著者、野中郁次郎教授が指摘する「アジャイルの真髄」 新しいソフトウェア開発方法論「アジャイル開発」の一手法である「スクラム」の源流は、日本発の論文にあった。その論文著者の一人、野中郁次郎氏（一橋大学名誉教授、中小企業大学校総長）が語る「アジャイルの真髄」とは何か。（JBpress） 新しいソフトウェア開発手法として、さらに組織変革やビジネスの革新手法として注目を集めている「アジャイル」。「スクラム」はその中で最も普及している具体手法である。その「スクラム」提唱者の一人ジェフ・サザーランド氏が着想を得る原点となったのが、日本企業におけるイノベーションの成功要因を研究した日本発の論文なのだ。 サザーランド氏が、その論文を竹内弘高氏（現ハーバード・ビジネス・スクール教授）とともに執筆した野中郁次郎氏に実際に対面したのは、「スクラム」を提唱してか
ベロシティは、スクラムの要素だったことはありません。 ソフトウェア開発に「ベロシティ」を適用することは、エクストリーム・プログラミング（XP）の先駆者たちによって考案されましたが、今ではそれが良くないアイデアだと考える人たちもいます。 残念ながら、スクラムの世界では、いまだに 「4倍のベロシティ向上 」や 「超生産性」などの言葉を押し付けている人がいます。私はこれを恥ずかしく思っています。これは、私が ケン・シュエイバーから学んだ スクラムではありません。ケン・シュエイバーは代わりに、 厳格な完成の定義 と、守れない約束を避けるということを強調していました。 もし私たちが、 実験から学び、適応する能力 を促進するのであれば、特に私たちの近視眼性（木を見て森を見ない傾向）と短絡的な認知バイアスを考えると、従来の生産性重視の姿勢は（それがどのような理由であれ）有害となりえます。あなたが昔に書い
この記事は freee Developers Advent Calendar 2022 の3日目です。 このドキュメントはなにかの答えをあたえるというより、アジャイルやスクラムを有効化させる上での障害はこれであるということを検討するためのドキュメントです。壁はすべての環境で発生するわけではないですが、そういう壁があるということを認識することで、転ばぬ先の杖となるような文章になることを目指しています。そして、その解決方法は示さず「意図的に不完全」にしています。これを読んで「なぜ意図的に不完全にしているのか」を味わっていただければと思います。（あるいは、私自身のエクスキューズかは読んでる皆様にその判断を委ねます） 前提: アジャイル開発とは アジャイルソフトウェア開発（以後、アジャイル開発）はアジャイルソフトウェア開発宣言で示されている価値の実現を目的とした開発手法です。宣言では4つの項目でそ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに 前回、なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのかの記事において、プロジェクト型の人員規模を柔軟に変化させる開発スタイルに関して、理論的なスケジュール削減の限界について考察しました。その際に、チーム型開発や組織とソフトウェアの紐付けについても示唆しました。 今回は、チームでソフトウェアを開発することに関して、「フロー効率」と「リソース効率」という観点から考察し、なぜ私たちはチームで開発するのか、あるいはなぜプロジェクト型を採用するのかについての考え方を深めていきたいと思います。 そして、組織における効率
4. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B 5. リソース効率性 A A A A A A A A A
尊敬するDOAの先輩である、渡辺さんがこう書いている。 「データモデルなきアジャイル」の危うさ、より その種のシステム（※引用者補記：販売管理システムや生産管理システムといった基幹系業務支援システム）をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。 業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。 それに対して、稲見さんがこんなコメントをしている。 アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
