フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
優秀な外国人技術者を使い捨てるSIer
むかついているがどうにもできない。そのことにさらにむかついている。 背景俺は新卒で入ったSIerに勤めて数年になる。 うちの会社は社員数も売上高も数千の中規模SIだ。いつからかわからないが中国にも支社があり、現地の技術者を採用したりもしている。（こうした実績からグローバル企業を謳ったりもしている…） 新卒でも中国人を採用していて俺の同期には5人いた。 同期の中国人技術者の優秀さこの会社に入って最初の合同研修期間で彼らと接することになったのだがまずスペックの高さに驚いた。 まず3ヶ国語を扱える。中国語はもちろんネイティブ、英語はビジネスレベルで習得しており、個人差はあるもののみんな日本語での日常会話に支障はない。外国人に難しいとされる日本語の読み書きも、漢字をある程度知っているだけあってアルファベット圏の人々より習得が早いらしい。 全員バリバリのコンピュータサイエンス出身。 俺は文系学部出身
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
ソフトウェア開発プロジェクトを蝕む10の典型的な過ち
プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1．「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す
NTTデータ、3年間で社員1000人をアジャイル開発人材に育成
NTTデータとNTTデータユニバーシティは2012年4月17日、同社グループの主に入社3年から5年の若手社員を対象に、「アジャイル開発」と呼ばれるソフトウエア開発手法の研修を5月から実施すると発表した。今後3年間で約1000人のアジャイル開発人材の育成を目指す。 アジャイル開発とは、システムの仕様変更や機能追加などに臨機応変に対応できるよう、開発対象を小さい機能に分割して、設計や実装、テストを短い期間で繰り返していく開発手法のこと。米国IT企業のソフトウエア開発においては主流となっているものの、国内での採用はWebサービス業界やゲーム開発業界の一部企業にとどまっている。 今回、同社グループは、グローバルに展開する顧客企業をサポートできる開発体制を整備する目的で、グループ内におけるアジャイル開発人材の育成を始めた。研修では、アジャイル開発の代表的な手法の1つである「Scrum開発手法」のフレ
何故バグ報告の99%が役に立たないのかもしくは何故プロのテスターが存在するのか - oops
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
「どうしましたか？」「お腹が痛いんですけど…」「もっと詳しくおしえてください」「えっ、お腹が痛いだけですけど」「それでは診断できません」 - uzullaがブログ
医者「今日はどうしましたか？」 患者「今は落ち着いてるんですが、最近どうも腹痛がひどくて…」 医者「もうちょっと具体的に言ってください」 患者「そうですね、なんとなくシクシクと…」 医者「なんとなくとかいわれても困りますね、もっと具体的に現象を教えてください」 患者「えっ」 医者「たとえば、脇腹に針をさしたようにいたい、とか。みぞおちに重い鈍痛があるとか、具体的に」 患者「ううん、そうですね…みぞおちが痛かったかも…」 医者「かも！？」 患者「みぞおちがいたいです！刺すように！」 医者「みぞおちがいたい、刺すように、なるほど（カリカリ」 患者「どうなんでしょう…胃炎とか…」 医者「素人が症状を断定しないでください」 患者「すみません…」 医者「今の症状はわかりましたから、どこで、いつ、どうやったら腹痛になったか、状況を詳しく、順番に教えてください。まず痛くなったのは何時何分何秒で、その何分
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根本的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Excel 方眼紙撲滅委員会 活動報告 2012.11 #odstudy