失敗しない情報システム調達 - 顧客の視点で、アジャイルを説明
失敗しない情報システム調達 - 顧客の視点で、アジャイルを説明 目次 はじめに 気をつけろ！ 目的を明確にしよう 予算を明確にしよう システムの初期仕様で契約するのはやめよう 決定権を持った人を担当にしよう 絶えず監視しよう 現物で報告させよう 定期的に短期間で報告させよう ふりかえらせよう 早く稼動させよう 開発技術を身につけよう 良い人を演じよう 信じよう コメントお待ちしています 顧客の視点で、アジャイルを説明 はじめに この文書は、情報システムを調達するときに、情報システム開発会社（以下、「やつら」と略記）から不当に搾取されないように、気をつけることや、予防策について書いています。 よく読んで、情報システムの調達に失敗しないようにしてください。 この文書が、読まれた方のご参考になれば幸いです。 気をつけろ！ 目的を明確にしよう なぜ、その情報システムを必要としているのか、その目的を
仕様明確化のためのプロトタイピング - 酔狂人の異説(新館)
プロトタイピングの一種だと思うが、「現物主義」というのが、話題になっている。 http://d.hatena.ne.jp/yamaza/20050620#p2 http://www.programmers-paradise.com/tdiary/?date=20050627#p01 http://amrita.s14.xrea.com/d/?date=20050629#p05 http://www.alles.or.jp/~spiegel/200506.html#d29_t3 http://www.programmers-paradise.com/tdiary/?date=20050629 http://d.hatena.ne.jp/emeitch/20050630/1120147602 http://www.mimori.org/~h/tdiary/20050630.html#p04 仕
Martin Fowler's Bliki in Japanese - 生産性は計測不能
http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし
開発プロセスの功罪 - カレーなる辛口Javaな加齢日記
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Swebok に尽きるかな．ウォーターフォールモデルとかPMBOKとかCMMとかCMMIとかRUPとか，その手の「何とか標準」などは大抵は論外だ．そう言ったものが「役に立つ」「きっと適用できる」と主張する人達もたしかにいる．しかし面白いことに奇妙な偶然が見られるのだ．役に立つと主張する人はソフトウエア開発経験が全く，或いはほとんどなく，下手をすると"hello world"さえも書いたことが無い*1．逆に優れた開発者で役に立つと主張する人はまずいない．なんとも奇妙な偶然だ． 以前，とある企業の方々と話をしたが，彼らは興味深い意見の持ち主だった．書類重視でウォーターフォールモデル，低レベルプログラマの大量投入による大量生産．おそらくは『上流行程神話』の信奉者．品質もメンテナンス性も全てドキュメントでなんとかし
XPユーザ会のこれから - t-wada の日記（旧）
清水川さんがレポートを書いて下さいました。必見です。やっぱり参加してみたかったです。機械猫モッカーもすごく興味があったので。残念です。 私はスタッフのくせに結局今回のXPユーザ会に参加できませんでした。 参加してもらったプロジェクトメンバー、清水川さん、kikainekoさん、mixiの中、いくつかの話しを総合すると、今回は初めて参加する方が多かったようです。そして、どうやら初参加の人には少し難しく感じた人もいるようです。悩ましい問題だと思います。 今、XP、アジャイルは「やってます」という人と、「やってみたいけど」という人に分かれ、その差が拡がってしまっているのではないかという悩みがあります。そして「やっています」という人の数も、「やってみたいけど」という人の数も、アジャイルが有名になるにつれ共に増えているという手応えがあります。 「やっている」人の問題意識と「やってみたいけど」という人
スクラム組んで開発しよう！ | オブジェクトの広場
今回の記事では, プロジェクト管理に特化したアジャイル開発手法であるスクラムの概要を説明します. また, スクラムによる開発が成功する理由を説明するための理論的なバックボーンとして引用されている知識創造プロセスやコンテキストの概要を紹介します. さらに, 20 名程度の中規模開発チームにおいてスクラムを適用し, 開発に成功した事例を紹介し, その中で知識創造プロセスやコンテキストが生まれたのか否かについて考察します. 1. スクラムとは 1.1 スクラムの価値と理論的な基盤 スクラム [1] は, Ken Schwaber と Mike Beedle によって考案されたアジャイル開発手法です. スクラムという開発方法論の名称は, ラグビーのスクラムにちなんで名づけられたそうです. スクラムは、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたとされています.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
