アジャイルサムライ DevLOVE道場 #5 飛翔

今日が7ヶ月に渡る道場の締め日となりました。

ちゃんと作り上げたかったのですが、実際は全く形に成らず・・・。

第5回目を踏まえて、改めて、なんでだろう?と考えてみました。

当日は西村さんと角谷さんがいらして、
発表を聞いてもらえ質問に答えて頂き、ワールドカフェでは対談し、
懇親会でもお話しでき・・・と、疑問を解決する場としてはかなり
成り立っていたなぁと。(さすがDevLOVEクオリティ)

その中で印象的だったことをいくつか挙げておきます。

・開発メンバは最低限同じ場所にいる必要がある。

・インセプションデッキはキレイに創る必要は無い。

・あの形を守るのではなく、何を考えるかを決めておくのが大事。

この辺りは前提からくつがえされたなというのが苦笑pointでもあるんですが、コミュニケーションツール検討や、応答までの時間ロス、度重なるオフラインミーティングを続けた結果、アジャイルって意外と時間がかかるじゃないかー、大変やないかーと背負い込むことが多かったかなと。

「いったいいつになったら作り始めるんだろうか?」
「何が早いんだ?」

と、思ってしまい、ちょっと現実的にとらえるのが難しくなってもいました。そうやって考えてしまうために、モチベーションが下がって行ったのかもです。

つまり、これはあくまでワークショップであって現実には即さないんじゃないかと。

でも、そうじゃなかったんですよ。

「実際にインセプションデッキは使っています」

全然理解できなかったのは、全然扱い方が間違っていたから。

つまり、

私は、ウォーターフォールに慣れ親しみ過ぎていたということです。

どうでもいいドキュメントに時間を使ってしまう性質がこびりついていたのです。

懇親会で、角谷サンと「Ajileは開発者を幸せにしますか」という話をしたときに、「幸せってなんですか?」と逆に質問されてしまったのですが、不幸せな点から考えると、不要なドキュメントにかける大量の時間は、プログラミングの時間を奪います。納品作業は私にとって、苦痛です。

そのうえ、「このドキュメントどうせ見ないし」って分かっているようなものを罫線がどうとか訂正するの、かなり死にたくなります。だって見ないもん。いっそのこと、バグってると言われたら、「詳細設計書見てから教えて下さい」なんてこと、言えるわけないし。そんなネゴ取れるかっつーの。

他に、「ドキュメントも作成するか選んでもらう」という手法はレガシー組織にとっても有効なんじゃないかなと思いました。

機能を追加するか、
読まないドキュメントを作成するか、
いずれか、です。

とにもかくにも、このドキュメント命な私に気づけたのが、最大の成果かなと思います。

システムはもっと簡単に創れる。→ 不足、誤解されがち
必要なところに力をかけよう。→ 正解

私にとっては、この図式を腹落ちさせるのが、この道場だったんじゃないかと思いました。

「現場に対して、今後アクションをするのは、このワークショップよりはるかに難しい。でも、この道場で出逢ったみんなは同じ状況にいるのだから、門下生として相談していけばいいじゃないか」

という言葉を胸に、それぞれ現場で飛翔していきましょう。
お疲れさまでした。

togetter
http://togetter.com/li/248786

広告

アジャイルサムライDevLOVE道場 第三回

本日は、オラクルで開催しました。

当日の資料はこちら。

仕事で遅れてしまい、浦島太郎状態でしたが、
なんとかメンバーの方にフォローいただき、やんややんやしてきました。

この内容は『アジャイルサムライ』本編には出てきませんが、
実際に製造に入る上では考える必要があります。

タスク分割の中で、

 スプリント0:開発環境
 スプリント1:優先順位の高い仕事

を決めました。ユーザーストーリーを前回で作りましたが、
開発環境に関しては、 ストーリーになっていませんでした。

よって、「タスク外」です。

でも、実際は環境構築をしなきゃいけないし、リリースしなきゃいけない。
フレームワークの制限を受けるかもしれないし、そもそも実装できないかもしれない。

タスク分割というのは、1タスクを0.5〜4時間ぐらいで分散していきます。
1日の工数が8ではなく、4だったのが印象的でした。
ついつい、5人日=40時間と考えてしまいがちですが、
実際に1日で働いている時間は、4時間程度にしたほうがいいという考えです。

これで組んで行けば見積もりに対して大幅に遅れることはないと思いました。
また、そのあとに出てくるバーンダウンチャートは、成果に対してコミットメントし、
かかった時間については評価しないそうです。

これってすごく精神的に優しい!
やっぱり「あいつだめだな」フラグを立てて行くよりずっと効果的でしょう。

だって、そんなことされて前向きな気持ちになれますか?
あたし、えむじゃねーし。

ってことで、アジャイル取り入れてゆきたいのれす!

アジャイルサムライDevLOVE道場 第二回 発展

ほぼ一年後に振り返ってるので、詳細を知りたい場合は、まとめ職人の下記ブログを参照ください。

アジャイルサムライ DevLOVE道場 『第二回 発展』に参加してきた #agilesamurai #devlove

振り返り

当日のノートがあったので、それを元に考えてみようと思います。

確か、当日は遅れて参加してしまった気がしまいました・・・。

INVEST〔p111参照〕

Independent(独立している)
Negotiable(交渉の余地がある)
Valuable(価値のある)
Estimable(見積もり可能)
Size Light(程よい大きさ)
Testable (テストでける)

Estimableはスペルミスではなく、あえて使ってると聞いたのは記憶にあります。

講義の後は、ユーザーストーリをカードに書き落とすワークショップに入ります。

Card〔p119, p187参照〕

表:ストーリー(テンプレート)
裏:制約(受け入れ基準(見積もり、タスク分配)、制約、気になる事))

を書くのですが、いきなりカードにすることには抵抗があったので、いつも通り?付箋にひたすら書いていきました。ストーリーをずらずらと、それに対して、制約があれば、ストーリー付箋に対して追加していきます。そいえば、図は全然書きませんでした。(それで後々、個々のイメージが合ってない事にオノノクわけですが・・・)

このとき、ストーリーが以下の通りになっているか注意する必要があります。

お客さんがワクワクするようなストーリーを書こう!〔p108〕

ついつい実装よりの話になってしまいがちなんですが、そうではなくて、「ログインできる」とか動作が分かりやすい内容が求められます。(って、これじゃ全然ワクワクしないけど・・・)

合わせて、見積もりも行います。
また、付箋の内容も、カードに書き写していきます。(時間足りなくてできなかったけど)

このとき、はじめてプランニングポーカーを触りました。それぞれが思うタスクの大きさを「いっせーのせ!」で出して、結果が違ったらそれについて討論するやつです。その後、見積もりを何度かしたことがあるけど、「あいつが適当に見積もったせいで今デスマなんだぜ」的な話を聞いたこともあるので、こーゆーみんなで決めましょうツールがあると、平和でいいですねwと思います。なかなか難しいのかな。

と、本日もモリモリ頑張りましたー。プランニングポーカーは、実はこの後の懇親会で、@haradakiroさんに頂くことになりました!めっちゃ嬉しい。そうだ、Agile girlsを作る話をしたのだった。nawoto_girlsじゃなしにw

引用元

アジャイルサムライ−達人開発者への道−

著者/Jonathan Rasmusson
監訳/西村 直人・角谷信太郎

4274068560
オーム社
2011-07-16
売り上げランキング : 1120