なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
スクラムチームがぶち当たる「相対見積もり」の壁と、私たちの乗り越え方
これまでエンジニアやスクラムマスターとしてスクラムチームに関わって来ましたが、その過程で何度も「相対見積もり」や「ストーリーポイント」に纏わる悩みにぶち当たってきました。工数や期間での見積もりに慣れていた私にとって、それらは理解も実践もしにくい手強いものでした。 今回は、私が実際に直面した問題と、それらを打破するためチームで取り組んできたことを思い返してみようと思います。 壁1. 「相対見積もり」の考え方を理解できない 壁2. ストーリーポイントが「何を見積もる手段か」を理解していない 壁3. 見積もりをコミットメントと捉えてしまう まとめ 壁1. 「相対見積もり」の考え方を理解できない バックログ上に積まれたユーザーストーリーやエピックを見積もろうとしたとき、私たちは真っ先に「こんなコンポーネントを新規実装するだろう、おそらく2日くらい掛かる」「あの既存機能をいじる必要があるが、複雑な箇
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
