ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
1on1ミーティングに備えるアンケート - しるろぐ
最近は、大体月一ぐらいのペースでメンバーと1on1ミーティングをするようにしている。 一人あたり30分から60分ぐらいで、前回のミーティングからの振り返りとその他相談を話す感じ。相談は仕事のことが主だけれど、プライベートな内容もある。 1on1ミーティングにあたって今年から事前アンケートを用意するようにしたのだけれど、そこそこいい感じに回っているのでまとめてみる。 事前アンケートを用意するメリット 話すことが事前に想定できる アンケート自体がアジェンダになるので、ミーティングがコントロール可能になる。 どんな話をするか分かっていると安心感もあるし、話が横道に逸れることもない（雑談は雑談で良いものだけど）。 その場で回答が思いつかなくて適当な返しになることがなくなる（お互いに） 自分の体験談なんだけど、何か質問をされたときにその場では「うーん、今は特に思いつかないです」と答えたのに終わってか
http://www.osushicompany.com/entry/2016/07/11/185035
For full functionality of this site it is necessary to enable JavaScript. Here are the instructions how to enable JavaScript in your web browser.
レガシーコードのテストを書いていくテクニック - Qiita
Symfony meetup #13 LT 発表 レガシーコードのテストを書いていくテクニック はじめに レガシーコードにテストを書くのはきつい。 頑張ってE2E書くか、fixtureを用意してDBを使ったテストをする （むしろそれしか方法がないぐらい） でもクリティカルなところはユニットテストで確かめながら開発したい じゃあ、ユニットテストどうするか？ レガシーコード改善ガイドを参考にする スプラウトメソッド 新しく機能を追加する場合には新しくメソッドを作る。そこにテストを書く ラップメソッド 新しく機能を追加する場合に既存のメソッドに手を入れず、ラップしたメソッドに機能を追加する 新しく書くコードなら テストできる ＼(^o^)／ スプラウトメソッドのサンプル 機能追加前 （レガシーコードはだいたいstatic…） // legacyなstaticメソッドはテストが困難 public
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
