見積もりをがんばらない - forest book
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
ソフトウェア開発の見積もり入門
見積もりとは？ Wikipediaによると見積もりとは、以下のようにあります。 見積（みつもり。見積り、見積もりとも書く）とは、金額・量・期間・行動を前もって概算すること。見積もること。あらましの計算をすること。また、その計算。目算。「所要時間を見積る」、「一日の来客者数をざっと見積もった」など、おおよその感覚で数字の見当をつける場合の口語体表現でも使われる。 Wikipedia このように見積もりとは、なにかを行う前に事前にその結果を予想しておくことを言います。 見積もりを使うケースは、ソフトウェア開発に限った話ではありませんが、製造業であるソフトウェア開発においては『見積もり』というタスクは様々なケースで登場します。 見積もりが苦手な人は多い ソフトウェア開発では、「この機能を開発するときにどのくらいで完成できますか？」といったケースが見積もりのシチュエーションとしては多いかと思います
プログラミングで一番難しいのは「見積もり」だと思う - Qiita
前書き プログラミングで一番難しいところの一つは、「見積もり」だと私は思う。人から頼まれてプログラミングをする時、必ず最初に聞かれるのが「だいたいどれくらいで終わるか？」だ。厳しいところだと「何日に納品してくれるのか？」を問われる(むしろこれが普通かもしれない)。まっさらな状況から過去の経験を総動員してかかる時間を予想したり、可能な限りタスクに分解して時間を見積ったりするが、いつも不安に駆られる。多くの人も、見積もりに対して困難と不安を感じているのではないかと思われる。見積もりに対する自分の知識と経験を話して他の人にも参考にしてもらいたいと思って記事を書いた。 見積もりという言葉には色々な意味を含むが、今回の記事では「プロダクトをリリースするまでの期間の見積もり」から「頼まれた一つの機能の完成させるための期間の見積もり」までのスコープで話をしたい。 なぜ見積もりをしないといけないのか？ 見
まだまだ研究者の皆様へ
2016.12.11 いただいたローカルルールのほんの一部です。ローカルルールではなく、役所の問題も数件あります。 学会関係 東北大学 海外学会の参加登録費に一括して含まれている懇親会・ランチ・バンケット代を研究費から支出できない。 東京工業大学 国際学会などに昼食が含まれていれば、日当から千円が差し引かれるため、参加費に昼食代が含まれているかどうかを確認しなければならない。提供されていないときは、昼食代が含まれていないことを証明するものを提出させられる。学会のときは全て千円を一律に差し引くという対応をお願いしても、それはできないといわれる。 東京工業大学 確かに学会に参加したという証拠のために、学外2名の出席者か代表者にサインをもらう必要がある。最近では学会の名札でも許されるようになったが、証拠書類として学会の看板と写真を撮らねばならない。 物品購入 理研 研究に関するクレジットカードは
先に相手の予算聞けよ
見積もり初心者の増田君にマジレスな。 先に相手に予算聞いて「う～ん、２００万ぐらいかな～」って言ってきたら、それに合わせて見積もり作れ。 簡単な要求でも２００万円分の機能をつけてやればいいし、難しい要求なら２００万円以内でできる仕様にすればいい。 これができれば見当違いだったり桁違いの見積もり出して大失敗することはないし、確度はかなり高い。 ある程度精度のある見積もりを作った方がいい。 要求仕様だけ見せてきて予算を言ってこない場合は「降り」 これは発注先が決まっていて、社内でちゃんと相みつ取った証拠に使われるだけで完全に無駄な労力になる。 出すならバカ高い金額で適当に作った見積書出しておけ。 マジなコンペも「降り」 零細企業は5分の1とかのコンペに付き合ってる暇はない。 金額は限界まで下げないと取れないし、仮に取れても要求仕様も期間も厳しくなってデスマーチ確定。 無理しすぎたせいで納期内に
ウェブ制作の見積もりを金額付きで晒してやろうじゃないか！
はい高いですか？こんなもんですか？以下見積もりの説明です。 リニューアルと言っても、既存サイトはCMS化されておらず、たいして情報もアップされていなかったため、ほぼほぼ新規案件に近い、というイメージです。そのため、旧システムからのデータ移行費用が入っていません。その代わり、商品データベースは既存のものがあり、定期的にそこからデータを吸い出してCMS側の商品ページに反映するというカスタマイズが入っています。色々調査した結果、1週間でできそうという見込みのもとに見積もりしていますが、この要望はなかなか軽く収まらないことが多いですね。 コンサルティング費用にどのくらいかけるかというのはサイトの規模感によってまちまちだと思いますが、誰に向けたサイトで、何の目的で、対象となる閲覧環境は、用意するサーバーは、考えられるリスクは、など細かく資料に起こしていき、事前に複数回クライアント往訪のうえ打ち合わせ
フリーランスのweb屋な人が、見積や注文書、請求書を発行する際のポイント。 | たけろぐ
要所要所で追記してます。 フリーランスのweb屋な人が、仕事をする時の書類の流れとポイントをまとめてみました。 ざっくり言うと、 見積書発行→注文書発行→お客さんが注文書返送→納品→請求書&納品書発行 という流れです。 「ここまで書いちゃう？」的にけっこう書いてるので、 「そんなんわかってるよー」て方も、確認の意味も含めてご一読あれ。 ちなみにうちは「見積兼注文書」として発行しています。 また、後述しますが、納品書まで出すことはあまりありません。 書類の送付方法について まず基本的な、でも間違えると面倒な部分から。 各書類の送付方法は、 ・原本郵送 ・FAX ・PDF どれが可能なのか確認しましょう。 見積書や注文書と請求書で異なる場合があるので、必ず両方確認してください。 注文書はFAX・PDFでよくても、請求書は原本という所がたまにあります。 また、請求書を送る場合は、現実的に郵送のみ
Web制作の見積もりの出し方について改めて考えてみました。 │ モノづくりブログ 株式会社8bitのスタッフブログです
株式会社8bitのスタッフブログです。こんにちは。株式会社8bitの高本です。 最近見積りを作る機会が多く、「フリーランスのための全国Webサイト制作料金表まとめ25個」というまとめ記事をたまたま見ていて、Web制作における見積もりの適正価格と算出方法というものについて考えていました。 Web制作業界はフリーランスの方も多く、価格もそれぞれかなりの差があり、何を持ってして適正価格なのかもよく分からなくなってきています。見積もりの算出方法も異なります。 価格のばらつきもさることながら、Webサイト制作は実際にものがあるわけではなく、無形の状態から完全にオリジナルで作るわけで、お金を出して依頼する方も不安はあるかと思います。 結局、費用に対して割りにあった成果物があれば、依頼者は文句ないわけですが、見積もり段階ではどんなものが出来るのか頭の中にあるだけなので、見積もりが適正なのかも判断
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）
ソニックガーデン流 無駄のないシステム開発
cmmntr.com