プラクティス偏重が失敗の鍵としたら、原則とか背景や大事にする部分と実践へのリンクをきちんと教えるのが解法な気がするのだけど。パーマカルチャーの実習コースじゃなくてデザインコースのように。 #agiletokyo

posted at 17:37:31

E-Agilityは出会いの場なんだね。#agiletokyo

posted at 17:14:37

ふりかえりがあれば、悪かった点についてはやりながら改善できたかもね。 #agiletokyo

posted at 16:46:15

チームプラクティスと、エンジニアリングプロセスを少しずつ取り入れるのはいいですね。 #agiletokyo

posted at 16:41:44

プロセス変更の前に、チームコミットメントの協調作業形態に変えた。仕事を「とる」という表現ができるのは協調できてる物差しだね。#agiletokyo

posted at 16:40:16

ベンチャーだと課題に対しての危機感が半端ない。本気で考えるのだなぁ。Ready to change. #agiletokyo

posted at 16:35:39

ベンチャーの再生話なのかなぁ。CV時代を思い出す。 #agiletokyo

posted at 16:33:41

分散アジャイルについてのコメントがあまりなかったのが残念。 #agiletokyo

posted at 16:20:05

タスクの工数が細かくトラッキングされているのが日本企業っぽいね。1月スプリントだと回数少ないから、ベロシティでプラン見直す感覚は少ないかもなぁ。。。。 #agiletokyo

posted at 16:13:05

ああ、プロビズモさんの案件の話なのか http://goo.gl/z0yFF #agiletokyo

posted at 15:51:39

Rubyビジネスモデル研究実証事業と聞いたら、聞くしかないな。 #agiletokyo

posted at 15:43:18

「テストが失敗したらコミット許さない」って昔からSCMのaegisで実現されていたけど、一般的ではなかった気がするので実現できるのはいいですね #agiletokyo

posted at 15:05:08

是非Fowlerの前で、「教えてマーチン・ファウラー先生」を話してほしいなぁ。 #agiletokyo

posted at 15:03:00

アジャイルサムライもってきたんだけど、訳者や監訳者はもう会場にいないのかな？ #agiletokyo

posted at 12:58:44

これは、ソフトウェアシステムの「Health Definition」なんだよなぁ。何をもってOK(健康)とするか。ProductionレベルまでみてのOKをDefinitionに含めておくということと理解している。 #agiletokyo

posted at 11:57:24

"完璧な自動化" #agiletokyo

posted at 11:51:41

CIはコードの問題早期発見、Continuous Deliveryはシステムの問題早期発見、Continuous Releaseはビジネスの問題早期発見だね。 #agiletokyo

posted at 11:50:03