ラベル 勉強会 の投稿を表示しています。 すべての投稿を表示
ラベル 勉強会 の投稿を表示しています。 すべての投稿を表示

2016/01/22

Scrum Gathering Tokyo 2016

Regional Scrum Gathering Tokyo に行ってきました。

Scrum Gathering って何？

正式名称は
[Regional|Global] Scrum Gathering (場所)
になります。
Scrum （参照 スクラムガイド.pdf）を実践している人たちが集まり、発表をし、それぞれがそこから何かを学び取ろうという二日間丸一日ぶち抜きのイベントです。

今年は会社がお金出してくれたので気兼ねなくいけました。

どんな内容？

午前中は 開会の話 と基調講演で両方とも英語ですが、同時通訳機と同時通訳の人がいます。英語から日本語、日本語から英語どちらも対応しています。
私はがんばって同時通訳機なしでチャンレンジしてみたので、どれぐらいの精度だったのかはわかりません。

午後からは各自のセッションが基本的には30分ごとにあり、基調講演が行われたメインルームを２つに分けて２コマずつ同時進行で行われますので、自分が聞きたいと思う方を選んでみていく感じです。

参照：http://2016.scrumgatheringtokyo.org/schedule.html

Day 0

前夜に基調講演をする Bas さんや Ken さんを交えて飲み会しましょうというのがあったので、ほぼ飛び入りで参加してきました。
今年はEary Birdがあまり売れず、正規の値段でビシバシチケットがはけたからか知らないけど、飲み代は向こう持ちでした。ラッキー。
Kenさんとても気さくな方で写真も一緒に撮らせてもらいました。

Day 1

東京に久しぶりの大雪、色々な場所で電車がとまるとまる。
まさにエクストリーム出勤。
仕事だったら家に帰ってたけど、仕事じゃないから仕方ない！

Opening Talk

Scrum Alliance CEO の Pete Deemer さんがお話し。

Keynote

Bas Vodde さんの The Story of LeSS 。
LeSS に関しては前から気になっていたので、そこを聞こうと思ったけど、勉強会以上の情報はあまりなかったかなぁ。
一番気になったのが、Component team を Feature team にせよの箇所。
私のチームは Feature team 作ろうとして、Component team として扱われているよな。と猛省。

Sessions

参加したのは

  • No Reuse Before Use
  • Bridging the communication gap with Specification by Example
  • Offshore and Nearshore Scrum teams
  • ゲーム作りから導くスクラムマネージャー(資料)
  • Technology-Driven Development

どれも面白かったけど、一番面白かったのはTAI氏の Offshore and Nearshore Scrum teams かな。彼はベトナムでアジャイルコーチをやり、オフショアでスクラムを実現している。自分もベトナムとのオフショアでスクラムを導入しようと模索しているところなので、彼が言う成功の秘訣などはとても参考になった。

Open Jam

会場外でもセッションを行うスペースがあったので、そこでのセッションも参加してみてました。

Day 2

雪はあがり、打って変わって晴天。

Opening Talk

Scrum Alliance CEO の Manny Gonzalez さんがお話し。

Keynote

エッセンシャル スクラム の著者 Ken Rubin 氏による、 Economically Sensible Scrum 。
かなり実践的な内容で、定義から妥協案までいかにスクラムを経済的に成功させ実現させていくか、について語ってあります。読んだことなかったけど、エッセンシャルスクラム読んでみようかな。

Sessions

以下に参加

  • Cisco’s Agile Journey – Continuous Delivery and Scaling Scrum
  • レゴスクラムの覚醒 / The Lego Scrum Awakens
  • フィリピンのスタートアップにスクラムを導入しようとしてみたお話(資料)
  • 金融系ＩＴ企業におけるスクラムへの挑戦
  • Customer Expectations Management of Scrum スクラムにおける事前期待のマネジメント

文句なしに一番面白かったのは藤村さんの フィリピンのスタートアップに〜… 一番笑えた！そして何気に教訓もそこかしことに散りばめられててこれは良い。文句があるとすればマイクを使わないでよかったのではという声量ぐらいか(スタッフが慌ててマイクの音量を下げに行ったと裏話を聞いた)。
金融系〜は名前に偽りはないけど、ついつい金融業務にスクラム使ったのかと期待してしまっていたが、そこは肩透かしを食らった気分。でもやっぱアジャイルコーチいた方がいいんだよな。と感じる。

得た教訓

  • オフショアで２チームでスクラムやるなら、それぞれメンバー( ambassador )の送り合いをする
  • 前に進むパワーはかなり大事
  • スクラムの全体性はスクラムにとってはとても大事
  • Component team ではなく、 feature team を目指す。
  • Component team は cross-functional であることもあるが、 single component である. 参考
  • Feature team は cross-functional かつ cross-component である。
  • スキルセットはTゾーンであればよい。

参考

Regional SCRUM GATHERING® Tokyo 2016
スライド資料のRTをしているのでチェック > 公式ツイッター

時刻: 0 件のコメント:
ラベル: , , ,

2011/01/19

スクラム道.03 スプリント計画ミーティング

1/7日に永和システムさんで行われたスクラム道.03に参加してきました。
今回のテーマは「スプリント計画ミーティング」

Twitter上でも話題にあがっていたけど、
どうやらスクラム道のレポートブログが少ないらしい。
（私の場合は、平日は仕事の忙しさ、週末は子供と遊ぶのを理由に怠けてただけなんだけどね。）

ただ、レポートを書きやすいか書きにくいかでいうと書きにくい。

私が行ってる他の勉強会のスタンスは「Agileってこんなのだよ〜、W/Fの人にも分かりやすく説明するよ〜」ってノリが多いのに対して、
スクラム道は実際にスクラムを使ってる人たちの集いであり、専門的な話、実践している人しか分からない話が多い。
「下手な事はかけないなこりゃ」って気持ちがある。

今までは大した前提知識がなくても、なんとなく「Agileってこんなものなのか」と納得できてしまう内容だったのだが、スクラム道は「初心者歓迎」と書かれてはいるが、実際には初心者には厳しいのではないかと思う。

だが、そこがイイ。
一歩踏み込んだ議論の場ってのは中々ない。
ああ、私はこんなにスクラムの事を知らなかったのだな、と感慨深く思う。
（本読めよ）



大幅に横道にそれたけど、レポート書いていきます。

スクラム道の進行は三幕構成になっており、

  1. テーマに沿った読み手さんの発表
  2. それに対する質問とディスカッション
  3. 懇親会

となっています。


私はちょっと遅刻していったので、一幕の途中から参加だったのが残念。
参加した時はプランニングポーカーの話でしたね。

発表の内容はスプリント計画ミーティングについて。

ミーティングには１部と２部があり、
それぞれで各担当者（PO,SM,Team)の振る舞いが変わるといった話がメイン。
特にPOの扱いに関して発表の最中も色々と論議されてました。
※発表されたスライドの内容以下参照

Check out this SlideShare Presentation:
スプリント計画ミーティング
View more presentations from Miho Nagase.


発表が終わると次は皆で質問を持ち寄って喧々諤々と議論開始。
主たる話題は、POの扱いとタスクの分割をどのようにやるか、
特に「特定の人にしか出来ないタスク」をどのようにバラすか？
そのようなタスクを持ってる人の扱い方。
この辺りが実際にスクラムしてる人たちもお困りの様子。

議論が終われば懇親会へ行って皆で議論の続きをフリーディスカッションして終了。
酔っ払いの脳みそに残った記憶の残滓は

  • 「パッションは有限」
  • 「ScrumにCraftmanshipがないのはわざと」
  • 「スクラム道は初心者向けではなく一歩踏み込んだ議論の場」


まとめ
スクラム道は他の勉強会とは少しばかり雰囲気が違う。
パブリックな講演会ではないし、プライベートな仲間内での議論とも違う。丁度その間に位置する勉強会だと思います。


以下蛇足

二幕の議論の元になるポストイットの中で大して話題には上がってないけど気になった議題に
「タスク分割とWBSの違いは何か？」
がありました。

スクラムでのタスク分割はストーリー（バックログ）を実行可能なタスクにチームが分割すること。
W/FのWBSは作業工程を分割したタスクの積み上げで表すこと。
似たことを言ってるようだが、これらを同じものと言うことは直感的に違和感を感じる。

スクラム道の場では大した話題にはならなかったが、気になったので会社のW/Fラー達と話してみた。
（自論をぶつけてその反応を見るといった一方的な対話ではあるが）

まず、端的にスクラムのタスク分割を説明し、WBSと違うか？と聞いてみた
「同じものだと思う、言い方が違うだけではないか？」

そこで、もしWBSにマネージメント層もしくは客先のコミットメントが付与されていない場合はどう思う？
「そんなもの渡されても、取り扱いに困るだけだ。」

WBSとタスク分割の差はこれではないだろうか？
原理主義者が細かいところをつけば、タスク分割とWBSは違うと言うかもしれないが、私は両者は置換可能だと思っている。

しかしながら、実際の運用方法に大きな違いがある。
WBSにはコミットメントの付与が必要不可欠であり、
実際にチームの人たちが使う段階には、対内外的にコミットメントされている必要がある。
（comprehensive documentationであり、contractである）

こうでないと、W/Fのチームは作業を開始できない。開始してはならない。

よって、チームはWBSを変更できないし、
新しいタスクが発生したところでタスクの追加も出来ないので、
99％進捗イナズマ線ぐちゃぐちゃ現象なども発生する。

こんな感じだろうか。
時刻: 0 件のコメント:
ラベル: , ,

2010/12/23

よっぱらいの戯言　アジャイル系勉強会に参加して思う事

スクラム道02の帰り道もんもんと考えていたことをよっぱらいのまま書いてみる。

アジャイル系勉強会は楽しいね、ウォターフォールでは出来ないことをしている人たちと出会えるからね。
 
しかし、ふと思う時がある、まじめにアジャイルを求めている人と、
アジャイルにのっかっているだけの人がいないか？



ウォターフォールな会社にいる私は、社内に勢いでアジャイルをぶち込もうとしたことがある、
しかしながら彼らはアジャイルを蔑視した、理想論だが出来る訳がないと。

アジャイル勉強会にウォーターフォールの話を持っていくと、
嫌がられることが多い。彼らはウォーターフォールを理論的ではないと蔑視する。
（うまくいけば何でもいいんじゃない？と言う人もいるが正論だが議論にならない）



理論的でない超過労働は効率を下げる、適度な労働時間こそが効率を上げる秘訣だ。
むぅ、その通り、だがしかし、適度な労働時間とは何時間だ？

超過労働とは何時間から？
残業はよろしくないという、だがちょっと待って、
８時間労働の会社さんの人がそういう場合、
7.5時間労働の会社から見ると、既に３０分残業してるんですけど？

労働時間５時間の会社ならば、３時間のオーバーワークだ。
逆に１０時間勤務の会社なら後２時間は残業時間内に働けるよね。

え？３６協定とかで決まってるじゃない？
誰が決めたのその時間、アジャイラーが決めたの？誰がコミットしたの？
さて適度な労働時間っていくつだろ？

常に８時間働いている人は６時間ぐらいは集中力を持って働けるだろう、
常に１０時間働いている人は８時間ぐらい集中力を持って働けるだろう、
そんなのはアンチパターンだ、能率が出るわけないって？

そうかもしれない、君はそうかもしれない。
じゃ僕はどうなのかな？
そして本当に君の仕事は能率が下がるのか？

全てのプロジェクト、全ての人で最適解は変わってくる、
ベストプラクティスはないってのがアジャイルプラクティスで読んだ内容だったと思う。
多いに賛成する。

だから思考を止めるな。

話は変わるが、私はプロセス重視のウォーターフォールが嫌いだ、
なぜならそこに自分が考える余地がないからだ、自分の工夫の余地が少ないからだ。

アジャイルは自由だ、自分で考え、自分で実行し、失敗から成功を生み出す事が出来る。
（ウォーターフォールでも出来るじゃないかって？そうかもしれない）

だが、何人かの人間はアジャイルというプロセスを重視しているにすぎない。

ある人は言う、アジャイルで仕事をしていると、アジャイルでしか見積りが通らなくなる。



プラクティスはツールだ、それはその通りだ。
振り回されてはいけない、それは使うときの話だ。
だからさ、勉強会ぐらいなんでそのプラクティスが生まれたのか、
本当によいプラクティスなのか、使えないケースはないのか考えてもいいんじゃないか？
それを宣っているのがどこの偉い人だろうと、僕じゃないんだから。


アンチパターンもそうだ。
それで失敗したことがあるからこそのアンチパターンだ。
今日は勉強会の場でプロジェクトの見積り時「上級者のみで見積もることはアンチパターンだ」と出た。
理由は上級者のタスク消化イメージで見積られるので、
計画が実際にチームでこなされる速度よりも、はやい速度で見積もられるから。
なるほど。
だが待ってくれ、それ本当に上級者か？ただの業務に対する有識者じゃないのか？
他人に仕事降る際に適切な見積り（厳密ではない）が出来ない上級者ってありか？

勘違いしないでほしいが「上級者のみで見積もること」がベストプラクティスだと言ってるんじゃない。
またアンチパターンじゃないとも言っていない。
人に、そしてプロジェクトに依存するんじゃないのか？

ただし、理由が見積り時にチーム全体のコミットがとれないから、
上級者のみでの見積りは危険だ。という話なら分かる。


駄目だな、思考が発散するのでこの辺りで閉じる。

最後に一つ、禅の臨済録の中でつらつらと書かれている内容を見るに、
臨済義玄が嫌がっていた弟子の振る舞いは、禅ごっこをすること。

仏に逢うては仏を殺し、祖に逢うては祖を殺し、羅漢に逢うては羅漢を殺し、父母（ぶも）に逢うては父母を殺し、親眷（しんけん）に逢うては親眷を殺して始めて解脱し、物と拘（かか）わらず、透脱（とうだつ）自在なることを得ん。


アジャイルは大丈夫か？

時刻: 3 件のコメント:
ラベル: , ,

2010/06/11

[勉強会]qpstudyにいってきました。

まとめるの遅くなったけど、インフラ勉強会の
qpstudy - キューピー３分インフラクッキング - 第一回に参加してきました。

勉強会HP:


私はインフラの人間ではないのですが、
業務の成り行きで開発サーバー（Windows 2008）のインフラ担当になり、
聞ける人はGoogleかプレミアサポート（残時間わずか）の状態で、

「インフラって何やってんだろ？何やるんだろ？範囲が広いのはわかるけど、
インフラならこれは知っとくべき！ってことはあるんだろうか？」

等の疑問を解決すべく参加してきました。


qpstudy形式

Twitterの#qpstudyの流れを見て参加を決めたので、
どういったことをやるのか全く分からない状態で参加。

形式は長めのLT(Lightning Talks)形式、
通常LTは5分だが、今回は15分の持ち時間で次々と多種のテーマで講義が行われる形式。

全部で10程のLTがあったので、
全部を並べて紹介するのは長くなるので気になったLTを2つチョイス。


Mon, Muninによる楽々監視生活

サーバーの保守時に発生する監視の話。
今まで触れた事もない世界の話。

トレンド監視（予防の監視）
障害監視（事象がおきることの監視）

といった区分けがあるのだ！ってことしかわからなかった。

資料：

Perl & Web Server

今回のLTの中で一番面白かったかな。
内容は昔懐かしPerlの話。Perlラブの話。

その昔HP作成をした人は、
Perl+CGI / PHP って単語を良く目にしたはず。

で、大体の人は
  • Perl=昔＆遅い
  • PHP=新しい＆速い
みたいなイメージを持ってたと思う。


あいやまたれい！

Perlが遅いわけじゃないよCGIっていう仕組みが遅いんだよ！

PHPが速いのはApachにネイティブに組み込まれているからだよ！

mod_PerlっていうApachに組み込まれたタイプのPerlならPHPとそん色ないよ！

ていうか最近めちゃくちゃF/Wが進歩してるし！Plackだって出来たし！

むしろPHPよりPerl+CGIのがいんじゃね！

と勢いのあるセッション。
終わった後、Perlに対する熱い思いが残りました。

###
後、使ってるプレゼン資料が良かった。
全体に対する進捗が見た目にわかり、あとどれ位で終わるかが分かるプレゼンってのは見てる側が楽だね。

資料：


後は各LTで気になった単語を並べる

ITIL
ITサービスマネージメントのベストプラクティスらしい。
そういや応用情報処理試験にもなんか出てたね。
また機会があれば調べよう。

Agile
まさかインフラエンジニアの勉強会でAgileって単語を聞くとは！
リリース物がないからアレな感じもするけど、
要するにチームビルドに朝会などのAgileプラクティスを使っていこうよってこと。

WEB+DB PRESS
って雑誌があるみたいだ。

PKI
PKI（公開鍵基盤）のシステムを作ってる人がLTしてた。
急ぎのLTだったのでへーほーふーんとしか。



最後に

参加して感じたことは、インフラのテーマは幅広く、
インフラとはこうだ！と語れるものはないのではなかろうか？

現に今回雑多な方面のLTが並んでいたが、
私がやっている実業務のWindowsサーバー関係の話はついぞ出なかった。

それでも、聞いたものの中では何時か何かに役に立ちそうなものが数々見受けられた。
これほど雑多な良く言えば多岐にわたるテーマでの勉強会ってのも珍しい。

好き嫌いがわかれるところだろうが、
次のqpstudyも時間が参加させてもらいたいと思う。


時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)