ラベル アジャイルサムライ の投稿を表示しています。 すべての投稿を表示
ラベル アジャイルサムライ の投稿を表示しています。 すべての投稿を表示

2013年8月25日日曜日

アジャイルサムライ読書会 横浜道場 「テスト駆動開発」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「テスト駆動開発」
http://yokohama-dojo.doorkeeper.jp/events/4834

テスト駆動開発

今回は、テスト駆動開発ということでグリーンバンドを左手にして参加してきました。

DSC_0001.jpg

アジャイルサムライで語られているテスト駆動開発は、一部分でしか無いので、ここだけでは単にテスト書いてから始めればいいよねくらいの感覚しか無いように思ってしまいました。

テスト駆動開発を始めるためには、まず第12章のユニットテストでユニットテストを書ける様になって、第13章のリファクタリングをプロダクトコード、テストコードで出来るようになる必要があると思います。

テスト駆動開発をプロセスとして始める際に、ユニットテストとしての完了の定義を計画ミーティングで決めることが大切なのではないかと思いました。
完了の定義が明確であれば、ストーリーを満たす条件が明確であるため、それを満たすケースを一つづつテストコードに落としこむことが出来るのではないかと思います。

また、テストコードのレビューを行うことで、足りていなかったケースや他になにか気づいた点を共有できる機会が持てるので導入してみたいと思いました。

ユニットテストを書く経験を積んでいると、どういったプロダクトコードだとユニットテストを書くのにしんどい設計なのか身を持って分かる為、テスト駆動開発を行うことでユニットテストをしやすい設計と実装を身につけることが出来るのではないかと思います。

おわりに

アジャイルサムライも残すところ「継続的インテグレーション」のみとなりました。

また、10月にはTDDBC横浜も開催される予定です。

参加者の皆さん、横浜道場のスタッフの方々、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまた、よろしくお願いします。

2013年6月12日水曜日

アジャイルサムライ読書会 横浜道場 「ユニットテスト:動くことがわかる」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「ユニットテスト:動くことがわかる」
http://yokohama-dojo.doorkeeper.jp/events/3963

ユニットテスト

DSC_0326.jpg





静的解析ツールがOSSで出るようになったり、Jenkinsで実行できるようになったおかげで、どこに潜在的なバグが潜んでいるのかを継続的に見られるようになったと思います。

また、レビューの対象もプロダクトコードよりテストコードを重視することでテストケースの漏れ等を共有できる様になるということを知りました。
これもユニットテストが全てGreenであることが前提となっているからこそだと思います。

また、ユニットテストを自動実行出来る事によって、手動で行わなければならないテストにコストを費やすことが出来るので、自動化出来るテストは自動化するのが望ましいのではないかと思いました。

ユニットテストを積み上げていくことで、変更の影響範囲を可視化出来るので、今までのような不正確な見積もりよりマシな見積もりが出来ると思いました。

おわりに

参加者の皆さん、横浜道場のスタッフの方々、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまた、よろしくお願いします。

2013年5月23日木曜日

アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「現場の状況を目に見えるようにする」
http://yokohama-dojo.doorkeeper.jp/events/3455

はじめに

今回の通常回は、プロジェクトで使う「貼りもの」についてどのように運用したらよいかといった内容でした。

現在のプロジェクトは独りで行なっていますが、付箋を利用したストーリーボードを実施しています。
こうすることで、今日やるべきことと後どれくらいで終わるのかめどが立ちやすくなりました。

ディスカッション




壁に貼るものについて主にプロジェクトで使う言葉についてと、貼り物の真価についての内容が多かったように思えます。

特にプロジェクトで使う言葉については、間違えやすかったり、文字通りの意味を持たない場合など注意しなければならない言葉をピックアップして貼りだすのが良いのではないかなど、改善内容が多く出て来ました。

貼りものをすると顧客の目に触れる機会があると思うので、その場で分からなかったり新たに追加する内容等がすぐに反映出来るのが良い点ではないかなとも思いました。

おわりに

懇親会では、似た境遇の方に今までやってきたことなどを伝えることが出来たので、とても有意義な時間でした。

次回はの特別編は、新しい試みをするそうなので、楽しみです。

参加者の皆さん、横浜道場のスタッフの方々、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまた、よろしくお願いします。

2013年4月7日日曜日

アジャイルサムライ読書会 横浜道場 「アジャイルな意思疎通の作戦」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「アジャイルな意思疎通の作戦」
http://yokohama-dojo.doorkeeper.jp/events/3267

はじめに

今回は、久しぶりの通常回です。
イテレーションの運営に入ってきており、実践している方がチームにいらっしゃらない場合のことも考えていかないといけないのかなと思います。

ディスカッション


イテレーション計画ミーティングとストーリー計画ミーティングの違いについて疑問が始めの方に出て来ました。
それぞれのミーティングでやることが似ている部分があったりして、どのように違いを付けて行なっているのか気になったりしました。
その後の方に、チームの合意が取れれば一緒にやっているという話も出てきていたので、実践している方は分けているとしたらどう区別をつけているのか、一緒にやっている場合でもどのようにしてやっているのか疑問に思いました。
ミニ振り返りもあまり時間をかけずにするということがあったのですが、長くなりがちな振り返りをどのようにしたら短く出来るのかいい方法があれば、実践してみたいなと思います。

朝会の話についても、マンネリ化したり形骸化したりするパターンがあったりして、どのように改善していければいいのかといったこともまとめの発表で出て来ました。
今日一日に対するコミットメントを発表するだけでもその人の一日の目的がはっきりするので、完了したかどうか個人で見直せることが出来ればある程度目的に沿っているのではないかと感じました。
その習慣が良い結果をチームにもたらしているのであれば、続けるか続けないかはチームの合意が取れればいいですし、何も生み出さすただの時間潰しであれば、別のことに時間を割り当てるべきかなと思います。

おわりに

まとめの発表でタイムボックスがキッチリし始めたので、そろそろ古参の人たちが率先してまとめの発表の計画をしっかり立てていく段取りをしなければならないのかなと思いました。
次回はまた特別編ですが既に予約が一杯の模様です。

参加者の皆様、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。
次回もまたよろしくお願いします。

2013年4月4日木曜日

横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」 に参加してきました #agilesamurai #横浜道場

横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」
http://yokohama-dojo.doorkeeper.jp/events/2912

2013/03/19(#agilesamurai)横浜道場 特別編「Domain-Specific Language としての魔法少女まどか☆マギカ入門」
http://togetter.com/li/474247

はじめに

今回は、告知された際にいろいろな箇所で話題になっていたおかげか、初めて横浜道場に参加された方が多かった気がします。

砲火後ティータイム



Domain-Specific Language、略してDSLは、特定の領域にのみ通じる言語ということで、今回は「まどか☆マギカ」を題材にした内容でした。
全話視聴済みの方がほとんどだったので、ドメインの共通知識は持っているということが確認できました。
私達のグループには全く知らない方がいらっしゃったので、キャラクターの概要やイメージから連想してもらったりしてもらいました。
個人的には、「杏子」派だったのですが、「ほむら」の生き様が開発者によく似ているというお話を聞いて、納得いくようなこともありました。

特に印象的だったのが、リーンスタートアップで有名な言葉も「ほむほむ」という単語で置き換えが出来るということでした。

同じドメインにいても考え方が違っていたり、見え方が違っていたというのも、興味深かったです。

おわりに

今回の開催のいきさつを聴いたり、懇親会での状況を見て、道場主巻き込み力の凄さを感じました。

講師の@hageyahhooさん、横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。
次回の通常回もよろしくお願いします。

2013年3月10日日曜日

アジャイルサムライ読書会 横浜道場 「イテレーションの運営:実現させる」に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「イテレーションの運営:実現させる」
http://yokohama-dojo.doorkeeper.jp/events/2911

アジャイルサムライ読書会 横浜道場「イテレーションの運営」
https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiinyokohama20130305

はじめに

今回から「第IV部 アジャイルなプロジェクト運営」に入りました。
これまで建てていた計画を実際に運営してくためには、どうすればよいのかを学んでいきます。
通常回の「第9章 イテレーションの運営:実現させる」でした。
特別編や番外編のおかげか、通常回にも新しい人がいらっしゃいました。

ディスカッション

DSC_0246.jpg

今回のディスカッションで一番印象に残っていたのは、「技術的な検証や調査を行う際にポイントを割り振って行う」ということでした。
新しい技術を調査する際に、例えば3ポイント割り振って実施して振り返りを行うことで、次のイテレーションにつなげるのか、それとも採用せず既存のものを流用するのかなどチームで検証が出来るということでした。
期限を区切らずに一人に割り当てて専任にしてしまうと、終わらなかったり、共有できなかったりしてしまうので良くないということが、あると思います。

また、設計のために必要な分だけ分析するというのが一番話されていました。
どこまでやればいいのかというのが分からず、やり過ぎると後々のイテレーションに影響が出てしまうという弊害も起こるので、さじ加減を習得するのは難しいのではないかと感じました。


おわりに

今回の章は、実際に運営した経験がある人でないと気付けないような箇所も見受けられたので、雲をつかむような感触がありました。
次回以降も運営に関することがあるので、疑問に思ったことはいろいろ聞いてみたいと思います。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。

次回もまたよろしくお願いします。

2013年3月4日月曜日

アジャイルサムライ 横浜道場 番外編「自分の価値観を見える化してみよう」 に参加してきました #agilesamurai #横浜道場

横浜道場 番外編「自分の価値観を見える化してみよう」
http://yokohama-dojo.doorkeeper.jp/events/2591

2013/02/22 横浜道場 番外編「自分の価値観を見える化してみよう」 #agilesamurai #横浜道場
http://togetter.com/li/460726

はじめに

今回は、特別編ではなく「番外編」らしいです。
内容は@haradakiroさんが講師となって行うワークショップでした。

ワークショップ

始まる前の注意書きとしてR指定が出てきたので、血で血を洗う名状しがたい何かだと思ってましたが、そんな物騒なことはありませんでした。

まず、自分が4つの相対するカテゴリに分別されるとしたらどんなカテゴリになるのかというのを、アンケートの結果を元に導き出されました。
4つのカテゴリには、それぞれ色が決められており、それぞれ特徴となる考え方、思考があるそうです。
私のカテゴリは、緑色の「創造・想像」でした。
特徴としては、常に新しいものに取り組むのを好んだりするらしいです。
反対側のカテゴリは、赤色の「改善・管理」で官僚的で管理するのを好んだりするらしいです。

1回目のワークショップでは、同じ緑色の人たちをペアプロについて話し合いました。
2回目のワークショップでは、シャッフルして自分の正反対の色のロールを演じながら1回目と同じペアプロについて話し合いました。


印象深かったのは、正反対のロールを演じるのは、ものすごいエネルギーが必要だということを実感したことでした。


ハンロンの剃刀という言葉があるそうで、反対側のカテゴリに属する人たちが言うことが気に食わない事もありますが、それは悪意を持っている場合は殆どなく、悪意があるように捉えてしまいがちだそうです。


予めそういうこともあるという認識を持つことでチームの多様性を維持することが出来るのではないかなと感じました。

おわりに

自分がどのような思考をしやすいのか、また反対側のカテゴリの人たちがどういう考え方を知ることで、お互いに上手くやっていく方法を見つけることが出来るのではないかなと思いました。

講師の@haradakiroさん、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまたよろしくお願いします。

2013年3月2日土曜日

アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」
http://yokohama-dojo.doorkeeper.jp/events/2592

アジャイルサムライ読書会 横浜道場 特別編「マシュマロ・チャレンジ」 #agilesamurai #横浜道場
http://togetter.com/li/459092

はじめに

今回の特別編は、「マシュマロ・チャレンジ」でした。
当日まで何の予備知識もなく臨んでみたいと思ったので、検索もせず楽しみにしていました。

マシュマロ・チャレンジ

実は、今回のチームは偶然にも前回のチームとほぼ同じメンバーでした。
1回目は作戦として設計とプロトタイプを作るのに専念した結果、下の写真のように土台を作るので手一杯でした。
DSC_0207.jpg

他のチームの状況を見ると、無事マシュマロが乗っていたところもありました。
2回目に移る前には振り返りをしてどの部分を改善したら上手く乗せられるのか意見を出し合いました。
2回目が始まってから土台の作成効率が上がったのと、マシュマロを乗せるタイミングをギリギリまで粘った結果、無事立ちました。
DSC_0210.jpg

マシュマロ・チャレンジの解説動画はこちら

CEOのチームにファシリテーターが居ることで、成績が良くなったというのが興味深かったと感じました。


本来、マシュマロ・チャレンジは一発勝負なので、私達が取った作戦は本来の主旨から外れたものでした。

チームビルディングとプロトタイプの重要性を知るいいワークショップだと思います。
材料も手に入りやすいものですし。
準備で重要なのは上に乗せるマシュマロは日本の小さいタイプではなく、バーベキューで焼くような大きいタイプを用意することだそうです。

おわりに

こういったワークショップも楽しめるので、横浜道場は面白いところだと思います。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。
次回もまたよろしくお願いいたします。

2013年2月19日火曜日

アジャイルサムライ読書会 横浜道場 「現場で実践する」に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「現場で実践する」
http://yokohama-dojo.doorkeeper.jp/events/2590

アジャイルサムライ読書会 横浜道場 「現場で実践する」 #横浜道場 #agilesamurai
http://togetter.com/li/450974

はじめに

遅くなりましたが、忘れないために書きます。

今回は、現場でいろいろとミスや失敗をしてしまいその為、遅刻して参加しました。

ディスカッション

DSC_0156.jpg

バーンダウンチャートから見えてくる結果から、どのように計画の変更を行なっていくのかが主な内容でしたが、メンバーの増減でコストがかかる場合にあらかじめそれを見越して、ドキュメントなど後々使うのをまとめておくのは、やりたいけど優先順位下げがちだなと感じました。

自分の隣に壁があるので、ポストイットを使って自分の作業をカンバンで見える化している話をしてみました。
こういった話を出来るようになってきたのが、とりあえず一人でも出来るプラクティスをやってきた結果なのかなと思いました。
自分が実践してみて分からなかったり、疑問に思ったことを話し合える場が、外部にもあるというのは心強いです。

おわりに

togetterで見直しながら書いていますが、あとで振り返るために頑張ってtsudaって見ましたがまだまだ精進が必要だと感じました。

参加者の皆様、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様、ありがとうございました。

次回もよろしくお願いします。

2013年1月23日水曜日

アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」 に参加して来ました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」
http://yokohama-dojo.doorkeeper.jp/events/2148

2013/01/22 アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」#agilesamurai #横浜道場
http://togetter.com/li/443871

はじめに

今年はじめてのアジャイルサムライ読書会に参加して来ました。

第一回目もワールドカフェだったのですが、それ以降何度か体験して面白かったので、このメンバーでやるとどうなるのか楽しみでした。

ディスカッション

ディスカッションのテーマはいろいろあったのですが、意見を出しやすいテーマを選んでみました。
選んだテーマは、「アジャイルのプラクティスで外せないものは何か」でした。
その結果は以下のような感じになりました。
DSC_0149.jpg

それぞれで外せないものは、あるのですがいろいろと関連性が見えてくるのが興味深い内容でした。

次のテーブルでは、型を破るタイミングとどう破るのかについて話し合ってました。
DSC_0150.jpg

チームのスキルセットによっては、型を形作るまでの過程が険しいのだと感じました。

おわりに



今年は、ハッカソンを中心に手を動かすような勉強会に参加して行こうと思います。
聴講形式では、知った気になって何も身につかないのは、この一年で実感したので減らしてみます。

横浜道場のスタッフの皆様、参加者の皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。

今年もよろしくお願いします。

2012年12月31日月曜日

アジャイルサムライ横浜道場 忘年会 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ横浜道場 忘年会
http://kokucheese.com/event/index/60584/

はじめに

これが2012年の最後の横浜道場ということで、忘年会が開かれることになりました。
内容は、LTを肴にいつもの懇親会をぶっ通しで行うようでした。

初めてのLT

前回のLT大会で初めての方が発表されていたので、今回私も人生初LTをしてみようと思い、手を上げてみました。
人前で話すことは苦手なのですが、LTなら「ウケなくても、滑っても特に問題無い」というこれまで参加した勉強会で学んだことを踏まえた上での参加表明でした。

今回のLTのスライドはSphinx + S6を利用してgithubに公開してみました。

http://grimrose.github.com/yokohama-2012-12-06-LT/

Sphinx + S6を使ったのも初めてですし、githubで公開するのも初めてでした。
Sphinxの良い所は、やはりhtmlで出力できるので、ブラウザがあればなんとか出来るところですね。
公開するときもhtmlならそのまま出来ますし、何しろrstならVCSで履歴管理も出来ます。
S6もテンプレートのままでも十分プレゼンテーションに使えます。
画像の差し込みも出来るようなので、次回以降使ってみたいと思いました。

内容は、これまで参加してきたことのKPTをスライドにしてみました。
S6だと書くことが出来る量がかなり制限されるので、いい制約だと感じました。

発表は、時間オーバーしてしまいましたが、自分が伝えたいことは全部話せたのは良かったと思いました。
他の場所だとこれではダメだとも感じたので、次回以降は練習を重ねて臨みたいと思います。

おわりに

他の方々のLTも絵が上手な方や、スライドに視線誘導されて話に集中できない発表だったりなど、とても個性的で楽しいものでした。
特に大トリの@joker1007さんのLTは、自分と似たような境遇の友人がいらっしゃるみたいで親近感が湧きました。

今年の横浜道場は今回で終わりですが、来年以降も続きそうな感じなので、参加する際には自分が体験したことをフィードバック出来るようにしていきたいなと思います。

参加された皆様、横浜道場のスタッフの皆様、会場を提供して下さった株式会社アットウェア様、今年も大変お世話になりました。

また、来年もよろしくお願いします。

2012年11月25日日曜日

横浜道場 特別編 Cucumber HandsOn !! に参加してきました #agilesamurai #横浜道場

横浜道場 特別編 Cucumber HandsOn !!
http://yokohama-dojo.doorkeeper.jp/events/1990

#横浜道場 特別編 Cucumber HandsOn !!
https://yukar.in/note/ckFj9t

はじめに

横浜道場の特別編として「Cucumber HandsOn !!」が行われることになりました。
cucumberにまつわる講義とその後の実践としてRubyとJavaに別れてハンズオンが行われました。

ハンズオン

当初cucumberは名前と概要だけ知っていた状態だったので、使っている人の話が聞ければいいな程度だったのですが、
その後「WEB+DB vol.69」に@shuji_w6eさんが執筆された「JUnit実践入門」にてcucumber-junitのライブラリによってJavaでも出来ることを知りました。
Javaではcucumberの文化が無いので、体験できればと思いました。

タイミングのいいことに開催前日に「JUnit実践入門」の書籍が発売されました。
当日は雑誌と書籍を見て、予め用意してもらったスケルトンと正解を利用しました。
途中つまづきながらも動かせるようになったので、何とかなったのかなと思います。

自然言語を使うことのメリットとデメリットがよく分かったハンズオンでした。

GroovyでもSpockを使うことで同様のことが出来るので、JUnit以外を利用可能な環境であればSpockを使って、JUnitに縛られているような環境では、cucumber-junitを使うことで似たようなことが出来るのではないかなと思いました。

おわりに

次回は横浜道場の忘年会とのことです。
一応、人生初LTをする予定なので鋭意考察中です。

講師の橋立さん、大中さん、吉田さん、横浜道場のスタッフの皆様、会場を提供して下さった株式会社アットウェア様ありがとうございました。

2012年11月17日土曜日

アジャイルサムライ読書会 横浜道場 「バーンダウンチャート」に参加してきました。 #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「バーンダウンチャート」
http://yokohama-dojo.doorkeeper.jp/events/1942

はじめに

年内最後の通常回ということでしたが、同日に他に勉強会があった模様で人数が少なめでした。
しかし、参加してみて意外と内容の濃い会になったと思います。

ディスカッション

DSC_0517.JPG

模造紙が消せるタイプにグレードアップしてました。
ただ、付箋が無かったのにはちょっと戸惑いがありましたが、頼んだら出てくるそうなので次回から使えそうです。

バーンダウン・バーンナップのどちらを使ったほうがいいのかは、プロジェクトの特徴に合わせたほうが良いみたいです。
途中でスコープが追加されるような場合は、バーンナップの方が変化が見やすく、
スコープが固定の場合は、チームの状態とこれからの見通しが分かりやすいということでした。

今回の範囲で、印象に残ったのは、以下の言葉です。

変化は絶えず起きているが、それを認識してどう対処するかはチームで考えて行かなければいけないのは、どんなプロジェクトでもそうなのだなと感じました。

あと、スコープを追加する場合は何かを諦めてもらうという習慣や文化がないと、炎上や頓挫してしまう可能性があるのだなと話を聞いていて思いました。

おわりに

今回は、早めに着いたので会場の設営とか手伝ってました。
次回は、Cucumberのハンズオンを行うそうなので楽しみです。
Javaでもcucumber-junitを利用することで出来るそうなので、自分でもやってみたいと思います。
参加された方々、横浜道場のスタッフの皆様、会場を提供して下さった株式会社アットウェア様ありがとうございました。

2012年10月31日水曜日

関東三道場共催 "先鋒、前へ!" に参加してきました。 #agilesamurai #横浜道場

関東三道場共催 "先鋒、前へ!"
http://partake.in/events/c58825a9-c0c0-4097-b853-2b15a1411fa4

関東三道場共催 "先鋒、前へ!"
http://togetter.com/li/399537

はじめに

今回は、遅くなりましたが忘れないために書きました。
ですが、さすがに半年も前では記憶が定かで無いので、まとめをそのまま利用させて頂きます。



おわりに

インセプションデッキのお話でしたが、基本とも言えるプラクティスだと思うので何度聞いていも忘れがちなことや、気が付かなかったことを思い出せるので、定期的に参加してみたいと思いました。
今回はほとんど横浜道場の方だったので、次回以降は別の道場との交流が持てる機会があればいいなと思いました。

参加者の皆様、スタッフの皆様、会場を提供してくださった日本オラクル様ありがとうございました。

2012年10月16日火曜日

アジャイルサムライ読書会 横浜道場 「現実と向き合う」に参加してきました。 #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 「現実と向き合う」
http://yokohama-dojo.doorkeeper.jp/events/1811

はじめに

今回は、第8章「アジャイルな計画づくり:現実と向きあう」でした。
初参加の方がいらっしゃらなかったのは残念でしたが、久しぶりに参加された方もいらっしゃったみたいでした。
やはり毎回違ったメンバーで議論するのは、面白いですね。
自分の体験を話すだけでなく、いろんな人の体験を聞くというのは社内では出来ないので楽しいです。

ディスカッション

DSC_0496.JPG
この章の前半では、「期待をマネジメントする」というキーワードがしっくり来る内容だと思われます。
また、現実とは、誠実に対応できる状況を示してるのでは無いでしょうか。

DSC_0498.JPG
お互いの認識がずれてしまうことで、計画している内容に齟齬や差異が生まれてしまうのではと感じました。
「意図が明確で無い報告は、ただのノイズ」ではないかという自分の体験を話しました。
相手が返答するのを期待するのであれば、どのような返答をして欲しいのか明確にすべきですし、相手に理解して欲しい報告であれば、自分の意志をはっきりと書いて伝えることが大切だと思いました。

DSC_0497.JPG
コラムにあったクビになった話から、どのように対処しておけばよかったのかを話し合いました。
これまで読んできたことを実践していれば、少なくとも信頼関係が著しく損なうことはなかったのではないかと思いました。

DSC_0500.JPG
誰に対して伝えて行かなければならないかと話し合った時、「期待している人」というのがキーワードとして出てきました。
これは、ユーザであったり、上司であったり、会社であったりとこのプロジェクトに対して期待をしている人に対して伝える必要があると思いました。

DSC_0499.JPG
適切なタイミングで伝えるというのは難しいことですが、伝えなければいけないタイミングというのは必ず訪れるので、それまでにしっかりと何を伝えるのか準備しておくことを忘れないようにしなければならないのですね。

DSC_0501.JPG
個人のベロシティを元に評価してすることは大変危険だということを学びました。
出来れば、人事評価をチーム単位に変えることが出来ればいいのですが、出来ないことが多いのでその場合は、全員の評価を同じにしてしまうということで対応しているという話を聞くことが出来ました。
そういう対応しか出来ないのはちょっと残念かなとも思いますが、仕方がないのでしょうか。

おわりに

ここで一番納得できるのは、「計画はあくまでも計画でコミットメントではない」ということです。
コミットメントと捉えて失敗しているプロジェクトがあったので、出来ればお互いに話し合って了承したい事項だと思いました。

次回は、何やら面白そうな特別編なので、楽しみです。
横浜道場のスタッフの皆様、参加された方々、会場を提供して下さった株式会社アットウェア様ありがとうございました。

2012年9月25日火曜日

アジャイルサムライ読書会 横浜道場「当てずっぽうの奥義」 に参加してきました。 #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場「当てずっぽうの奥義」
http://kokucheese.com/event/index/52905/

アジャイルサムライ読書会 横浜道場「当てずっぽうの奥義」
http://togetter.com/li/376992

はじめに

今回は、第7章「見積り:当てずっぽうの定義」でした。
全15章なのでだいたい折り返し地点でしょうか。

参加者が少なかったのが気になりましたが、これからの箇所は実践的なのでこれからでも全然大丈夫だと思います。

ディスカッション

DSC_0467.JPG
ポイントで見積もることで相対値が分かりやすいのと、三角測量することで基準となるストーリーが出来るので漠然としたストーリーでも大きさだけは見えてくるのではないかと思います。

DSC_0468.JPG
小さいと誤差が少なくなるというのは、実践しているとわかってくるそうです。
また20など大きい場合は、今すぐやるべきなのか、本当に必要な機能なのかを判断できるので、実際に始まる前には分割して進めるそうです。

DSC_0466.JPG
実際にアジャイル開発をやっていくと8や13といったポイントは手強いストーリーとして認識されるそうです。
そういった「におい」に敏感になれるようになりたいですね。

おわりに

今回の見積りの話は、実際に使える話しばかりでした。相対見積りはやっていましたが三角測量とポイントを組み合わせてやる方法はやっていなかったので、やってみたいと思います。
また、プランニングポーカーについては、見積もりの精度よりも、話し合って分からないことや思っていることを共有する場であることが大事ということです。
この段階でも漏れ等を掬うプラクティスがあるというのは、よく考えられているなと思いました。

今回は、道場主不在の中スタッフの皆様が頑張っていらっしゃいました。
横浜道場のスタッフの皆様、参加者の皆様、会場を提供して下さった株式会社アットウェア様ありがとうございました。

2012年9月17日月曜日

アジャイルサムライ横浜道場 特別編 パネルディスカッション に参加してきました。 #agilesamurai #横浜道場

アジャイルサムライ横浜道場 特別編 パネルディスカッション
http://www.zusaar.com/event/355105

アジャイルサムライ読書会横浜道場特別編パネルディスカッション #agilesamurai #横浜道場
https://yukar.in/note/ckFkBf

はじめに

開催されてからだいぶ経ってしまいましたが、書いておきます。自分自身の制約を守るために。

久しぶりの特別編でしたが、今回は講師の方を呼んで行うのではなく、パネリストを募ってこれまでの内容からディスカッションを行う形式でした。

パネルディスカッション

ディスカッションの内容は、@modal_soulさんがゆかりんのーとでまとめてくださいました。
結果的に上手くtsudaれていなかったのが、反省点だと感じました。

内容は、チームやこれまでの経験からお題に対して意見を述べていたので、一人だけで開発している自分としては「これは個人でも出来そうだな」と感じる部分がありました。


この部分は「問題は早く見つかるのか?」で出てきたことで、アジャイルな開発を行なっていると、このままだと後になって火を吹きやすそうな箇所などに気づきやすくなるので、予め先手を打ったり、振り返りの場で問題の共有して対処できるようになるといった意見がありました。
なので、早く見つかるというより見つけやすい状況になるといった方が、しっくり来るのではないかと思います。


この部分は、振り返りの場での内容で、折角見つけやすい状況になっても隠蔽されてしまったら手の施しようがないので、吊し上げのような問題があることを追求するよりも、解決する方にリソース振った方が前に進めるので、そういう状況に陥った場合に冷静になれるようになりたいと思いました。

おわりに

パネリストに志願された方々、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。

2012年8月13日月曜日

アジャイルサムライ読書会 横浜道場 「ストーリー収集ワークショップを開催しよう」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場
「ストーリー収集ワークショップを開催しよう」
http://connpass.com/event/834/

アジャイルサムライ読書会 横浜道場 「ストーリー収集ワークショップを開催しよう」 #agilesamurai #横浜道場
http://togetter.com/li/353184

今回は、久しぶりの通常回です。
「6.4 ストーリー収集ワークショップを開催しよう」からでした。

ストーリー収集ワークショップ

DSC_0369.JPG

実際にスクラムを実践されている方がテーブルにいらっしゃったので、実際にやっている内容を聞いて意見を出し合ったりしました。
特に文房具の使い方は、頷ける内容が多いように思いました。
例えば
  • ホワイトボードは議論用に使ってあとで見直せるように印刷できるものやデジカメで保存するようにする。
  • ストーリーカードは紙のサイズを制約として扱い、その一枚で表現する。
といった内容でした。
文章の限界ということを認識して絵や図を多用することで、お互いに共通認識を深めていくのが目的なのではないかなと感じました。

その他もろもろをブレインストーミング

DSC_0370.JPG
「ご近所さんを探せ」などで出てきた、政治的プロセスの把握や、開発環境や運用に関する項目もこの場所で出すことで、そのストーリーがどこと関係しているのかや、どれくらいの規模なのかが見えてくるのではないかと思います。
あまり細かくしてしまうとストーリーが膨大になってしまいますし、粗いと漠然としすぎてしまって本当にやりたいことが隠れてしまうといような印象を受けました。
細かくするのは後のプラクティスでやるのはいいのですが、どの程度までの「粗さ」がこの段階で求められているのか疑問に思いました。

見積り

DSC_0368.JPG

ここから第7章の「見積り:当てずっぽうの奥義」に入りました。

ここで出てきたのが「見積りの根拠」でした。
前回のスプリントから見積もることで相対的に見積もれるというのは分かるのですが、スプリントゼロの見積りはどれを基準にして相対的に見積もるのかなと思いました。
ただ、いわゆる「不確実性のコーン」に基づけば最初の見積りはどんなに頑張っても当てずっぽうなので、今までの経験から推測される根拠であればいいのかなとも思いました。

現状の契約ですとこれがコミットメントとして扱われてしまうから、無駄なものを作ってしまったり、デスマーチに陥ってしまったり、赤字なのにどんどんリソース突っ込んでしまったりといった不幸なことが起きてしまっていると思います。

スクラムやその他のアジャイル手法に適切な日本の商習慣にでも使える契約モデルとかどこかで公開してないでしょうかね。

最後に

今回も初参加の方がいらっしゃいました。だんだん参加される方も増えてきてディスカッションも毎回新鮮な感じを受けています。
次回もまた初参加の方とお話できればいいなと思います。

横浜道場のスタッフの皆様、参加者の方々、会場を提供して下さった株式会社アットウェア様、ありがとうございました。

2012年7月23日月曜日

アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」
http://partake.in/events/8b888e57-e3d3-4703-a456-4c042bcaf429

2012/07/19 アジャイルサムライ読書会 横浜道場 特別編 「アジャイルは組織を変えられるのか」 #agilesamurai #横浜道場
http://togetter.com/li/341420

アジャイルサムライ読書会 横浜道場 特別編  #agilesamurai #横浜道場
https://yukar.in/note/ckF3it


今回は、楽天の藤原さん(@daipresents)、及部さん(@TAKAKING22)を迎えての特別編でした。

アジャイルリーダーシップと組織改革


アジャイルペーペーシップとチーム改革

印象に残ったこと、共感したこと

  • 少人数で開発側からアプローチするならXPは、やりやすいと思う
  • 定量的に観測できる手段があると、今までと相対化出来、見える化出来るのは大きい。
  • サービスやOSSとしてリリースしすると、継続的に変更やバグ対応しなければならないので、テストが重要。
  • コーチがいなくなっても大丈夫なように「ヒト」を残す。
  • やらなければ分からないこともある、失敗から学ぶこともある。
  • 自分が変わることで、周りが変わってくる
  • 一歩でも前へ
特に、藤原さんがチームを去った後から、及部さんがどうやって改善していったのかが勉強になりました。
Agileは抽象化された部分ではそれぞれ似ていると思いますが、実現方法はチームや人によって変わると個人的に思っています。
それぞれのチームでやりやすいと思う方法を導入して改善できれば、いいのではないかなと思いました。

ビアバッシュ

懇親会では、ビアバッシュをしながらのQ&A大会でした。
お酒が入ったせいかいろいろな意見が出て面白いと思いました。
自分の質問は、以下のような質問をしました。
  • 「ファシリテーションするときに心がけていることは、何ですか」
返答は、
  • 「サンデル教授のようにふるまう」
でした。

確かに、場をうまくコントロールすることで、チームで発言していない人から意見を聞くこともできますし、タイムボックスを守ることも出来ます。
自分は、どうしても喋り過ぎてしまうので簡潔に話せるようにしたいと思います。

最後に

一度、特別編として全編ビアバッシュ and ディスカッションをやるのも面白いと感じました。
講師の藤原さん、及部さん、横浜道場のスタッフの皆様、会場を提供してくださった株式会社アットウェア様ありがとうございました。

2012年7月8日日曜日

アジャイルサムライ 横浜道場「ユーザーストーリーを集める」 に参加してきました #agilesamurai #横浜道場

アジャイルサムライ 横浜道場「ユーザーストーリーを集める」
http://kokucheese.com/event/index/42827/

2012/07/05 アジャイルサムライ 横浜道場「ユーザーストーリーを集める」#agilesamurai #横浜道場
http://togetter.com/li/332950

今回から第3章「アジャイルな計画づくり」に入っていきます。

DSC_0303

文章化の難しさ

文章にするということが目的となってしまって、後から見返してみると「何をやりたかったのか」がわからなくなってしまうといったことになりがちです。
文章にしてしまうことで、それが実現可能かまだ分かっていないのに安心してしまうような人たちもいます。
そうではなく、今後の計画を立て得る際に、会話のテーマになる程度のまとまりになるようにするのが大事ではないでしょうか。

ユーザーストーリー

DSC_0305

ビッグウェイブ・デイブのユーザーストーリーをチームで出し合ってみました。
テンプレートである「ユーザーとして、何をしたい、なぜなら理由だから」に沿ってやってみました。
機能にまで掘り下げてしまうとその他によい解決案があったとしてもそれに引き摺られてしまいますので、そこまで細かくするのではなく、ざっくりとやりたいことを挙げていく方が分かりやすいということがわかりました。
よく書けているユーザーストーリーでは、以下の6つの要素を備えているそうです。
  • Independent(独立している)
  • Negotiable(交渉の余地がある)
  • Valuable(価値のある)
  • Estimatable(見積もれる)
  • Small(小さい)
  • Testable(テスト出来る)
今回のに当てはめると機能まで掘り下げてしまったので交渉の余地が少なくなってしまいました。
この6つを確認しながら書いていくと後々のタスクに分割する際にやりやすくなると思います。

よくある要件定義書や仕様書では、更新する際にいろいろ手続き等が発生して面倒なことがあったりしてコストが発生してしまいます。
後になって顧客が本当にやりたかったことと違い、また文書の更新のコストを請求してからという無駄なことを続けるというようなこともよくあると思います。

小さいカードに書くことで、詳しく書くことよりやりたいことを簡潔に表現することに意識を持ちますし、並べた際に優先順位を付けやすいとおもいます。

最後に

今後、やりたいこと等テンプレートに沿ってカードにしてやってみたいと思います。そうすれば何からはじめなければいけないのか、本当にやらなければならないのかをまとめて見られます。

道場のスタッフの皆様、会場を提供して下さった株式会社アットウェア様、ありがとうございました。