設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
Scott Ambler と ソフトウェア開発のメタファについて話をした。：An Agile Way：オルタナティブ・ブログ
IBM の中でテクニカル的にアジャイルについての発言をしているのは Scott Ambler です。今日は彼と話すことができました。Agile@Scale のBofです。 BOFは４人でしたので、ひざを突き合わせて話をしましたが、そのうち一人は、Agileというコンセプトに始めて出合った人。その人の、 「ソフトウェアは工学的に作るようにようやく進歩してきたのだ。Agileはその歴史を、人側に逆戻りさせようというのか？」 という質問に、 「昔、太陽は地球の周りを回っていると思われていた。しかし、回っていたのは地球だった。これがAgileのパラダイムシフト。もしかしたら、後何年か先に、宇宙の中心がみつかって、そこを中心に回っていることがまた発見されるかもしれない。ソフトウェア工学はまだ40年しか歴史がないのだから。」 といい答え。さらに、 「建築や土木をソフトウェアのメタファと捉えるのではなく
Scaling Agile ... ソフトウェア開発をスケールさせる（大規模対応）：An Agile Way：オルタナティブ・ブログ
Agile開発はどうしても少人数での開発が多い。スタンドアップミーティングができる人数、つまり１ダースが１つの目安。また、ウォーターフォールなら大規模が成功するか、というと、ぼくはウォーターフォールの大規模開発で成功例を見たことがない。本当にソフトウェア開発はスケールさせられるのだろうか、という疑問もある。 ソフトウェア開発をスケールさせるにはどうしたらよいのだろうか。 別のドメインの似た例として、Webのサーバー側のシステムをスケールさせるには、２つの考え方がある。 ・scale up ... １マシンのCPUやメモリ、バス性能などをアップさせて、システムのパフォーマンスを上げる。 ・scale out ... マシンの数を増やして、システムのパフォーマンスを上げる。 scale up には限界がある。その時点のテクノロジの限界があるから。逆に scale out 作戦が成功するようなア
Ruby+Agile で誠実なソフトウェア開発を。：An Agile Way：オルタナティブ・ブログ
お客様に価値を継続的に提供できる、開発がやりたい。 価値を見て分かって触ってもらえる開発がやりたい。お客様の喜びが、開発者の喜びに直結する開発がやりたい。 こういうテーマで、永和システムマネジメントで技術者と管理者が議論しました。 誠実なソフトウェア開発を、 Agileに行うことで、顧客RoIと連動した開発を、 Ruby on Rails を使うことで初期コスト、変更コストを最小限に。 行いたいんです。このコンセプトを、ぜひ実装したい。一緒にやって頂けるユーザはいらっしゃいませんか。変化、にたいして、本当に敏感に反応できる開発ができる可能性があります。大きな投資を初期に決めてしまうのでなく、やりながら考えてくれるユーザ。 これが実現できるのは、変更を抱擁できる言語(Ruby)＋フレームワーク(Rails)＋開発プロセス(Agile)、そしてユーザと対話できる開発者側の会話力と共感力、そして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
