Practices of an Agile Developer -- よいプログラマの習慣：An Agile Way：オルタナティブ・ブログ
「アジャイルプラクティス」、読んだ。よかった！ もしあなたが、開発者としてアジャイルでありたい、と思っているのであれば、必ず読んで欲しい。「アジャイル」は方法論ではないし、プロセスでもない。あなたが明日から始められる「習慣」と「心構え」なんだ。 ■ アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 http://www.amazon.co.jp/dp/4274066940/xpjp-22 この本は、アジャイル開発、の本ではない。アジャイル開発の手順を解説なんてしていない。そうではなく、「あなた」が開発者としてアジャイルでありたいならば、こういう習慣を身に着けよう、と言っている。あなたは「気持ちよく」納得した感情で開発をしたいだろう？誇りをもって、自分自身とチームが書くコードが高品質である、と言いたいだろう？顧客に価値を提供している、と言いたいだろう？ たとえば、本書では、あるプ
ODD - おもいやり駆動開発：An Agile Way：オルタナティブ・ブログ
思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
XPは第二版になって過激さを失ったか？：An Agile Way：オルタナティブ・ブログ
ちょっと長いが、今朝のKent BeckのXPメーリングリストへの投稿を引用、要約したい。このメールは、「XPは第二版になって、その過激さを失った」というスレッドへの回答になっている。 RE: [XP] Do it by the book Wed May 2, 2007 1:32 am XP2nd になってXPは「ダイヤルダウン」した、という意見をよく聞く。1stよりソフトに、柔軟になったといわれるのは嬉しいことだ。2ndが攻撃性を欠いているのは意図的だ。ぼくのゴールは、「価値」(value)を基礎にした「原則」(practice)を活用することで、できるだけアジャイルになること。「実践項目」(practice)のチェックリストを作ってしまっては柔軟性を失ってしまう。実践項目は外的要素との重ねあわせだ。価値と原則に沿って行動することで柔軟性が増すが、自身が意識を持つことが必要だ。よい考えを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
