Martin Fowler's Bliki in Japanese : 更新日時順
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?c=recent
Martin Fowler's Bliki in Japanese 更新日時順jaCopyright (C) kdmsnr2010-02-07T12:59:52+00:00対話的ストーリー
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ConversationalStories
2010-02-07T12:59:52+00:00@@ -30,7 +30,7 @@
//In terms of coming up with stories, what this means is that they are always something to be refined through conversation - and that developers should play an active role in helping that definition.
//* spotting inconsistencies and gaps between the stories
@@ -46,7 +46,7 @@
これが、Bill Wakeによるストーリーの[[INVEST|http://xp123.com/xplor/xp0308]]試験の1つ、Negotiable（交渉可能）の原則だ。
アジャイルチームのメンバーは誰もがストーリーを作成したり、修正を提案したりできる。
-ほとんどのストーリーを一部のチームメンバが書くことになるかもしれない。
+一部のチームメンバーがほとんどのストーリーを書くことになるかもしれない。
ただそれは、チームがどうしたいかによるものであり、チームの自己組織の判断次第である。
しかし、チームメンバー全員がストーリーを作り、洗練していくことに携わるべきだ。
（ストーリーの見積りに加えて、これも開発者の責任のひとつだ）]]>命令的ストーリー
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DecreedStories
2010-02-07T10:12:20+00:00@@ -1,3 +1,5 @@
+[[http://martinfowler.com/bliki/images/conversationalStories/decreed.png]]
+
//An approach where stories are written by product owners or analysts and passed to developers to build. I see this as a profound misunderstanding of agile thinking and thus greatly prefer ConversationalStories.
//For me, one of the key features of agile methods is that they are PeopleOriented. They recognize that people and how they work together is the primary factor in software development, and that processes are a secondary factor. This is reflected in the first value of the agile manifesto "Individuals and interactions over processes and tools" and is reinforced by two principles of the manifesto:
// Another situation that we are usually in at ThoughtWorks is where we are on a co-sourced project with a client team. In most of these situations we are responsible for the delivery of the software but we need to work with client staff in order to provide a good handover and so that the client people can learn about how we work. In this situation we are being paid to be as effective as we can be, so we'll use a process that works for us. This doesn't mean we don't tailor the process to the client's environment, that's always necessary, but there is a tricky line between sensible tailoring and abandoning the practices that make us successful.
@@ -85,6 +85,6 @@
こういった類の問題は必然である。
私はオブジェクト指向とその他オブジェクトほげほげみたいなよく分からないものが流行したことをハッキリと覚えている。
新しいものが受け入れられる過渡期では、これはごく普通のことだ。
-アジャイルではないものに「アジャイル」という名前がつくことを防ぐことはできない――RigorousAgileを取り締まる「アジャイル警察」はいないのだ。
+アジャイルではないものに「アジャイル」という名前がつくことを防ぐことはできない――[[RigorousAgile]]を取り締まる「アジャイル警察」はいないのだ。
我々にできることは、アジャイルが本当に意味することを説明できるよう、日々心がけることである。
「説得」ではなく「説明」しよう。]]>ThoughtWorksでのRuby
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RubyAtThoughtWorks
2009-12-03T20:33:44+00:00@@ -577,3 +577,4 @@
//While we can't claim any big part in Obama's internet triumph, a number of ThoughtWorkers were involved in writing software for the Obama campaign [1]. I popped in occasionally to see how things were going along and got quite interested in the way software was being used in the political process. I was keen to see more said about this and at QCon London in 2009 my colleague Zack Exley and I gave a keynote about the role of software in Obama's victory.
//Changing the Organizational Dynamics of Campaigns
@@ -121,7 +121,7 @@
//A peer-to-peer approach like this creates great energy amongst individual volunteers, often engaging people who aren't likely to get involved in a formal campaign. But it lacks direction - in the Dean campaign, this became evident in Dean's surprisingly low 4th place finish in the Iowa caucus (the first of the primary contests). This leads us to the mass-organization model, which, thanks to the internet, was developing in parallel with the peer-to-peer model.
[[http://martinfowler.com/articles/obama/massOrg.png]]
@@ -153,8 +153,8 @@
//Weaving in the mass-organization model, the key difference is that the process can be kicked off by the campaign leadership. They can decide that they would like to see a coordinated push to discuss health care over the next couple of weeks. So they suggest to volunteers that they may like to try and organize meetings around this. They may provide catalysts such as articles to read or DVDs to watch. This creates a buzz around the topic that makes it more likely that meetings get set up. This buzz reaches out to potential attendees as well who are now more likely to try and find local meetings on the topic.
@@ -351,10 +351,10 @@
//The VAN helped this work by allowing volunteer organizers to make walk packets and run canvasses from home. Volunteers' homes became campaign offices and "staging locations" for canvasses and phone banks. Using The VAN made all of this both easier to learn and quicker to do, both of these are important to allow volunteers to do the organizing since they tend to be short of experience and time. Furthermore the access to data allowed the staffers to keep and eye on what was going on so they could collaborate effectively with the volunteers. Agile software people like me argue that open access to project plans enable everyone to get involved - which both boosts both the effectiveness of the planning and the motivation of those doing the work. Opening up the planning of canvassing is a similar notion for volunteers.[10]
//Agile software people like me argue that open access to project plans enable everyone to get involved - which both boosts both the effectiveness of the planning and the motivation of those doing the work. Opening up the planning of canvassing is a similar notion for volunteers.[10]
//More important than duplicating the door-to-door aspects of The VAN, Neighbor to Neighbor added the capability to support phone canvassing. Phone canvassing is particularly important in a presidential election since candidates take states on a winner-take-all basis. There's little point for democratic supporters in Massachusetts to canvass their neighbors since Massachusetts was a safe win for Obama.
@@ -422,8 +422,7 @@
//Much of the attention to the role of software in Obama's campaign focused on new web tools. Yet perhaps the most important part of the software toolkit was the mailing list. By the end of the campaign some 13 million people had added their email addresses to the campaign's email list. The challenge was to compose, send, and log all these emails so that an email ask could be sent out to the whole list within a few hours. More targeted asks [12] could be sent out on subsets of the list as well.
@@ -506,7 +505,6 @@
//Another way of looking at the change over the years was the number of campaign staffers focused on the internet. For Gore in 2000 it was just a handful, for Kerry in 2004 it was 60-70, while for Obama it was a few hundred.
//3: Blue State Digital
//Blue State Digital have turned into a considerable organization over the last few years, with over a 100 clients internationally. Indeed their success as a commercial organization has been a source of controversy, as many political software activists consider their publicity about their role in Obama's victory to have been excessive.]]>即興トーク
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ExtemporarySpeaking
2009-08-19T04:38:42+00:00@@ -0,0 +1,30 @@
+http://martinfowler.com/bliki/ExtemporarySpeaking.html
+
+2006/8/18
+
+Jon Udellが講演のやり方について[[2つのモデル|http://weblog.infoworld.com/udell/2006/04/09.html]]を挙げていた。
+
+* 原稿付き：話す内容を正確に書いておき、それを読み上げたり、暗記したりする方法。
+* スライド駆動：詳細なスライドを元に話を進めていく方法。
+
+私はというと、3つ目のモデルを使用している――即興スタイルだ。ラフなアウトラインを元に話し始め、話しながら内容を構成していく。
+
+私は原稿付きの講演はやったことがない。スライド駆動方式は長いことやっていたが、箇条書きのスライドはもう飽きた。スライドを見て話す内容を思い出すことができるのはいいが、逆にスライドに縛られているみたいでイヤになった。スライド駆動だと、事前に――カンファレンスの何ヶ月も前に――話す内容を決めておかなければならない。最初からスライドがなければ、内容がスライドに沿っていなくても誰も文句は言わない。だから私は、話す時に自由に内容を決めることができるのだ。
+
+だからといって準備をしないというわけではない。話のネタはちゃんと用意して、頭にしっかりと叩き込んでおかなければならない。私の場合は、人生是即ち準備なのである。
+
+具体的に言うと、私は事前にアウトラインを作っておくことが多い。インデックスカードにラフなアウトラインをスケッチしておく。こうして、おおまかな話の構成を作っておく。
+
+[[./img/railsCard.jpg]]
+
+これはRailsConfで使ったインデックスカードである。（字がヘタな件については /dev/null に捨てておくれ。私はいつも我慢してるんだから。）
+
+[[Tony Benn|http://en.wikipedia.org/wiki/Tony_Benn]]から来た人が教えてくれた非常に役に立っているTipsがひとつある。それはポイントを3つ入れるというものである。各ポイントにはさらに3つのサブポイントを入れる。これは話の構成を決めるときにいい出発点になると思う。
+
+このやり方は基調講演ではうまくいっている。私が近頃よく頼まれるのは、この基調講演である。ある程度詳細な技術の話の場合は、コードサンプルや図を載せるためにスライドを使う。ただ、基本的にスライドはほとんど使わない。使うとしても、アウトライン程度のものだ★――ただし、事前に用意する。
+
+即席トークなら、話す数分前に内容を決めることができる。カンファレンスならば、どんな感じでやるか、どんな風に話すかを、トピックを決める前に掴んでおきたい。もちろん、まだラフな感じにしか決めてないので、実際に何を話すかは決めなくてはいけない――あとは話すだけだ。
+
+この方法だと、引用されるときに困る。文章を書くのであれば、できるだけ明解に書くよう注意することができるが、即興で話すと誤解を招く恐れがある。観客が限られていればあまり問題ではないが、インターネットで配信されるとなるとそりゃもう大変だ。だから著名人は即興で話したがらない。非常に残念なことだ。
+
+この方法は必ずしも万人向けのものではない。心地よいと感じて実際にやってみる人もいるだろうし、そうでない人もいるだろう。私の場合は、これが自分のスキルのひとつであってラッキーだったと思っている。この方法は自然さとエネルギーを引き出すことができる。 IT系のカンファレンスでよく見かける山盛りのPowerPointはもちろん、メディアで見かけるお上品な原稿付きのトークとも、いい意味で、まったく違ったものなのだ。]]>Web2.0
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?Web2.0
2009-08-19T04:20:55+00:00@@ -0,0 +1,34 @@
+http://www.martinfowler.com/bliki/Web2.0.html
+
+2006/12/14
+
+ここ数年、Web2.0はその概念と[[Neologism]]としての価値について、大いに議論されている。これまで私はこの件についてあまり関わってこなかった。 Tim O'Reillyの意見を見聞きしたり、彼がオーガナイズしたワークショップに参加したりといった程度でしかない。巷では多くの混乱が見られるようだが、ここはひとつ（無駄かもしれないが）私なりの意見を述べてみることにする。（大部分はTimの言い分を私なりに解釈し直したものなので、賛同できない点があったら、Tim本人の言葉を信じるようにして欲しい）。
+
+Web2.0の議論でよく混乱が起きてしまうのは、それが何なのか知らないままに話そうとしているからである。まずはWeb2.0が登場した2004年から話を始めよう。
+
+""「Web2.0」という概念は、O'ReillyとMediaLive Internationalによるブレインストーミング・セッションから生まれた。Webのパイオニアであり、O'Reillyでバイスプレジデントを務めるDale Doughertyは、ウェブは「崩壊」したどころか、かつてないほど重要な存在となっており、刺激的な新しいアプリケーションやサイトが驚くほど着実に生まれていると指摘した。また、バブル崩壊を生き延びた企業には、いくつかの共通点があるように思われた。{{br}}--[[Tim O'Reilly|http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html]]（訳注：[[CNETによる翻訳|http://japan.cnet.com/column/web20/story/0,2000055933,20090039,00.htm]]を参考にした。）
+
+これはWeb2.0における[[決定的な論文|http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html]]からの引用だが、非常に意味深いものだ。「Web2.0」という用語は、WWWにおける現在進行形の変化を指している。この変化こそがWeb2.0の本質である。
+
+非専門家――つまり、普通の人々――にとって、「Web2.0」とは、インターネットで新しい何かが起こるということだ。新しい何かとは、MySpaceやYouTube、そしてFlickrといったポピュラーなサイトの登場、またblogなどの急増といったことである。オンライン上で、みんなが何かを作ったり、共有したりすることもそうだ。これは流行であり、現象なのである。[[Nicholas Carr|http://www.roughtype.com/archives/2006/12/the_semantics_w_1.php]]
+
+Timは流行に名前を付けただけではない。彼がWeb2.0について議論しているのは、この流行を理解しようとする試みなのだ。この新しいWebの世界で成功するものはどんなものなのかといった点に彼はフォーカスしている。彼の論文はほぼこの点について述べられている。そして、Web2.0の7つの原則を挙げている。
+
+----
+
+:プラットフォームとしてのWeb(The Web As Platform):デスクトップコンピュータ上で稼動するソフトウェア（Netscapeなど）ではなく、Web上のサービスとして稼動するソフトウェア（Googleなど）
+:集合知の利用(Harnessing Collective Intelligence):少人数のエキスパートからではなく、多数の人たちから情報を集約する（Amazonのレビューワコミュニティ、Googleがリンクを検索アルゴリズムに使用している例など）
+:データはネクスト・インテル・インサイド(Data is the Next Intel Inside):専門的なデータベースを保有する（Amazonの商品データベース、NavTeq?の地図データ）
+:ソフトウェアリリースサイクルの終焉(End of the Software Release Cycle):新しい機能を絶えずリリースする（Flickrは新しいビルドを30分ごとにデプロイしている）。
+:Lightweightプログラミングモデル(Lightweight Programming Models):シンプルな開発環境は消費者が再利用しやすい（Googleのシンプルな地図インタフェース）
+:単一デバイスのレベルの上のソフトウェア(Software Above the Level of a Single Device):多くのデバイスがWeb上で一緒に動く（iTunesとiPod）。
+:リッチなユーザー体験(Rich User Experiences):ユーザーインタフェースがより動的になってくると、Webとリッチクライアントのギャップが小さくなる
+----
+
+これらの原則が「規範的」なものではなく「記述的」であることが重要だ。 Web2.0がどういったものであるかを示したものではなく、何がWebサイトを成功させるのかというTimの考えを示したものなのだ。それに、Web2.0が意味することを理路整然と記述してある。 Web2.0とは意味のない言葉だと言ってる人をよく見かけるが、 Timの論文を読んだのかと問いたい。
+
+「Web2.0は良いジャーゴンではない」というNicholas Carrの[[意見|http://www.roughtype.com/archives/2006/12/the_semantics_w_1.php]]には賛成だ。なぜなら「専門家が皆同様に明確に意味を理解しているか」というテストに失敗しているからだ。しかし、明確に理解できないのは、[[SemanticDiffusion]]の必然的なプロセスである。理解が完全になることもないし、それを阻止することもできないのだ。
+
+よくある間違いは、Web2.0とは全く新しいものだと思うことだ。 Web2.0を支える多くの考えは、実はとても古く、以前からWebで使われていたものだ。たとえば、AmazonのコミュニティやWikiの利用がそうだ。以前は利用者が少なかっただけなのだ。 Web2.0へのシフトとは、90年代にあまり使われなかったものが今になってメジャーになったというものなのだ。
+
+Web 2.0という言葉によって参照されている根本的な変化とは、重要かつリアルなものだ。その点で、Web2.0の概念は健全であるといえる。「Web2.0」という言葉がこの概念を表すのに相応しいのかという議論もあるだろうが、すべての人を満足させる用語などないし、すでに定着してしまったので、この点についてはすでに議論の余地はないだろう。それよりも議論として面白いのは、これらの原則がこの現象を正しく表しているか？という点だろう。これらの原則と合わせて、パターンやプラクティスについてより具体的に議論することができるのだ。こうした議論はTimがやりたがっていたことであり、私も興味のあることである。]]>