2014/02/14 デブサミ2014【14-A-3】Microsoft Office開発部門リーダーが語るOffice開発（仮） #devsumiA

Yasushi Hagai @yas_hag

コードの共同所有は出来てるのかな？ #devsumiA

rinfield @rinfield

Microsoftのアジャイルすごいでしょ！？みたいなノリかと思ったけど、かなり泥臭い地道なお話だった #devsumiA

Takuto Wada @t_wada

抜けていたもの: 3. スプリント毎の製品の完成。スプリント終了までにテストを完成させるのは無理で、出たバグも直しきれない。スプリント後から出荷可能になるまで1、2ヶ月かかるので(以前よりは圧倒的に速いが)、状況が変化してもすぐには対応できず、達成感がない。 #devsumiA

永谷 弘宣@静養中 @HironobuNagaya

ウォーターフォールからアジャイルへ移すのに四苦八苦した話です。 今までの開発プロセスを変える時は慣れの期間を含めマージンを多めに取った方が良いのかなと感じました。 #devsumiA

Takuto Wada @t_wada

アジャイルマニフェストを読み直し、できている/いないを自己採点。できていないのは「ビジネス側の人と開発者は日々一緒に働く(これは組織と製品の構造上難しい)」「持続可能な開発(毎日しんどい…)」「技術的卓越(テスト後回しになりがち)」「定期的に振り返る」だった #devsumiA

Yasushi Hagai @yas_hag

「スクラムのまねごとしてみたけどダメダメでした」って事を発表したかったのか… #devsumiA

IIJIMAS @IIJIMAS

正直あのMSのプロジェクトなのにかっこ悪いお話だけど、同じ失敗しないためには参考になるお話ｗ #devsumiA

Takuto Wada @t_wada

つまりはスクラムもどきだったが、メリットはあった。最速でEnd-to-Endのシナリオが通せるのでドッグフーディングができる。実際に使ってくれた社内ユーザからフィードバックがあり、仕様やつくりを見直せる。作り直すところを精密に作り込んでもしかたない。 #devsumiA

KimKimmy @KimKimmyMi

scrumもどきのメリット→1.最速でend-to-endのシナリオが通せる。2.社内ユーザのフィードバックを元に仕様を見直せる。 #devsumiA

駆け出しちんちん改九拾八式 @macoairhead

UX設計プロセス改善 一番目立つところって一番迷うよな・・・ #devsumiA

IIJIMAS @IIJIMAS

次回への改善点「UX設計プロセスの改善」「見積もりに余裕を」「スプリントRetrospectiveの実行」 #devsumiA

sin_o2k @sin_o2k

組織文化がある会社やWF主流だとありがち話。ある意味安心した。#devsumiA

Yasushi Hagai @yas_hag

「めんどくさくてもRetrospectiveやろう」って… #devsumiA

KimKimmy @KimKimmyMi

私も始めたばかりなので、失敗談と次回改善点のあたり、とても参考になる。 #devsumiA

sin_o2k @sin_o2k

失敗から学ぶ姿勢は見習いたいね　#devsumiA

Takuto Wada @t_wada

次回への改善点: UX設計プロセスの改善。見積もりに余裕を持つ。スプリント毎のふりかえりを面倒臭くともきちんとやる。(以前から MS では計画と postmotem の文化があったので粒度の細かいふりかえりを面倒臭く感じてしまいがちだった) #devsumiA

ぐらばく☪ @Grabacr07

「エキスパートでない集団がアジャイルを適当にやるとこうなる」 #devsumiA

Yasushi Hagai @yas_hag

最後はちょっと笑ったけどね。　#devsumiA

KimKimmy @KimKimmyMi

アジャイルのエキスパートでない集団がアジャイルをやるとこんな感じになりました。(笑＠会場) #devsumiA

Takuto Wada @t_wada

Microsoft 社の社内事例 (OneNote 開発チーム) 、以外にも(?) とても泥臭く、格好悪くて、とてもよかった。世界有数の計画主導ソフトウェア開発企業が変わろうともがいている姿が見えた。 #devsumiA

Pika- @PikachuPunch

OneNoteの紹介あってメモ綺麗に取れるようになった。今日はこれだけでも来た価値があった気がする。スクラムの話はやはり同じところに課題を持つんだなという感想。 #devsumiA