2012年06月08日

[勉強会]社内でのランチ勉強会

※この記事は新しいブログに移行しました。

移行先は【社内でのランチ勉強会 – サウスポーなエンジニアの独り言】です。


タグ:勉強会
posted by yohhatu at 08:14 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年06月05日

[勉強会]「TDD Boot Camp 大阪 1.0」に参加してきました。

 「TDD Boot Camp 大阪 1.0」に参加してきました。
 全国各地からスピーカー、TA陣が集まって非常に豪華な顔ぶれでした。
 
#スピーカー、スタッフ、参加された皆さん、楽しい時間をありがとうございました〜
***********************

◆会場
 楽天さんのカフェテリアが良かったです。
 プロジェクター(2台も!)も無線LANも電源(さすがに座席分はないですが、タップで分ければ全然問題ありません)も完備で良かったです。

 椅子が硬い材質で長時間座っているとツライかもしれませんが、事前に主催者さんが「クッション持ってきた方が良いよ〜」て言っていたので問題なかったです。

 主催者の@bufferingsさんが「今後も勉強会で使って行きたい」と言っていましたが、本当に良い環境だと思いました。

 以下、完全に自分用メモ。
◆和田卓人(@t_wada)さんの講演「TDD のこころ – テスト駆動開発に大事なもの」
・BC(ブートキャンプ)では、(TDDだけでなく)ペアプログラミングも経験できる
・同じお題を解く(ので)コードレビュー大会ができる
→コードレビュー大会は初体験でしたが「他の人ならどう書くだろう?」を知ることができて新鮮でした(実際にこんなことはなかなか業務ではないので)。

・ソフトウェア開発の三本柱
 ・バージョン管理
 ・テスティング
 ・自動化
→現代的、合理的に開発するのに必要ってのはまさにその通りで。イテレーション0ではまずこれをするってのは鉄則かなと思います。
 逆にここを取りこぼすとそれなりにしんどい思いをすることにもなったり。

・バージョン管理
 ・RPGをセーブ無しでクリアしようするもの
→このメタファは良いなぁと思いました。それにブランチを切る時のメタファにもしっくり来ますし。
 今度(バージョン管理に理解を示さない人に)使ってみようと思いました。

・テスティング
 ・開発者が自分の書いたコードに対してテスト(コードを書いて)する

・自動化(自働化)
 ・オートメーション
 ・人間がやっている作業を機械に肩代わりさせる
 ・コンパイル、FTP…などを自動化する
 ・人間が使える時間を増やそう(人間にしか使えないことに時間を使うようにする)
 ・「自働化」は機械がやった結果を人間に教えてくれるってこと
  依存の矢印を逆にする。
 ・ポーリングすることで思考を非同期化して進めることができる

・三脚椅子
 ・三本柱だと切実感が足りないので、三脚椅子というメタファを言うようにしている
  ・「一本もないと安定してしまう」って言われたけど(笑)

・まずはバージョン管理から始めるのが大事

・「テスト」にまつわる混乱
 ・「○○テスト」が多い
  日本語の中でも「ユニットテスト」「単体テスト」の違いがあったりする。
 ・なのでモデルを単純化している
  ・「誰が何のために」
   ・DeveloperTesting:開発者が開発促進のために
   ・CustomerTesting:顧客(のロール)が進捗管理のために
    ※機能が出来上がっているかどうか?価値が出来上がっているか?…を0か1で判断する。
   ・QATesting:品質保証担当者(のロール)が品質保証のために
   ・この話の中には「何を、いつする」てのは入っていない。
  ・というわけで今日は「DeveloperTesting」をする

・TDDとは?
 ・書籍「テスト駆動開発入門」
  何か分からないことがあったらこの本に立ち返れば良い

・動作する、きれいなコードへ
 ・その方法論は2つあって、良い設計をしてその後コードにする…これで「動作するきれいなコード」になる。
  きれいな設計というのは「沼地」であって「完璧な設計」を追い求めるといつまでも終わらない。
 ・動かそうとして初めて分かるということがソフトウェア開発には多すぎる。
  なので、頭の中で考えているよりもはるかに多い。
 ・なのでまずは「(すぐには)動かない」汚いコードから、動作する汚いコードにする。
  その後、キレイにしていくってのがTDD。
→この四象限のスライドは知っていましたが、初めて直にお話を聴いてやっぱり分かりやすいなぁと思いました。
 一方、自分の所属組織の状況に照らし合わせた時にプログラミングをせずに設計する(実際は「設計書を書くだけ」かもしれませんが)人にとってはこの四象限の話はイメージできないのかな?とも思ったりしました。

・TDDと黄金の回転
 ・四象限に当てまめる
 ・汚い→キレイにするには意思がいる
 ・大事なのは小さいうちから初めてやる
 ・よくある質問で「リファクタリングのコストをどう説明するか?」
  ・小さいうちからリファクタリングをやっておけば良い
   大きくなると投資効果や説明責任が必要になってくる
 →リファクタリングを「個別タスク」て考えると確かにその通りで、「テストコードを書く(もちろん通る)」と「リファクタリング」もセットにして「プログラミング」タスクという扱いにしていくのが良いアプローチだと思っています。

・TDDをこころ
・少しづつ、少しづつ
 ・小さいDoneを少しずつ定義していく
・複数を相手にしない。ひとりずつ対処する。
 ・1つてストコードを書いて1つ流す

・すばやくまわす
 ・早ければ早いほど良い
→チームやプロセスにボトルネックがあると素早く回せないので、それも明白になって改善活動につながると思いました。

・素早く回っていないと「問題が大きい」「ピントがボヤけている」証拠。
 ・小さくすることで「どこが」ピントがぼけているかが明確になる。

・自分が最初のユーザ
 ・引数にString×6あるようなメソッドって自分が使う際に使いやすいと思うか?
 ・ドッグフードを食べるのが大事

・不安をテストに
 ・祈るようではダメ
 ・命綱を編むようなものがテストコード
  ・リリース=バンジージャンプ
   で、バンジージャンプする前になって命綱を編むのではなく、日々ちょっとづつやっておく

・TDDをはプログラミング技法
 ・最大のメリットは「心理的」なもの
  ・即座にフィードバックを得るため
  ・書いたコードに自信を持つ
  ・これから書くコードに自信を持つ

・TDDの真の目的
 ・変化に対応できるのは「健康」なコード
  ・無駄がない:引き締まっていて、贅肉がない
   ・重複がない、分かりやすい名前で、分かりやすい構造になっている
 ・チームの「健康」
  ・日々毎日動くかどうか分からないようなコードを残業して書くようでは「健康」ではない

・実装時間具合は1〜2割増、不具合は半分位に減る
 ・デバッグの工数が減らす
 ・要求が洗練された
 ・コードの品質を上げる
 ・開発工数を減らす

・TDDを導入したことによって減る工数=デバッグ
 ・軽微なミスが減る(テストコードもカバーしてくれる)
 ・小さいバグはコードを書いているのでテストコードがあるのでデバッグをほとんど必要でなくなる
  ・テストコードがないとデバッグ(推論)をしないといけない
   時間が読めないデバッグの工数が減る

◆デモペアプロ
 プロジェクターとの接続トラブルで急遽デモマシンを交換していましたが、これがまたキーバインドが違っていて更に混乱を…って感じでした(笑)。
 ペアプロの場合、お互いのツールやキーバインドが違っていると生産性(や気分)に影響が出るので、「合わせる」か例えばキリの良い所でコミットなりして、マシン毎交代するなどの工夫がいると思いました(以前、ペアプロやっていた時にはeclipse派とNetBeans派がチームに混在していたので、そうやっていました)。

 またメモ。
・とにかく最小限で書くってことが大事
・ゴールの最小限から書いていく
・仮実装
 ・「今書いたコードが絶対通る」コードのこと
 ・これで失敗するってことはテストコードがバグっていることがすぐに分かる
 ・「テストコードをテストコードが必要になるのでは?」の前に、仮実装をすることで「テストコードのテストをする」ことができる。そのタイミングがTDDとして良いタイミングである。
  もしこれをしなかったらミューテーションテストが必要になる。

◆吉岡弘隆(@hyoshiok)さんの講演「大規模ソフトウェア開発とテストの経験について」
・今日のメッセージ「開発者の皆さん、テストを書こう」
・安定性に差こそあれ常に動くものがある

・学んだイロハ
 ・マニュアルを読むこと
 ・テストを書くこと
 ・デバッグの仕方
 ・質問の仕方
・環境は変化する
・自分は変化しているか

お昼直後、かつ、吉岡さんの声が心地よくて、うつらうつらしてしまいました…(すいません)。

◆関将俊(@m_seki)さんの講演「どこまでがTDD?−-TDDの引き算と足し算」
・TDDの場合、最初の「目標を考える」のがポイント。
・まずはそれを書いてRedにする。
 テストに沿って実装する。
・壊してみる活動をTDDのサイクルに入れても良いのでは無いか?
・より良く、より強く…動く、キレイに続く指針
・Destoroyがキーワード

◆ペアプロ
・久しぶりだったので余計に疲れた(心地良い疲れだけど)。
・ドライバーでもナビゲーターでもあれだけ集中すれば疲れる。
 反省点として(TAの方からも言われたけど)もっと頻繁に交代、休憩を取りながらしたら良かったかも…と思いました。
・(直接TDDの話ではないですが)ペアプロやると設計やプログラムに対して不安が少なくなり、自信を持って進める(少なくとも2人の知識が入っている)ので、精神衛生上、自分にはとても合っているプラクティスだと再認識しました。

◆その他、懇親会
・グリーンバンドの話
 ・(プロフェッショナルでも)テストコードを書くのが面倒くさいことがある。でもそのグリーンバンドを見て、「プロフェッショナルであるならば、自分の書いたコードは説明できるのは、当たり前だし、テストコードを書くのが当たり前」と思い直す。

・吉岡(@hyoshiok)さんとお話できて良かったです。
 (社内外の)勉強会を主催したり、お手伝いすることがちょくちょくあり、その中で「勉強会と組織との関係」みたいなことを考えていました。
 なので、吉岡さんがブログに書かれているこのエントリなど(たくさんある)について話をしたかったわけです。

・(Skypeでは話したことがあったけど会ったことは無かった)きょん(@kyon_mm)さんとも会えてお話して、Groovyをえらく薦められたり(笑)。

***********************

 何よりも(特にペアプロやってる時の)熱気というか集中力がすごかったです(後で写真見て余計に感じました)。
タグ:勉強会 TDD
posted by yohhatu at 07:58 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年05月15日

[雑多]「XP祭り関西2012」でLTしてきました。

 もう1ヶ月以上前のことなのですが「XP祭り関西2012」に参加してして、LTをしてきました。

#スピーカー、スタッフの皆さん、楽しい時間をありがとうございました〜
***********************

◆自分のLT
 前回「XP祭り関西2011」に参加して、そこでもLTをしたので、せっかくなので「続きもん」みたいにやってみようと思いました。


 主題は「勉強会に参加したことが無い(主に社内の)人に対してやったこと」です。

◆スライドの補足
ここには同僚は来ていませんけどね
 スライド作った後で同僚が参加しているのに気づきましたが、せっかくの対比だったのでそのままにしておきました(苦笑)。

1:情報発信
 時々「誘っても全然来ないんですよ〜」て声を聞きます。
 やっぱり来ない人は来ないです。
 
 なので、まずは「広い層に対して(自分のリソースをあまり使わない方法で)アプローチ」しました。
 これが社内SNSにポストしたり、みんなでランチしている場で軽く話してみるなどです。

 そこで、興味を示した人によりリソースをかけて一本釣りに行きます。
#リソースって聞こえは悪いかもしれませんが、多くの方に来て欲しいですが、自分の時間も有限ですので。

 それぞれ興味の持ち方、「後一歩踏み出すため」のハードルが違ったりします。
 「勉強会」は怖くなく、軽い気持ちで行けば良いのですが、行き慣れている人の感覚でもあるので、そこを無理に「大丈夫だって」て押してもうまく行かないことも多いと思います。

 気をつけているのはアジャイルサムライにもあった「誰もがこの働き方を気に入るわけじゃない」というフレーズです。
 (残念なことですが)誰もが自分のレベルアップに一生懸命でも無いですし、レベルアップの必要性は理解しても、その実現方法は勉強会に行くだけではないので。

2:自社で社外勉強会
 平日夜開催なら(社員の方が)「残業をちょっと早めに切り上げて参加して(覗いて)みようか?」と少しでも思ってくれれば…と。

3:巻き込む
 ベースは巻き込む側の得意なパターンで良いのですが、ただ、同じく意識していたのが、人によって参加するきっかけ、しない理由はそれぞれ(性格ももちろん影響します)ってことです。
 なので、それぞれによって「響く言葉」を選んでいたように思います。

次は経営層やマネージャ層
 こういう層の方々は売上や利益など目に見える「数字」を(時には短いスパンで)達成することをより強く求められています。

 その環境の中で直接の数字に(すぐには)貢献しそうにない場を理解してもらう、また積極的に参加してもらえるのはなかなか難しいなぁと思っています。

 まぁ(技術的な勉強会などには)参加しなくて良いので「こういう存在があって、そこに(やる気のある)エンジニアがたくさん来ている」というのは知ってくれたら嬉しいです。
#もちろんビジネス的なセミナーや勉強会にはアンテナを張って参加して欲しいです。
***********************

 後日開催されたRxTstudyでは「勉強会初参加」の同僚も数人いましたし、細々と続いている(気がつくと30回を越えている)「社内読書会」にも若手の方が参加してくれています。
 (もちろん自分のアクションだけではないですが)少しでも貢献できているのであれば、嬉しいことです。
タグ:勉強会
posted by yohhatu at 07:20 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年05月11日

[雑多]「マシュマロ・チャレンジ」を体験しました。

 GWの谷間に「マシュマロ・チャレンジ」を体験しました。

 ちょうど先日、NHKのスーパープレゼンテーションで放送されたのでご存知の方もいるのではないでしょうか?

***********************

◆「マシュマロ・チャレンジ」とは?
 「タイムボックス」や「チームビルディング」などについて色々な学びを得る事が出来るワークショップです。

 使うのは1チーム毎に以下のものです。
1:パスタ20本(もちろん茹でていない)
2:マシュマロ
3:マスキングテープと紐を90cmずつ

 ルールは制限時間内にこれらの道具を使いながら、パスタでタワーを立てその上にマシュマロを乗せ、高さを競うというものです。

 詳しくは以下のブログに色々書いています。
 ただし、ネタバレ(このワークショップの色々な狙いや気づき)も書かれているので「いずれ(自分で)それを体験してみたい」という人は見ない方が良いと思います。
「チームとタワーを創造せよ!マシュマロチャレンジでチームビルディング #sgt2011 #CSPO」
TED


◆やってみた
 進行は原田(@haradakiro)さんにお願いしました。
 そしてメンバーは「スクラム道場関西版」(仮)の11人。
#「スクラム道場関西版」についてはまた今度書きます。

 比較的こういうのに慣れている、そして、やっていくメンバーだったので、ゴールとして「体験することで、自分達が進行できるようにする」というのもありました。

 3チームに分かれて開始しました。
 私のチームは全員が仮にも(ペーパーでも・笑)「認定スクラムマスター」でした。

 そして1回戦は3チームともタワーを建てることができました。
 ↓こんな感じです。
DSC_0229.jpg


 しかし、2回戦は(少なくとも自分は)完全にこのワークショップの狙いにハマって、見事に失敗しました(記録ナシ)。

◆気づいたこと
・ちょっとした状況でこんな簡単に視野が狭くなるのかってこと。
・視野が狭くなったら、チームがこんな簡単に機能しなくのかってこと。
・「なぜうまく行ったのか?そしてそれは再現可能なのか?」を共有するのが難しいってこと。
・小さくても良いから、ゴールに近い部品から作ることが大事ってこと。
・時間はあるだけ使ってしまう(その使い方が有効かどうかに関係なく)ってこと。

 
 ある程度、どんな狙いがあるのか理解していたにも関わらず、他にも色々気づいたことがあり、興味深かったです。
 そして自分達のシステム開発でも同じような状況に良くなっているということも改めて感じました。
***********************

 「ちょっとやってみたい」「体験してみたい」という方がいれば、声をかけてくれると嬉しいです。
posted by yohhatu at 08:32 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年04月23日

[雑多]「RxTstudy」(第4回)に参加してきました

「RxTstudy」の第4回で(スタッフ/発表者として)参加してきました。

#「RxTstudy」のこれまでの内容はこちらのサイトをご覧ください。

 今回は[雑多]RxTstudy第4回に向けてで書いたように「タスク管理」と「グループディスカッション」が特徴でした。

#参加していただいた、お話していただいた、準備/後片付けを手伝っていただいた皆さん、ありがとうございました!

***********************

◆スピーカーのみなさんの話を聴いていて思ったこと
 「自分のタスク管理」的なお話だったのですが、それぞれ今のやり方に行くまでの試行錯誤したことが伝わって面白かったです。
 「なぜうまく行かなかったのか?」をちゃんと分析して、次に活かして自分なりのタスク管理スタイルになっているような感じでした。

 新妻あっちさんの話にあったように「本に○○と書いている」と言っても、書き手と本人のコンテキストや性格をちゃんと分析しないと、テクニックや考え方を有効に使えない・・・と改めてて思いました。

◆自分のお話


 今回言いたかったのは「自分の調子と相談」でした。

 仕事内容にもよりますが「どうしても乗らない時間帯/日」というのはあります。
 その状態でタスクをこなしても良い質のアウトプットにならず、結果的に手戻りなどで余計な時間がかかってしまうこともあります。
 なので・・・
1:「調子の良い時間を長くするか?」・・・「調子の良い状態へ持って行く方法を知っている」
2:「調子の良い時間にいかに最大限のアウトプットを出せるか?」・・・「準備をちゃんとしておく」

 …が大事だと思っています。

◆グループディスカッション
 (2回目はスタッフ業のため参加しませんでしたが)1回目は「デジタル×チーム」の枠に参加しました。
 みなさん「Redmine」を使っていたようです。

 それぞれの悩み・・・「どうやってみんなに使ってもらえるか?」とか「レビューをどう回すか?」など・・・に対して「自分はこうしているよ〜」という話が少しはできたので良かったかなぁと。

 自分なりに印象に残って考えてみたいと思ったことは…
「チームで使ってその効果は出ているが、マネージャクラスへの報告資料的なサマリ情報も一緒に出したい」
 …ということでした。
#今のところの考えでは「マネージャ用には別のツール(ベースの情報はRedmineで良いけど)を使った方が受けが良いと思う」という感じですが。

◆その他
 「社外勉強会に行ったことが無い」同僚が3人ほど来てくれたのが嬉しかったです。

***********************

 第5回も夏頃に開催予定です(これから相談ですが)。
 決まったらRxTstudyのアカウントで、つぶやきますので、是非参加してください!

#「スタッフしても良いよ!」「スピーカー/LTしたい!」「ブログ書いたよ」とか感想のつぶやきは、ハッシュタグ#RxTstudyをつけてもらえると嬉しいです。
posted by yohhatu at 04:31 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年04月05日

[仕事]バーンダウンチャートの疑問を聞いてみた

※この記事は新しいブログに移行しました。

移行先は【バーンダウンチャートの疑問を聞いてみた – サウスポーなエンジニアの独り言】です。
タグ:agile SCRUM
posted by yohhatu at 06:49 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年04月04日

[雑多]自分が関わっている勉強会・コミュニティ活動

 社外勉強会やコミュニティ活動がマルチタスクだったり、これから活動するよ!ってなものもあり、整理したく書いてみます。

***********************

RxTstudy
 「Redmine」と「タスク管理」の勉強会です。
 少し前まではこの活動にパワーを使っていました。
 
 次回が第4回で、2、3ヶ月に1回のペースで開催しています。
 ありがたいことに「今度、話したい!」という声もちょくちょくあります。

◆(仮名)スクラム道場関西版
 「仮名」とあるようにこれから動き出すもので、どんな名前になるのか分かりません。

 「関西、大阪近郊でAgile(またはScrum)にフォーカスしたこぢんまりとした勉強会(ディスカッションがメイン?)」のような形で・・・
1:アジャイルを実践している/しようとしている人の「よりうまく行くためにはどうしたら良いか?」という相談をしたり。
2:アジャイルな開発でより価値を届けたいけど「うまくチームが機能していない」という問題を一緒に考えたり。
3:ユーザ企業で「アジャイルな開発でより価値を得たいけどどうしたら良いか分からない」という問題を一緒に考えたり。
・・・などをテーマにできたらと思っています。
 
 発端は・・・
「関西ではスクラムマスター同士の情報交換できる場所とかあまりないなぁ」
 …と思ったからでした。
 スクラムマスター同士が顔を合わすと、(コンテキストはそれぞれ違いますが)似たような悩みを持っていて、ディスカッションすることでその悩みの突破口が見つかることがあります。
 そういうシーンをもっと多くできると嬉しいのでは?と思ったわけです。

 「興味ある!」という方がいたらTwitterなりFacebookなりで声をかけてくれると嬉しいです。

◆DevLOVE関西
 DevLOVEを関西で開催するって内容です。
 今度で3回目です。

 過去2回に参加した方から時々・・・
「DevLOVE関西ってまたしないんすかね?」
「今度あったら行きたい」

 …と声をかけられていました。
 
 ということで、「この人の話を聴きたい!」という方もたくさんいるので、せっかくなので進めていくことにしました。
 @papandaさんを初めとしたDevLOVEな方々も手伝ってもらえるでしょうし。
 これも「関わってみたい!」という方がいたらTwitterなりFacebookなりで声かけてください〜

#他にも社内読書会や(大阪)Jenkins勉強会などがありますがメイン処はこんな感じです。
***********************
 
 (もちろん本業も大事ですが)こういうコミュニティ活動から得られたモノはすごくたくさんあり、大きいものです。
 私にとっては本業をがんばる源泉の1つでもあります。
posted by yohhatu at 03:44 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年03月23日

[仕事]仕事と勉強会の源泉の関係

※この記事は新しいブログに移行しました。

移行先は【仕事と勉強会の源泉の関係 – サウスポーなエンジニアの独り言】です。
タグ:考察 勉強会
posted by yohhatu at 08:06 | Comment(0) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

2012年03月22日

[雑多]RxTstudy第4回に向けて

 AgileJapan2012でも少しだけお話したのでこちらでも宣伝です。

 「RxTstudy」(第4回)が2012年4月21日(土)にあります。
 参加受付はATNDで行なっています。

懇親会の出足が毎回いまいちなので、こちらもよろしくお願いします(笑)

***********************

◆今回の特徴1:「タスク管理」に焦点を当てたセッションが多い
 過去3回では(「R:Redmine」に関する話が多く)なかなか「T:Taskmanagement」である「タスク管理」になかなか焦点を当てることができませんでした。
#これまでの過去3回の内容はRxTstudyの公式サイトにまとまっています。

 そこで今回は関西ライフハック研究会女子部新妻あっちさんなど(あまりRedmine色が強くない方・笑)にお話していただきます。
 「IT業界じゃないから…」という方も参考になる話だと思います。

#私も「個人のタスク管理」に焦点を当ててお話するつもりで、Redmineは出てきません。

 今更の余談ですが「RxTstudy」の「R」は「Redmine」で「T」は「Taskmanagement」を表しています。

◆今回の特徴2:グループディスカッション
 これまで「スピーカーが話す→それを聴く」という一方通行感がありました。
 また参加者のフィードバックにも「他の参加者と意見交換したい」という声もありました。
#質疑応答や懇親会でディスカッションできた方もたくさんいるとは思いますが。

 というわけで、グループディスカッションを設けました。

ATNDの文章より 
自分の自慢のタスク管理ツールをみんなに見せるもよし。
話すのが苦手な方は、今タスク管理について困っている事を相談するもよし。
タスク管理について、自由に話ができる場にしたいと思います。

 多くの方の話を聴いてインプットするのも良い事ですが、それにとどまらず(意見交換などを通じて)アウトプットをすることで、より良いものをRxTstudyで(自分も含めた参加者の方々が)得ることができれば…と(スタッフの1人として)思っています。

***********************

 まだ人数に余裕がありますので、興味がある方は軽い気持ちで覗いてみてはいかがでしょうか?
タグ:redmine RxTstudy
posted by yohhatu at 07:12 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2012年03月17日

[雑多]「AgileJapan2012」に参加してきました

 「AgileJapan2012」に参加してきました。
#色々準備をされていた(もちろん当日も)スタッフのみなさん、スピーカーのみなさん、ありがとうございました。

 去年は大阪はサテライトだったのですが、今年はメイン会場でした。
 各地からスピーカーが集まり、参加者の数もかなり多くとても熱い内容になりました。

#それでも平日ということもありスーツな方の割合が多かったですが

 私はご縁があって2つのセッションでお話してきました。
 Agile セッション「チケット駆動開発の課題と展望」とChange セッション「現場に続くAgileの道を語ろう〜アジャイルサムライ読書会が変えてきたこと〜」です。

 今回は「チケット駆動開発の課題と展望」での話です。

***********************


 今回は(あえて)「Redmine話」や「チケット駆動開発」を意識しませんでした。
 「チケット駆動開発をどうやったらうまく行くんだろ?」と期待されていたものとは違ったものだったかもしれません。

 ただ「Redmineを入れてチケット駆動開発をしたいんですけど・・・」という相談をちょくちょく受けるのですが…
「どんな風なチームにしたいのですか?Redmineを入れてそれをどう実現したいのですか?」
 …と聞くと「本当にやりたいこと」が実はRedmineで無くてもできることがあったりして「Redmineやチケット駆動開発をやることが目的になっている」事例もけっこうあるなぁと感じていました。
 ですので、今回のスライドのお話にしました。

 いくつかスライドの補足です(当日話したこととかぶるかもしれませんが)。

◆「守」の話
 他のメンバーのチケットの書き方、分割・更新のやり方が自然に目に入る機会が多くなり、チームに広まって行くことがあります。
 フリカエリなどで「分かりやすいと思ったチケットはどれだったか?」などとテーマでディスカッションするとより効果的です。

 理想はツールを介せずに、ノウハウや技術の伝承ができるチーム(組織)です。
 しかしロケーションの違い、その風土が無いなどでも(諦めずに)このような方法でもレベルの底上げのチャレンジができるという話です。 

◆「破」の話
 「改善タスクを行うリソースをどう確保するか?」ですが、チーム全員が改善を好き(得意)ではないですし、そればかりだと本業(お客様へ価値をもたらすシステム)もおろそかになります。

 しかし、改善しないとちょっとしためんどうや不便さがチームのスピード、モチベーションを低下させ、パフォーマンスを奪っていきます。

 スクラムマスターはこういう改善がそれこそメインになりますし、改善が得意なメンバーがいれば(本業のタスクとのバランスで)改善タスクを取ってもらうのも1つの方法です。

 ポイントは(スクラムマスターやプロダクトオーナーを含めた)チームが「改善は必要なタスク」と意識することです。

◆「離」の話
 「これまでがこうだったから・・・」「○○を今まで使っているから…」という理由でチームのパフォーマンスを上げるチャンスを逃さないように・・・というのが言いたかったことです。
 確かにこれまではその方法がベストだったかもしれません。

 でも今ではチームのパフォーマンスも変わって、周囲の状況も変わっているはずです。

 その中で、これまでの方法も含めて「今のチームが一番パフォーマンスを発揮できるやり方」を考えて行く方が(短期的には多少遠回りでも)結果として良い価値を届けることができやすくなると思います。

 コンテキストもそれぞれですし「そんな簡単には・・・具体的にどうしたら・・・」という方もいると思います。
 そんな場合、愚痴を聞くだけかもしれませんが、(もしかすると)何かお力になれるかもしれませんので、お気軽に声をかけてください。

***********************

 ちなみに(各セッションも良かったのですが)自分にとって一番勉強になったのは講師控え室での色々な方とのディスカッションでした。
 正解が無い話題が多い中で「自分はこう思う」を話して、それに対してフィードバックを(ダイレクトに)もらえる時間というのは、スピーカーをするメリットでもあると思います。
タグ:agile
posted by yohhatu at 15:52 | Comment(2) | TrackBack(0) | 仕事 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。