経験主義的アジャイル思想

アジャイルな人生、性格、人生観、思想、実践哲学。一連の議論を通じて「経験主義アジャイル(Empiric Agile)」という言葉を獲得。暫定的にこの名前を使う。 経験主義アジャイル:経験主義(設計しすぎない)、目的中心主義(目的のために手段を選ばない)、現実主義(計画しすぎない)、現物主義(WebサーバとHTMLが中心)、信頼とコミュニケーション(資料をなるべく作らない)。 前提:この議論では「新規事業としてのウェブサービス」を前提しており、とくに新規事業立ち上げの不確実性とそれに対処するためのプロセスや行動規範を前提としています。「意図的」では無く「創発的」な戦略策定プロセスのマネジメント。
17
前へ 1 2 ・・ 7 次へ
石橋秀仁 @zerobase

自分の計画能力や設計能力を信用しないというか、懐疑的であるというか、自分の限界を知った上で身の丈の計画・設計の範疇で、手を動かして、作って、分かっていくプロセスが、アジャイル。ゆえにソフト開発の文脈など、どうでもいい。アジャイルはデザインのプロセス。

2010-10-22 01:35:27
石橋秀仁 @zerobase

RT アジャイル開発の本質とスケールアップ http://togetter.com/li/59973

2010-10-22 01:36:21
石橋秀仁 @zerobase

RT アジャイルという経営マター・政治マター http://togetter.com/li/56997

2010-10-22 01:36:33
石橋秀仁 @zerobase

RT 短納期×仕様書無し×信頼関係=アジャイル http://togetter.com/li/43372

2010-10-22 01:37:30
naoki ando @threepennie

@zerobase アジャイル開発の費用ってイテレーションごとに請求する契約でやってるんですか? 年度予算が当初に決まってる中で、増工分をどうしているのか興味あります。

2010-10-22 01:40:57
石橋秀仁 @zerobase

なぜアジャイルか?→作ってみないと分からないから、作る。実験して学習(失敗)する。同じ時間で何回学習できるか。それを突き詰めるうえでアジャイルが現在知られる唯一の有力な解。つまりデザインからの要請としてのアジャイル。

2010-10-22 01:42:14
石橋秀仁 @zerobase

"そもそもアジャイルが個人の幸福感やワーク・ライフ・バランスの文脈で語られるのは間違いでしょう。それらは組織マネジメントの問題であり、開発手法の問題ではないからです。この混同は現場への責任転嫁です。" http://tumblr.com/xfimlvyua

2010-10-22 01:44:05
石橋秀仁 @zerobase

『橋はなぜ落ちたのか』にアジャイルのヒントがあるかも、と思って再読しようと思ったら、手放してた。三度目の購入w

2010-10-22 01:47:04
わたべきみよし @watouch

だいたいの場合、後者かなぁ RT @zerobase 受託アジャイルの場合、お客さん=担当者はどういう人がやりやすいか。すごく分かってて勉強してて明日から受託側でやれるレベルの人か、まったくの素人で「なんとかしてください」と丸投げされるか、のどちらか。

2010-10-22 01:49:55
HiroIzumo @HiroIzumo

@zerobase 教科書を全部読んでから問題を解くよりも、章ごとに区切って何回も問題を解く方が成績があがると思うけど、それと同じような気がします。 規模が大きくなりすぎて管理のオーバヘッドが大きくなるのも問題かもしれません。

2010-10-22 01:52:10
Rio Joraku @joraku

大規模なプロジェクトでアジャイルする場合には優れた PM と Architect が必須。でないと発散するかグダグダになる。昔 500 人月超くらいのプロジェクトでアジャイルしたことがあるけど、その時ほどグダグダで、工数の無駄遣いをしてるなと思ったことはなかった。

2010-10-22 01:54:11
わたべきみよし @watouch

能力?先見性?が低いとウォーターフォールしか知らない罠。泥沼化 RT @zerobase 発注側のWF/アジャイルの適性・性格の相性とかもあるけど、基本的にはWFのほうが発注側担当者の能力が高くないと難しい。WFの発注者には、設計図から完成像を読み取ってジャッジする能力が必要。

2010-10-22 01:57:56
石橋秀仁 @zerobase

@threepennie 場合によりけりですが、例えば:by-nameの時間単価×期間×コミット率の見積りで契約したうえで、超過分は信頼ベースの事後請求とか。でも1次開発は成果物ベース見積の請負契約とか。わりと柔軟にやるし、柔軟にやれるお客さんでなければ難しいかなーと。

2010-10-22 02:00:30
Rio Joraku @joraku

ウチは自社サービスの開発ではウォーターフォールとアジャイルの組み合わせ。要件定義や基本設計くらいまでをウォータフォールで、デザインやシステムの実装をアジャイルで、というのがほとんど。経験的にはこれが一番うまく行くし速い。

2010-10-22 02:02:26
Kazuma YONETANI @4EX

@joraku さすがにその人数ではグダグダになりそうっすねぇ…

2010-10-22 02:02:35
Kazuma YONETANI @4EX

@joraku 僕も基本的にはその考え方です。大まかな方針を見い出すところまではある程度順序立てて落としこむ必要がある。ただしそれはあくまで多くの案件の初期段階で関係者の合意形成のために必要になプロセスであって、全員が7、8割描けたらそこから手を動かしてよいと思います。

2010-10-22 02:07:14
Rio Joraku @joraku

逆に要件定義や基本設計まで何もかもアジャイルで進めようとすると、それはそれで良いんだけど、手戻りが多くなることは覚悟する必要がある。そして、手戻りが多くなれば、当然スケジュールも狂う。(本来は手戻りも想定内の作業としてスケジュールを引く必要があるけど、大抵そうなってない。)

2010-10-22 02:12:09
石橋秀仁 @zerobase

ウォーターフォールが想定するプロジェクトマネジャは、何を作れば良いか、どのように作れば良いかを完全に知っている。近代経済学が想定する人間は、将来にわたる利益を合理的に最大化する経済人。似てるよね。ぼくの中では、アジャイルは経験主義であり、近代的合理主義への懐疑的代案。

2010-10-22 02:15:29
Kazuma YONETANI @4EX

実はアジャイルだウォーターフォールだというのはどうでも良くて、メンバーだったり納期だったりビジネス戦略だったりの制約がある中で一番うまくいきそうなプロセスを実践したいだけだったりする。

2010-10-22 02:16:45
Rio Joraku @joraku

受託開発とアジャイルの相性は必ずしも良くはないけど、その辺は与えられる裁量次第。全てお任せなら当たり前だけど最高に速い。(信頼がなければ全てお任せなど不可能だろうけど。) また、請負の場合は実装そのものはアジャイルで進められる場合はとても多い。

2010-10-22 02:18:52
naoki ando @threepennie

@zerobase なるほど、やはりクライアントにも革新的な人材が必要そうですね。皆、このやり方がいいのはわかっていてもなかなか踏み切れないのが実情でしょうね

2010-10-22 02:23:43
石橋秀仁 @zerobase

ベンチャーが「うちはウォーターフォール」といっていて、たしかにプロジェクト/フェーズ単位で見るとそうなのだが、1プロジェクト毎のスコープ/時間が小規模で、それを何度も繰り返し、市場・顧客を見て高速に仮説検証する、というのは、「アジャイル」なのだ。アジャイルは経営。

2010-10-22 02:24:21
石橋秀仁 @zerobase

ぶっちゃけプロジェクトがアジャイルかどうかとかどうでもよくて経営をアジャイルにできれば競争上こんなに有利なことは無い。とくに横一線でスタートするグルーポンレースみたいな競争においては。

2010-10-22 02:25:09
Rio Joraku @joraku

受託開発ではクライアントを満足させ、かつクライアントのユーザーを満足させるのが前提。だから、結果的に仕様の変更や追加などには最後の最後まで付き合う必要があるし、それが可能なような体制を構築しないといけない。ただ、それには契約面も含めて、クライアントとの相互理解や協調が必要。

2010-10-22 02:30:58
とみぃ(B面) @tomix

これ読んで、設計のアジャイルと、実装のアジャイルって 本質的に違うもののような気がしてきた。 経験主義的アジャイル思想 http://togetter.com/li/61615

2010-10-22 02:31:53
前へ 1 2 ・・ 7 次へ