Viewing entries in
Agile

XP祭り2015に参加してきました

XP祭り2015に参加してきました

みなさんこんにちは。KEYチームの武永です。

今回は、先日行われた 「XP祭り2015 “俺も!!”」 に参加してきましたのでそのレポートになります。

XP祭りとは

日本XPユーザグループ(XPJUG)が主催しているイベントです。
2002年より毎年秋に開催されています。
私は今回が初めての参加です。

今回参加したセッション一覧

私が参加したセッションは以下になります。 オープニングは間に合わず基調講演からの参加になりましたが。。。

基調講演「XP lives, XP dies, XP lives again!!」

角征典さんによる基調講演のスライドは以下になります。

基本的に全てスライドに書いてあるので御覧ください。
個人的に印象に残っているのは「ときめき」というワードです。

  • TDD -ときめき駆動開発-とは
    こんまり流片付け術 では「捨てるモノ」ではなく「残すモノ」を選ぶが、 残すかどうか迷った時に「それはときめくか?」と先生は聞くらしい。
    ときめきは個人的なもので教えるものではない、最強のツール。
    エクストリームプログラミング の23章「時を超えたプログラミングの道」は、
    ときめきの道であり、 XPをやるときもみんなが「ときめく」必要がある。
    「ときめくプラクティス」を選ぶべきである。
    XPは「価値」と言ってるけど、それは届けた後にしか分からないよね?
    だから「無駄」とか「価値」じゃなくて、「ときめき」が重要。
    これが「ときめき駆動開発」。TDDだよね!

プラクティスを選定するときに「ときめく」ことが重要というのは個人的にもスゴく共感出来ました。
実際にプラクティスを選定する場面に立ち会わせたことはありませんが、
何かしらの課題を抱えていて、それを解決してくれるかもしれないものに出会った時に「ときめく!」のだろうなとはなんとなく感じることができるので。
このあと1日中「ときめき」というワードがどこかから聞こえてくることや、 セッションの資料に出てくることもあったのでみなさん同じ気持だったのかなとか想像してました。

結構笑えるネタが盛り込まれていたらしいのですが、
私には分からないネタが多くて反応できなかったことが結構ありました(汗)

“共感”でつながるアジャイルチーム

こちらは「共感コミュニケーション」というものをワークショップで体験してみるセッションでした。
スライドは以下になります。

4つのプロセス

  • 観察
    録画再生のように明らかな事実
  • 感情
    自分/相手が感じていること
    エンジニアは感情を出しづらい/感情を抑える傾向にある職業だと本に書かれているらしいです
  • ニーズ
    何を必要としているか
    感情の裏には自分が必要としているものがあるはず
  • リクエスト
    具体的な要求
    叶わなくてもいいから口にだしてみる

このワークショップでは、「感情」と「ニーズ」の部分について 「感情」と「ニーズ」を結びつける練習を行いました。

最初に「自分の感情」を感じるということをしました。
例えば

  • ときめくプラクティスを聞いた時は「面白かった」。なぜなら「ひらめきが欲しい」、「刺激が欲しい」というニーズが「満たされた」からだ。
  • 基調講演を聞いて「ショックを受けた」。なぜなら一部理解できない話があり、「情報や知識がほしい」というニーズが「満たされなかった」からだ。

というように、どのような感情を持っているのか、その感情の元となるニーズを探ることで、
自分・相手が欲しているものは何かということを探っていくことをしました。

「自分の感情」を実際に他の人に上の例文のような形で話してみると 「本当にこの感情とニーズは合致しているな」と改めて納得した部分もありました。
しかし、「この感情はこのニーズと合致しているのか?」と自分に疑問を持って相手と本当のニーズを探してみると新たな発見もありました。
自分のことなのに実際に口に出してみると相手にも伝わるし、自分も新たな発見ができるという非常に面白い体験でした。

次にペアの人の話を聞いて、その裏にある「感情とニーズを探る」ということを行いました。
何かの感情にまつわる1つの出来事を相手に話して、相手はその裏にある「感情」を当てたあと、2人でニーズを探していくという練習でした。

これが非常に難しくもあり、面白い時間でした。
相手の話の裏に隠れている感情を探るのは難しく、そこからニーズを探るのはさらに難しかったですが、
探ろうとして深堀りして聞いていくうちに新しい情報が出てきてもっと相手のことが知れたり、
自分のことを知ってもらえるようになるのだなと感じた時間でした。

TDDライブコーディング

こちらは「ときめき駆動開発」ではなく本当に「テスト駆動開発」の方のTDDライブコーディングです。
まずはTDDについて説明と登壇者のきょんさんが大事にしていることの説明がありました。

TDDの3原則 by Uncle Bob

  • 失敗するテストが出来るまでプロダクトを書いてはいけない
    最初Greenにした時に、一気に追加実装してしまうのはTDDあるあるだがやってはいけない
  • 失敗するテストがある場合にはそれ以上テストを追加してはいけない
  • テストを成功させるプロダクトがある場合にはそれ以上プロダクトを追加してはいけない

要求や設計の反映

テストが失敗した時に判断できるようにする

  • バグを埋め込んでしまったからか。
  • 意図された振る舞いは変わらず関連性があった部分が何処か別の場所に移されていたのか。
  • 振る舞いがもはや正しくない。システムの前提が変わってしまっているのか。

分析と設計

  • 分析には主にミカドメソッドを使う
  • 設計には主にTDD/BDDを使う

そして実際にライブコーディング。
https://gist.github.com/kyonmm/6102436 にあるTODOリストをTDDでコーディングするのを見ていくセッションでした。
もっと時間があればワークショップにしても良かったらしいですが、90分枠でライブコーディングになったらしいです。

ライブコーディングの様子

そして出来上がったコードがコチラ

最初Greenにした時に一気に追加実装してしまうのは割りとやりがちなので気を引き締めたいところです。
きょんさんは非機能系(パフォーマンスとか)のテストも最初から入れるとのことで、
特に性能テストとかは最初から書いておくらしいです。
実際にどういうテストを書くのかあまり想像できていないので個人的に聞いてみたいです。

LT祭り

そしてLT祭り。
毎年レベル高いと聞いていたのですが、噂通りでした。

それぞれ公開されているスライドを以下に紹介しておきます。

クロージング

最後の最後に協賛の出版各社様からの献本が参加者にプレゼントされました。

私はプレゼントを貰える条件の1つ

XP祭りに初参加で、入社5年目以内

という条件に当てはまったのでこちらを頂きました。ありがとうございました。

最後に

非常に良い刺激を受け続けた1日でした。
一度読みましたが、もう一度エクストリームプログラミングを呼んでみようと思いました。
そして今回聞いたものですぐに使えそうなのものはどんどん実践していきたいです。
例えば共感コミュニケーションなどは非常に練習が必要だと思うので常に意識しながら会話していきたいですね。
今回参加できなかった他のセッションも興味深いものが多いので、スライドをあとで見ようと思います。
来年もきっと参加します!!

学生相手にAgile講習をした話

学生相手にAgile講習をした話

みなさんこんにちは。KEYチームの武永です。

こちらの記事にもあるようにatWareでは今年もインターンシップを受け入れています。 その中で私がインターン生に向けてAgile講習を行ったのでそれについて書いていきます。

Agile講習開催の経緯

KEYチームがメイン担当としてインターン生を受け入れており、
私と円城寺(円城寺の記事はこちらから)が認定スクラムマスターの資格を持っていて
実際のプロジェクトをScrumで取り組んでいることもあり、Agile講習を行うことにしました。
自分のAgileに対する知識・経験の把握と社外の人向けプレゼンの練習になると思って
私がメイン講師になり、円城寺のサポートを受け、講習を行いました。

Agile講習の内容

流れとしてはウォーターフォールの紹介、ウォーターフォールでの問題点から
紙ヒコーキワークショップを実施し、Scrumの説明という流れで行いました。
私はウォーターフォールのプロジェクトを経験したことが無かったので教科書的な説明になってしまいましたが。。。
使用したスライドは以下になります。

講習の様子

函館ラボにもインターン生が来ていたのでリモートで行いました。

以下の動画は実際に紙ヒコーキを飛ばしているところです。
楽しそうに実施してくれて良かったです。

紙ヒコーキワークショップ結果
予測 実測
1 5 1
2 3 4
3 8 10
4 11 8

紙ヒコーキを飛ばしたらみんなで後片付けをした後にScrumの説明を行いました。

本当は2時間程の予定でしたが、1時間半程で終了してしまいました。
学生の頃の経験で10分・20分程度の短いものの時間感覚はあるのですが、
1時間超えというものは初めての事だったので非常に良い経験になりました。

インターン生からの感想

講習後個別に感想を聞いてみました。

  • 分かりやすかった
  • 紙ヒコーキワークショップが楽しかった
  • なんとなく分かった
  • Scrumのことはなんとなく知っていて、ワークショップで「なるほど」となるところが結構あった。

直接聞いたので社交辞令的にプラスの意見が多かったのかは分かりませんが 皆さんから良い感想が聞けて非常に嬉しかったです。

反省点

学生側からはプラスな感想が出来ましたが講習を聞いていた社員からは
「話すの速かった」、「知っている前提の内容が結構あった」などのご指摘を結構受けました。
Agileの知識・経験不足、対象者を考えたプレゼン作りなどなど
自分に不足している部分を改めて実感できた良い経験になりました。

最後に

今回の講習を受けた学生の刺激になり少しでもAgile・Scrumについて勉強するきっかけ作りになれたなら最高だなと感じています。
それと同時に自分ももっとAgile・Scrumについて勉強していこうと思える機会になりました。

またこのような発表する機会があるのなら上手く行った点、反省点を活かして行いたいと思います。

認定スクラムマスター研修に参加してきました

認定スクラムマスター研修に参加してきました

みなさんこんにちは。KEYチームの武永です。

先日開催された認定スクラムマスター研修に参加してきました。

参加までの経緯

現在私が参画しているプロジェクトはスクラムを取り入れており、普段から「スクラム」や「アジャイル」という単語をよく耳にする環境にいます。
そこで、「スクラムについて学ぶことで実際の業務に役立てていきたい」、「アジャイル・スクラムについて学んで今後のコミュニティ活動などにも活かしていきたい」という思いを持ち参加することにしました。

認定スクラムマスター(CSM)とは

ScrumAllianceが認定してる資格の一つです。
「スクラム」と呼ばれるチーム開発手法における役割の1つになります。 スクラムにはスクラムマスターというロールがあって、そのロールをこなすための知識を認定しているのがCSMです。
決してスクラムをマスターしていますということを認定している訳ではありません。 (とはいえスクラムマスターの役目を果たすにはスクラムのことを正しく理解し、説明することが必要)

研修内容

  1. イントロダクション
  2. スクラムの歴史
  3. スクラムの理論、コンセプト、プラクティス
    1. アジャイルについて、アジャイルはなぜうまくいくのか
    2. スクラムの3つのロールモデル: プロダクトオーナ、スクラムマスタ、チーム
    3. スクラムの4つのミーティング: リリース計画、スプリント計画、デイリースクラム、スプリントレビュー
    4. スクラムの3つのリスト: プロダクトバックログ、スプリントバックログ、障害リスト
    5. プランニングポーカーによる計画
  4. リリース計画
    1. プロダクトバックログ
    2. プロダクトバックログ作成演習
  5. 生産とスプリント
    1. スプリントのゴール
    2. スプリント計画
    3. タスクボード
    4. デイリースクラム
    5. バーンダウンチャート
    6. ベロシティと障害物
    7. アーキテクチャとインフラ
    8. 完了の定義
    9. スプリント署名
    10. スプリントのプレゼンテーション
  6. ベロシティ・ゲーム
  7. 障害に打ち勝つ
  8. マネジメント、分散、スケールアップ

基本的にスライドを見ながらの座学を中心にワークショップを交えながらの2日間でした。

学んだこと、感じたこと

  • スクラムマスターの役割
    スクラムマスターとは開発が「スクラム」と呼べる状態にする人のことで、 開発チームに対して指示はすることもなく、プロセスの管理をする。
    チームがチームを管理して自律的なチームを目指す。
    スクラムマスターはチームが困っている時に助言する
    チームの障害となるものを取り除いていく。
    例えば、 プロダクトオーナー(PO)がスプリントの途中で別のアイデアを考えたからそれをスプリントに取り入れてくれという要求を出してきた際には

    「確かにそれはいいアイデアですが、このスプリントには入れずに次のスプリントに入れていきましょう」

    というようにPOからの新しい要求(障害)を取り除いて開発チームが上手くスプリントをこなしていけるように環境を整える役割を持っています。
    もし、この要求を受け入れてしまえば開発チームのリズムというものが崩れてしまいスプリントが上手く回らなくなってしまいます。このリズムを崩すこと無く開発を進めていけるようにするのがスクラムマスターの役割なのではないかと感じました。

  • 非効率の「3つのM」

    • Muda:ムダ
    • Mura:ムラ
    • Muri:ムリ

    この3つをどんどん無くしていくことでチームをより良いものへとしていくことが必要。

    「チームを加速させようとしていくのではなくムダ、ムラ、ムリを無くしていくことで間接的にチームを加速させていくことが重要」

    特にこの言葉が印象に残っています。
    何か良いツールや手法など新しいものをどんどん取り入れていくと、逆にどれも中途半端になってしまい、チームを減速させてしまう。そうではなくて現在のプロセスの中に潜む3つのMを取り除いていくことでチームを加速させてから新しいものを取り入れていく方がより良いチームへ成長していけるのではないかと感じました。

    スプリントを上手く回していく、より良いチームにしていくためにはどんどん3つのMを取り除いていく、改善していくということが大切です。

最後に

研修は受けましたが、まだ資格は取得していません。研修後、オンラインの試験を受けてから正式に認定スクラムマスターの資格が得られます。
「改善」というものを常に意識して自分達はチームの一員で自分達がチームを良い物に変えていくという考えがとても重要なものなのだと改めて実感した研修でした。
今回参加した研修でスクラムの「型(守破離の守)」を学ぶことが出来ました。まずは、ここで学んだことを実際に実践していくことで「知識」でしかない部分を「経験」にしていけばスクラムマスターに近づいていけるのではないか、より良いチームにしてくことができるのではないかと考えています。
とりあえず、早くオンライン試験を受けて正式に資格を取得したいですね。
もっと研修のこの部分の内容を知りたいなどありましたら以下のメールアドレスまでご連絡ください。
takenaga at atware.co.jp