エンジニアの「できない」という言葉の裏側 - Konifar's WIP
「ここ、こんな感じにできませんかね？」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか？」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「（できるけどやり
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
ついに登場！ 究極の見積もり技法（その2：実践編）
ついに登場！ 究極の見積もり技法（その2：実践編）：山浦恒央の“くみこみ”な話（39）（1/2 ページ） 「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回はSLIMのソフトウェア開発関係式を実際に使用し、工数（コスト）、開発期間（月）、機能総量（規模）、（プロセス）生産性の具体的な算出法（Excelによる算出）を解説する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的
規模見積もりの女王様「FP見積もり」【後編】
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、計算手順が30分で理解できて、システムの分析やFP計算も1～2時間程度で可能な「FP試算法」について説明する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は、積み上げ法の代表である「FP（Funct
規模見積もりの女王様「FP見積もり」【前編】
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、積み上げ法の中でも、少しアカデミックな雰囲気のある「FP（Function Point）」による規模見積もりについて解説。まずは、FPの概要・特長を理解しよう。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます
規模見積もりの王様「LOC見積もり」 ～見積もりの基本技法 その2～
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回から世界のソフトウェア開発プロジェクトで最も頻繁に使われている積み上げ法による見積もりを紹介。まずは、規模見積もりの王様「LOC見積もり」について。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回、“勘・経
勘・経験・度胸による「類推法」 ～見積もりの基本技法 その1～
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、見積もりの3つの基本技法のうち「類推法」について取り上げ、その概要とメリット・デメリット、利用時の注意点について詳しく紹介する。 「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 今回は、3つの基本的な見積もり方法のうち、「類推法」を取り上げます。 KKDと「機能要件」「非機能要件」「性能」の見積もり
【引っ越し】覚えておきたい引越のテクニックを教え合おう！！ スレ21【就職・転勤】 : えっ!?またここのサイト?
提供元:【引っ越し】引越のテクニック 21【就職・転勤】 http://yuzuru.2ch.net/test/read.cgi/kankon/1288641322/ 1：おさかなくわえた名無しさん：2010/11/02(火) 04:55:22 ID:MPr+/nIj 引越しに関しての質問をしたり、経験談を語るスレです。 引越し費用の相場の相談は、多分誰かが教えてくれます。 でも、質問する前にテンプレくらいは見たほうが良いかもしれませんよ～。 引越し業者サイト・業者選び・値引きの方法とか >>2～10ぐらい ■ 引っ越し業者 >>2 ■ 見積もりについて >>3 ■ 一人暮らしの場合 >>4 ■ 選び方 >>5 ■ 引越し屋を選ぶコツ >>6 ■ 知っておくとよいこと >>7 ■ 最後は直感 >>8 ■ 値引きの仕方 >>9 ■ おまけ >>10 2：おさかなくわえた名無しさん：2010/
特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
アジャイル開発/見積もり方法 - TOBY SOFT wiki
2020-06-02 Comments/Subversion/TortoiseSVNメモ/コミットしたログメッセージが編集できない 2020-03-31 ゲームを作る上でのバッドノウハウ/十字キーがボタンとして認識される 2019-11-12 Comments/Wiki/PukiWiki/スパム(spam)を防止する方法 2019-11-01 Delphi/XML/Delphi付属のXMLライブラリ 2019-08-27 Comments/SaGa2 秘宝伝説/モンスター一人クリア 2019-07-11 Comments/git/git rebaseを元に戻す方法 2019-06-08 VBA/関数呼び出し時に「オブジェクトが必要です。」というエラーが出る 2019-03-07 Comments/PhotoShop/「下のレイヤーとグループ化」はどこいったの？ 2019-02-06 Rub
アジャイル開発の見積もりとリスク
ここ３年ぐらい同一案件のアジャイル的な開発をやっているのですが、 見積もりについて経験則がまとまってきたので整理してみたいと思います。 まず、前提として以下のような作業を請け負っています。 顧客の要望を聞いて要件開発を行う 要件を元にシステムの設計を行う 設計を元にプログラムの製造を行う テストを行う 運用時に発生した障害の調査 開発は１期のスパンが２か月～３か月程度で、 開発した機能のリリースを行いながら順次機能拡張していくといった感じになります。 作業の見積もりはその作業の種別により分類されます。 建築での比喩で表現すれば、大きく分けると設計図面を引く前と引いた後です。 これに加え、突発的な飛び込み作業があるので、以下の３つに分類しています。 設計図面を引くまでの作業 引いた図面をもとに開発する作業 突発的に発生する作業 そして、それぞれの作業ごとに不確定要素（リスク）が存在します。
ビジネスアプリ開発者のための機能規模測定手法COSMIC法入門（第1回） | オブジェクトの広場
ソフトウェアの規模をどのように測るかというのは従来から白熱した議論が展開された領域ですが、未だに１つの決定的な方法に収束していません。収束しない一因は、ソフトウェアの規模の測り方がこれまであまりオープンに紹介されてこなかったことにあるのではないかと筆者は考えています。このような状況に一石を投じようと、本連載ではオブジェクトの広場の読者のみなさんのようにモデリングの心得がある人を対象にして、モデルを作ってソフトウェアの規模を測る方法の 1 つである COSMIC (COmmon Software Measurement International Consortium) 法を紹介します。 COSMIC 法は、元々組み込み用のソフトウェアの規模を測るための方法として提案されたものですが、ビジネスアプリケーションの規模測定にも使える方法です。今回の記事では、規模を測定する目的と規模を測定する複数
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スマホアプリ開発の見積もりで気をつけたいいくつかのこと
そのプロダクトを作るのにどれくらい時間がかかるのですか？
会長@腹部日記(2011-08-16)