「ラーメン二郎にまなぶ経営学 ―大行列をつくる26（ジロー）の秘訣」を読みました

読んだ本

感想

ラーメン二郎にまなぶ経営学 ―大行列をつくる26（ジロー）の秘訣

昨年の6月に職場の先輩ジロリアンにエスコートしてもらい、ラーメン二郎目黒店を経験してよりラーメン二郎がちょっとしたブームになっていた事もあり手にとってみました。

内容としては、マーケティングの基本的な考え方が時に自然に、時に若干強引にラーメン二郎と絡めて解説されています。

ラーメン二郎が好きでマーケティングに初心者の私のような方にはおすすめです。
楽しく読めると思います。（私は楽しかったです）

著者の二郎への愛情と、時に自然に時に強引に二郎と経営学（マーケティング）的な考え方を解説いく方式は、二郎好きな私にとっては飽きずに楽しく読めて良かったです。
肝心の内容も、マーケティングに用いる様々な考え方が解説されており、初心者の私でも特に挫折することなく読めました。

2016/1/19 Regional SCRUM GATHERING® Tokyo 2016 に参加しました（二日目）

1/18,19の二日間にわたって開催された Regional SCRUM GATHERING® Tokyo 2016に参加してきました。
一日目に降った雪は残っているものの、2日目はとくに遅延もなく会場に着けました。

togetter はこちら

Economically Sensible Scrum

エッセンシャルスクラム氏によるKeyNote

経済合理的性 を何度も強調していました。
Scrumのベストプラクティスや、こうすべきという話はもちろん根拠があって参考にすべきだが、
結局儲かってなんぼなので、そういう観点であえてベストプラクティスに沿わない選択をするケースもある。

大事なのは 経済合理的性 ということでした。

例えば、一日目のキーノートではフィーチャーチームがいいよという話だったそうですが、
経済的合理性がコンポーネントチームにあれば、コンポーネントチームと言う選択肢も取るべきだろうといったことも言及されていました。

確かに、儲からないことにはどんなに理想的なプラクティス、プロセス出会っても事業が継続できないですよねぇ。

「Scrumに従う必要はあるがそれだけでは十分ではない、経済合理性のあるScrumをする必要がある」

レゴスクラムの覚醒 / The Lego Scrum Awakens

スライド

XP祭り2015の基調講演や、XPの第二版を始め様々な良書の翻訳もされている角さんによるセッション。
度々有償でセミナーが開催されているレゴスクラムは
「全体性」があり「経験学習モデル」で効果的に学習でき「開発者以外も参加」できる。
この点からスクラムの学習に最適という解説でした。

レゴスクラム

レゴスクラムのマニュアルは翻訳されているのでぜひやってみてくださいとのことでした。

印象に残ったのは「みうらじゅん＆タモリ理論」からのワークショップ疲れ→もはや「ゲームしかない！」の流れです。

セッションを聞いて思ったのは、初期投資は必要な物の、紙飛行機ワークショップの代わりにでもぜひやってみたいと感じ米sた。

フィリピンのスタートアップにスクラムを導入しようとしてみたお話

アジア圏に可能性を感じた！と言っていたと思っていたらほんとにそっちの会社に転職して、来月からダナンに行くという藤村さんのセッション。

内容はスライドを見ていただくとして。

非常にアツく面白いセッションでした。

金融系ＩＴ企業におけるスクラムへの挑戦

ニッセイ情報テクノロジー株式会社の社内でのScrum導入のお話。

publickeyで記事になってました前編後編

チームがScrumを導入するときに組織としてのサポートは重要
  • 今までのウォータフォールベースの社内標準プロセスから逸脱する許可を得た
  • 看板などの掲示物はセキュリティ的に問題ないと説得した
立ち上がりをスムーズにする試み
  • アジャイルコーチをおねがいした
周りからみて楽しく見えるような工夫をした
  • スプリントごとにスローガンを決めた
  • プロジェクト公式キャラクターを作った
  • お菓子神社をつくった
報告に工夫をした
  • WBSなどの旧来の報告方式から
  • プロダクトバーンアップチャート
  • スプリントバーンダウンチャート
やってみて
  • 価値のあるものに注力
  • フィードバック
  • テストツールが充実した
  • 自主的な行動
  • コミュニケーションの活性化
  • モチベーションUP
  • 自分たちでやってる感

People As the Conveyer of Knowledge (知識は人が運ぶ)

平鍋さんによるおはなし。

当日のスライドの日本語版のスライド

  • スクラムは海外発祥と思っているかもしれませんが、その源流は日本人が発表した論文
  • SECIモデルを利用してのプロダクト開発には暗黙知の共有が重要である。
  • それ故プロダクト開発は（角さんのセッションでもあった）「経験学習モデル」と学びが重要。
    • 松下電器がホームベーカリーを開発した時はエンジニアが一番好きなパンを作っている職人に弟子入りした
      • 知識は暗黙知が多く、ドキュメントだけでは伝えられない
      • ソフトウェアは共感で繋いでいく
  • 究極のプロダクトオーナーは何を作るのかを共感

野中先生はヨーダ

  • とあるセミナーでの質問「ステークホルダーが多くて調整が大変です、どうすればいいでしょう」

    • 合宿をしなさい

  • 合宿をすると一日目で形式知ができる

    • 食事して、メンバーのバックグラウンドがわかり
    • なぜここにいるのかというはなしになり
    • そこからプロダクト開発の話が始まる

以下メモ。

RSGT2016 Day 2 Scrum alliance talk

Forbs 100 -> 今は一社しか残っていない→変化に適用できていない→変化に適用することが必要

Economically Sensible Scrum

大きな組織ではチームレベルではScrumがうまく行っているが、収益ができてない
→経済的合理性がないから
→阻害要因
経済合理性のあるスクラムをやってほしい

Scrumの概要説明

→ Scrumは成功に必要だが、十分ではない

Scrumに違反しない＝Scrumで成功 とはいえない

4つの阻害要因

  • アジャイル原則に沿ってない
  • アジャイルの原則を社内に適用できていない

  • 経済合理性が考慮されていない？

  • 経済合理性の中でアジャイル原則を適当できていない

→ スクラムとその原則を理解する必要がある

経済合理性のあるScrum

ライフサイクルプロフィット
→違った変数で表現されるプロダクトの価値を比べる時の尺度？

遅延

変更コスト

JITの誤解

ScrumなのでJITでやるます→見通しは立てません は間違い→バランスが必要
→見通ししすぎ→推測しすぎ沼
→すべてをJITで→Sprint1に入ってストーリー作るの？
→事前作業は必要なやる、だがやり過ぎない

WIPの問題

ソフトウェアの在庫
→見えないから、ないと言われがち
→在庫を見える化すればいい

ソフトウェア開発の最もかかるコスト
→人件費
→テスターが60%しか稼働していなかったらそれは無駄ですね
→Projectを掛け持ちして稼働率を100%にする→ムダがなくなりました→これはだめだよね。

リレーのメタファ
→リレー選手の稼働率は25%
→残りの75%はどうする？
→すきま時間に別の競技に出る
→そうではない
→リレーの目的からすれば稼働率100%ではなくて、25%でバトンを誰よりも早く繋げば最も価値がある。
→稼働率100%はプロダクトの価値を高めない、収益性は上がらない。
→バトンがつながらない時のロス

[参考]バリューストリームマップ

Idle Workに注目しない！

キューイングすることの無駄
→Fast flexible flow

計画

バリューチェーン

Portfolio Planning

  • 遅い車（トラクター）
    →ボトルネックになる→遅延コストがかかる

  • アジャイルの原則をポートフォリオレベルでは使わない

パートナー

→アジャイル開発の契約書を作るべき

変化への抵抗

→ 変わることに対して抵抗勢力がある

全体が見えていない

→ システムレベルでの最適化をすべき

組織構造を経済合理性のある形にあってない

マルチタスク

  • 稼働率を上げるためにマルチプロジェクトとか
    → ダメです

  • マルチタスクは能率を下げる

    • 1prj = 70% の付加価値を提供できる
    • 5prj = 30% の付加価値しか提供できない
      →マルチタスクは経済合理性がない

    2pararellだとちょっと効率が上がる
    → 1プロジェクト目がブロックされたら2つ目に逃げられるから？

T字スキル

  • BROAD + DEEP

長生きチーム

  • プロダクトごとにチームを作るのは経済的に良くない
    →チームを解散すべきではない

  • 消防士
    →チームを解散させると効率が下がる

→ チームの経済効率性を考える

チームの分け方

  • コンポーネントチーム
    → GUI・Serversideなどで分割されている

  • フィーチャーチーム
    →クロスファンクショナル
    →クロスコンポーネント

コンポーネントチームに取ってフィーチャーなものが、フィーチャーチームにはタスクである

アジャイル界隈ではコンポーネントチームは良くない、フィーチャーチームがおすすめと言われている

コンポーネントチームで複数のフィーチャーを実装しようとすると、バトンが下に落ちた状態になる。
→チーム間のコンセンサスが取れない？？

  • この辺よくわからん？？？

経済性にしたがってスケールしましょう

まとめ

  • Scrumに従う必要はあるがそれだけでは十分ではない、経済合理性のあるScrumをする必要がある

質問

  • コンポーネントチームのPO ＝ テックリード
    → テックリードはビジネスをあまり考えない
    → コンポーネントチームをなくす時も経済的な合理性があるならよい

    • 消防署は東京で一個とかはありえないですよね
      → そういった場合は各区に消防署はあるべき

フィーチャーチーム、コンポーネントチームにするにせよ、マルチタスクと考えるとT型スキルにはならないのでは？

→チームにはT型にはなってほしい
→クロスファンクショナル

→マルチタスキングは完全には解決できない
→フィーチャーチームとコンポーネントチーム同時に所属するのは正しいが、マルチタスキングしちゃいけないという意味では正しくない

レゴスクラムの覚醒 / The Lego Scrum Awakens

http://www.slideshare.net/kdmsnr/legoscrumawakens20160119

レゴスクラム

→翻訳してるのでやってみてね。

OpenStack

→OpenSourceのモデルをレゴで表現してみよう
→フリーのコントリビューターがいるのがほかと違う

アジャイル開発の体験に最適

レゴスクラムの3つの特徴

経験による学習ができる

スクラムガイドと実践の間を埋めるためのレゴスクラム

経験と教育
→教育とは日常に溶け込んで行くべきだ

経験学習モデル
→まず経験する

みうらじゅん＆タモリ理論

ワークショップ疲れ→もはや「ゲームしかない！」の流れ

全体性が備わっている

ホールネス
→ぶぶんぶぶんで違っていても全体として合っていればOK
→見積もりとか、部分のトレーニングは意味がないのではないか？

デイリースクラムが時間の関係でない、後で研修する。
時間が短い1スプリント7分
→それ以外はスクラムそのもの

開発者以外でも参加できる

スクラムチーム以外、関係者、ユーザーすらも！

フィリピンのスタートアップにスクラムを導入しようとしてみたお話

経験

→食いっぱぐれない！！！！！
→金を払ってでも得たい経験！！！

0週目

  • 明確ではないけどなんか良くないよねという状態

  • 勉強はしてくれなかった！！

1週目

  • KPT2

  • 日本とフィリピント特に変わらないKPT

2週目

だんだん暇になる→隙間タスクをやっていた！

金融系ＩＴ企業におけるスクラムへの挑戦

WFとスクラムを足した感じ
→要件定義＋基本設計 WF
→予算承認
→開発以降はスクラム

アジャイル→生産性が高いという噂
→途中からメンバーを追加した 開発T6人 PO2人中野さんが忙しいのでサポートとして一人入れた

導入は1Day研修を受けた

社内の標準開発工程を適応しない申請をした！

看板も掲示したままでOKとした。

アジャイルコーチをお願いした→豆蔵山田さん

デイリースクラム

→今日やることは最後にみんなで決める
→報告チックになっていたので、ファシリテートは持ち回りにした

KPT

Tryの確認をスプリント中間で行う

コミュニケーションの活性化

→周りから見て楽しそうに見えるように

  • スローガンをスプリントごとに決める
    → POが20分以内に今スプリントでやることを踏まえて決める

  • キャラクターの作成

  • お菓子神社

  • HELPカード

課題

進捗と品質の報告

  • WF
    • 計画通りか
  • Agile
    • 実績を計測して
    • 収束予測する

進捗の報告方法

  • プロジェクト
    →プロダクトバーンアップ

  • スプリント
    →バーンダウンチャート

品質の報告

  • ツールを導入して計測した

成功の要因

カイゼンの繰り返し

  • ルールをシンプルにする
  • 効果的でないならやめる

チームを取り巻く環境

  • 外部からの阻害が少なかった
    →初アジャイルなので、暖かく見守ってもらえた
  • メンバー
    →自己組織化できてた
    →リードするキャラがいた
  • アジャイルコーチを活用した
    →立ち上げがスムーズに
    →ちょっとしたことが相談できる

プロダクトへの効果

  • 価値のあるものに注力
  • フィードバック
  • テストツールが充実した

意識

  • 自主的な行動
  • コミュニケーションの活性化
  • モチベーションUP
  • たのしいかいはつ
    →自分たちでやってる感

今後の展望

社内への展開

社内開発支援組織を設置

複数チーム体制での開発

顧客も含めた開発への適用

People As the Conveyer of Knowledge (知識は人が運ぶ)

Slide日本語版あるよ→SlideShare
http://www.slideshare.net/hiranabe/nonakas-scrum-phronetic-leadership-and-requirements-development

アジャイル開発のコンセプトは日本が寄与している

海外プレゼン時にはその地で流行っているアニメを入れるとつかめる

The new new product development game が Scrumにあたえた影響

  • Scrumの黒い本
    → 扉の次のページに引用

  • リレーレースのモデルからラグビーのモデルへ

  • New New

    • 新しい
    • New Product
    • 新しい新製品開発

  • Scrumを編み出すときに100くらいの論文からこれだと選ばれた

  • TypeC Scrum の語源もこれ

  • プロダクト開発と同じく、関係者を巻き込んで行く進め方

  • 野中先生
    → Yoda

  • アメリカ海兵隊
    → クロスファンクショナル

  • Wise Leadership
    →Phtonetic Leadership

  • TypeC Scrum
    → 最初は刺し身にしようとした→ボツ

SECI-Model

暗黙知

  • more then you can tell
  • やってみるほうが早いこと、一緒にやって覚えること
    →自転車の乗り方とか
  • 同じ体験をすることによって伝わる
    →言葉がなくてもつたわる
  • ミラーニューロン
    →暗黙知暗黙知伝達

形式知

  • パターン、マニュアルなど

  • 知がポータブルになった

  • Sticky information
    →暗黙知にちかい

SECI Model

  • T-T

  • T-E

  • E-E

    • 組み合わせ特許

  • E-T

Story

  • 知識創造企業

松下電器がホームベーカリーを作った時のはなし

野中先生

  • 新製品開発の最初は暗黙知にある
    →想いからはじまる

  • PDCA → イクナイ → Planする前にみんなで何かをしよう→暗黙知の交換

  • パン焼き職人に弟子入り
    → 最終的には開発チーム
    → 実験＋実装＋暗黙知暗黙知変換
    → パン焼き器できた
    パン焼き職人の暗黙知からリブを作るという形式知になった
    → SECIモデル
    → 新製品開発においてT-E変換がいかに大事か

Design Thinking

→最初に「共感」がある！

  • Role Playing
    →実際のユーザーの共感をトリガーに

  • Bodystorming
    → 体で感じろ

T-T

  • pair programming

知識はどこからきてどこへ行くのか

  • 知識は暗黙知が多い

  • ソフトウェア開発は共感で繋いでいく
    →形式知、ドキュメントだけでは伝えられない

  • Honda
    → 作ろうと思っているもののユーザー視点になる
    → 共感して、もちかえる

究極のPOは何を作るかを共感

Scrum
→ 知識の運びては人であると宣言したもの

ステークホルダーが多くて調整が大変だ
→ 合宿をしなさい

→一日目で形式知ができる
→食事して、メンバーのバックグラウンドがわかり
→なぜここにいるのかというはなしになり
→そこからプロダクト開発の話が始まる

2016/1/18 Regional SCRUM GATHERING® Tokyo 2016 に参加しました（一日目）

1/18,19の二日間にわたって開催された Regional SCRUM GATHERING® Tokyo 2016に参加してきました。

まずは、天気予報通りといえばその通りなのですが、おかげで新宿にたどり着いた時には午前中のセッションが終わっている（＝基調講演聞き逃した！！！）という波乱の一日目の感想です。

togetterはこちら

NexusとLeSSの概要説明、比較

最近話題の大規模Scrumフレームワークの中から
Scrumの父Ken Schwaber氏の「Nexus」と認定スクラムマスター研修の講師でお馴染みのBas Vodde氏の「LeSS」の概要とその差分についての解説のセッションでした。

資料はそのうち上がると思うので、内容はそっちを見ていただくとして、資料が公開されました
聞いてみた個人的な感想としてはNexusは依存関係の最小化にこだわったり、イベントに関しても代表者でやるイベントとチームでやるイベントをかっちり分けている印象があり、シンプルさにこだわっている感じを受けました。
一方LeSSは、通常のScrumの延長線上でありながら、大規模ゆえのチーム感の調整・協調作業ができるように最大公約数的なゆるいルールを提案している感じを受けました。

個人的な好みとしては、製薬が少なそうなLeSSの方が適用しやすい印象を受けました。

生き延びよう！強い組織になろう！ - 迷わず行けよ 行けばわかるさ

Scrumを導入して一旦うまく行ったものの、
そのままの勢いで周囲を巻き込もうとしたら煙たがられてしまった話とその後それをどうカイゼンしたかというお話。

おそらくスライドはそのうち公開されるんではないかと思います。

Scrumとかうまく行きだすと、なんかいい気になって「善意の押し売り」＋「正論で殴る」のコンボみたいな状況になって孤立してしまい、うまく行かなくなるような雰囲気を感じました。
その結果、メンバーが萎縮してしまって本当の問題が表面に現れなくなってしまっていたのかなと感じました。

ただ、体調を崩したタイミングで自分自身でふりかえりを行ったことを天気に、イケイケで勧める感じから、みんなの話を聞くスタンスに変わったことにより状況が良くなったと
やはり対話することが大切だなと、あと仲間がいると心強いなぁと感じました。

僕らのおれおれメトリクス / We metrics in our own way!

スライドはこちら僕らのおれおれメトリクス / We Metrics Our Own Way!

とあるチームに対して、どのようなメトリクスを取得し、
それをどのようにつかってチームに考えてカイゼンしてもらったかというお話。

メトリクスにはお金に関わるKPIに関するメトリクスと、チームの健康状態を測るHealthcheckのメトリクスがあり。
何かとおろそかにされがちなHealthcheckのメトリクスも大事だよということを再認識しました。

よいメトリクス＝NARRATE

NARRATEの中でも、何かと値で絶対的な評価をしがちですが、絶対値ではなく値の「傾向を見る」というところと、
「チームが見たいと思うメトリクス」という点がメトリクスを取る上での心がけとして重要に思えました。

スクラムとメトリクスとテストを活用するチームの事例

スライドはこちらScrum,Test,Metrics #sgt2016

1
2
3
4
私は最高のチームの一員であるだろうか？
最高のスクラムをできているのか？
最高の開発をできているのか？
つまり、最高のスクラム、最高の開発とは何で あるのか？を常に問い続けるチームになる必要 がある。

この一節にしびれました。
具体的なメトリクスの例は、結構過激なのもあるので、このまま全てチームに適用できないかもしれませんが、
常にすべての前提を（もっとカイゼンできないか）疑う姿勢は脱帽でした。

Technology-Driven Development

昔のスライドはこちらTechnology-Driven Development: Using Automation and Development Techniques to Grow an Agile Culture
きっと最新版も公開されるはず。

テストやデプロイ、要求の確認にツールを導入したら目に見えて効率が上がったというおはなし。
Agile2014で海外登壇＆発表されたセッションの日本語番ということで、技術要素などは若干古いらしいですが、
改善点を見つけるための計測とそれを改善し続ける取り組み、そして実際成果が出ているところは非常にすごいです。

社内でアジャイルアジャイル言ってる人が多いが、プロセスばっかりで、テクニカルな要素が全くおろそかだったことに対するアンチテーゼとしてのTechnicalDrivenという表現をしているという反骨精神的なものもアツくさすがアジャイル会のプロレス伝道師というところでした、

以下、殴り書きメモ

NexusとLeSSの概要説明、比較

Nexus

Nexus のイベント

  • プランニング

    • Scrumとほとんど同じ
    • 最初に代表者 -> 次にチーム
    • チームごとにスプリントプランニングするが、場所は一緒のところで、不明点はその都度他チームに確認する

  • デイリースクラム

    • 全体 -> チームごと

  • スプリントレビュー

    • 全チーム合同でやる
    • 全部できないかもしれない -> うまくやってね（としか書いていない）

  • レトロスペクティブ

    • 依存関係をとくていして最小化するということが繰り返し語られている

  • リファインメント

    • 1チームに割り振れる単位まで分割する

    • 依存関係を洗い出す

成果物

  • PBL

    • 全体で一つ
    • レディ
      -> 依存関係が排除されているか最小化されている -> チーム単位でPBIを完成させられないと行けない

  • Nexus PBL

    • 次のスプリントで行う分のバックログ

    統合

  • 作成物の透明性

    • 技術的負債

  • 完成の定義

    • Nexus完成の定義

    QA

    • PBL おすすめツールは
      → 数チームならアナログ

    → 全体はJira チームごとではアナログでやってます

Less

  • Less 2-8 チーム向け それ以上は Less Huge

  • LeSS Huge

  • LeSS Rules 2016/1 が最新

構造

  • 大規模なんでマネージャーいるよね

    • Undone Work
      → わざわざUndoneとかいらなくない？
      → 実際こうなってしまうので、（しかたなく？）定義している

特徴

基本的には1チームのScrumと同じ

協調と統合

  • マルチチームのミーティングなどを定義している

LeSS での役割

PO

  • 優先順位付けはかならず一人で演る
  • 明確化はユーザー・顧客・チームでやる

SM

  • プロダクト全体を意識するように働きかける→ チームないで凝り固まらないように
  • 3チームまでは兼務OK

チーム

  • フィーチャーチーム

イベント

  • 全体的なイベントが追加された

初期のプロダクトバックログリファインメント

  • 完成の定義
  • ビジョン

スプリント

スプリントプランニング

  • Nexusと同じ
    1部
    全体
2部

各チーム

マルチチームスプリントプランニング
→ 複数チームが分担を話し合いながらプランニングする

デイリースクラム

  • Scrum of Scrum
    → 週に3回程度

プロダクトバックログリファインメント

全体的な
  • クロスチームで見積もる
マルチチーム
  • 関連するチームが集まってやる（全員or関係者）
チーム
  • チームで完結することは

スプリントレビュー

  • スプリントレビューバザール
    • 複数のエリアがある大きな部屋で実施

レトロスペクティブ

  • すべてのチームを妨げているのは、全体の問題リスト？に上げる

全体のレトロスペクティブ

*

作成物

PBL

Scrumと同じ

インクリメント

Scrumと同じ
ただし、統合されていること

DoD

  • チームごとに拡張することはOK

未完了作業

  • リスク・遅延を引き起こす可能性のあるものに対してチームで議論する

まとめ

ガイドとルールのセットになっている

代表者の参加するイベント → チームのイベントの2段構え

協調と統合

Nexus と LeSS の比較

Nexus

役割、作成物 イベントルールは普遍
シンプル10ページ

LeSS

オフショアとかのコツが書いてある
全部やれとは言ってない

デイリースクラム

Nexus

依存関係の最小化！にこだわってる
ソフトウェア以外にも適用しにくい

LeSS

フィーチャーチーム
マネージャーに言及している

生き延びよう！強い組織になろう！ - 迷わず行けよ 行けばわかるさ

前回までのあらすじ

  • 上司と世界観と共有
    → 話を聞いてくれる、一緒にセミナーに出てくれる

鬼っ子

→ アジャイルがうまく行っているアピールが強すぎた
→ WF XS Agile の発生!！

結果

  • チームが見ざる言わざる聞かざる
  • 形だけのスクラム
    →ざんねんスクラム化

病気になった！

→ 一人レトロスペクティブす@病室

対立構造を作っていた要因

チームが困っているポイントが変わっていた

どうやるか→どうしたらうまくいくか

→ コミュニティから力を借りた(2名)

再始動

  • そっとチームに関与

一人でなんとかしようとしていた愚かさ

→ 先人はみんなで、チームでやれって言ってる

人生は短い

ジェフ・サザーランド

無駄なことでなく、有意義なことに人生を使おう

僕らのおれおれメトリクス / We metrics in our own way!

http://www.slideshare.net/yattom/we-metrics-our-own-way

見積もりに自信がないチーム
→バーンダウンしない

Tシャツ見積もりを使っていた
→うまくいかない

  • 変えた
    Spring1-3 Tシャツ 1wスプリント
    Sprint5- ポイント 2wスプリント

  • うまく行った
    見積もり通りに行った

  • なんでうまく行ったの？

    分析

    バックログアイテムを分析

    同じポイントでも5倍くらいの時間見積もりの差があった
    →見積もりが上手にできるようになったわけではない
    →3,5 と 8,13 で時間に差がない → うまくなってない
    →問題か？
    →別に問題ではない
    →カイゼンはできているのでOK

オーバーワークしてない？

スプリントの予実を見る（見積もり時間と実績時間）

スプリントの進捗

  • 発生したタスクと、終わったタスクをプロットしたグラフ
  • バグ、テストの分量も追加でプロット

Sprint8

  • ビジネス的な要望でやってほしいことがあった！
  • オーバーコミットでも完成出来た

傾向を見た

Sprint7まで 見積もり＞実績
Sprint8 見積もり<実績

Sprint11,13 SprintDondeできなかった
→ 見積もり＜実績

ダメな時の傾向

  • 最後にまとめてテストをして、バグがばっと出た！！！ Sprint8,Sprint11
  • 追加のタスクが多い！ Sprint13

メトリクスの使い方

→ ヘルスチェック

  • こんなの出てます、このパターンやばくない？ とSMが言う
    → チームが考えてアクションをする

メトリクス

KPI

  • お金に関わるのでみんなが奇にする

    HealthCheck

  • お金にかかわらないので、みんな疎かにしがち
  • 傾向を見なければいけない

Scrum Master

→ OK！ じゃあやってみよう！

Agile Metrics in action

良いメトリクス

  • 自然に計測できる
    →メトリクスのためにプロセスをかえない
  • 自動化
    →手間は減らそう
  • 意味がある
  • 安定している
    →傾向を見ないといけないので
  • チームに沿っている
    →チームに合わせたメトリクス、チームが必要としている
  • タイミング
    → チームが使いたいタイミングで見れるようにする
  • 見たい！
    →チームが見たいと思うものを

NARRATE! 物語！

スクラムとメトリクスとテストを活用するチームの事例

保守で4年目のプロジェクト

→ 2014まではうまくやれてなかった
→残業多い、再計画が不正確すぎる

カイゼン
1w Sprint
Scrum event is on time as possible
multi functional
‥

→ すべての活動を見えるようにする

大切にしているポリシー

→最高の開発、最高のスクラムとはなんであるかを常に問い続ける
→そのためすべての活動を疑う
→スクラムイベントも疑う
→なぜ必要なのか！

メトリクス
→予実はチームメンバーが自主的に15分単位で入れている
→レビューの品質も定量化されている

テスト

→アジャイルでテストをやるのだから、テストが別チームとか、バックログにテストとかあったらリリースできないよね？

  • Specification By Example
  • 探索的テスト

  • レビュー
    → などの高効率テストを行う

  • 誰のようきゅうを表現したテストであるかと徹底する
    → なんとなくは許さない

スプリントレビュー

  • レビューを行う人は持ち回り
    →チームのことなんだからわかるよね？

→ 全くわからない という人をなくす
→ わかってないと見積もれない！→コミットできない
→ サポートがあればできるの前に説明できるという状態があるだろう → せめてそこまでは持っていく スプリントレビューの場でそこまで持っていく

メトリクス

  • メトリクス取っていなかった→自信過剰だった

  • 不満からメトリクスを取るようになった
    → できるチーム
    → 頼まれごと多い
    → 自分の仕事できない！！！！
    → 割り込み作業をメトリクス化
    → 40%
    → 割り込み作業のおねがいテンプレ化
    → 10%になった
    → メトリクス重要！！！となった。

レビュー

  • レビュアー

    • 指摘内容を狩野モデルで素敵品質指摘が多い人はダメレビュアーとか

  • レビュイー

    • 情報共有が多すぎる人は理解が浅いとか

計画内作業と計画外作業

アドリブ

→いいアドリブと悪いアドリブ

無関心品質が0であること

新しいTryをした時に注意力を

→音楽を聞くというTryに対してどうだったか
→音楽に載ってると視野が狭くなる
→得意な作業は早くなる
→不得意な作業、注意が必要な作業はいけてない

わかったこと

  • 自分が納得したものを取り入れる
  • 活動に対してできるだけ早くフィードバックを上げるとどんどん良くなる、よくなりたいという気持ちになる。

スプリントレトロスペクティブをレトロスペクティブしていますか？

→なかなか解決できない問題がどういうふうに変化しているかを計測する

Technology-Driven Development

TDDからインスパイアされて作った言葉

TecDDの3つの目的

  • 業務効率化
  • 教育
  • コラボレーション

TecDDの経緯

  • アジャイルをやりたいけど助けてくれない？
  • Androidのプロダクトのチーム

問題点

  • アジャイルやりたいって言うけど経験者がいない
  • 業務の殆どが手作業で
  • チームメンバーが若くて業務経験が浅かった

大変だなぁだが、たぎるぜ！
→何やっても効果がある！！

具体的な話

CI/CD

  • 手作業でパフォーマンスが低い
  • 要求が曖昧で、チームが混乱している

→地ならしをしたい！！！

CI/CD以前

  • 変更要求に対する回帰テストに週 13.5時間 かかっていた
    → 週の1/3以上がこれに！！

自分のマシンでCI/CD

  • 一時間ごとにビルド
  • 毎日端末にデプロイ
    →実機でデモ＆進捗確認
    →進捗がわかる＆フィードバックが早くなる！
    → 13.5h -> 15min へ
    → 自動化にかかった時間 = 2w

TDD

なぜ？
→アンドロイドわからないから、勉強したかった
→みんなAndoroid知らない
→テストを使ってわからないところを明らかにしたかった

before TDD

  • 1 アクティビティ追加に時間がかかる

  • Android JUnit
    → テストしづらい、テストが遅い
    → mockito, roborectricを導入

After mockito, roborectric

→コンポーネント単位でテストできる様になった
→ 5日→1日になった

BDD

  • Feature creep 要求の爆発！！
  • ユースケースレベルのバグとデグレは検知できない
  • ドメインの知識が必要になった

Feature creep

  • 企画側からのやれやれ圧力に対抗する必要が出てきた

デザイナーが話す
→開発チームがBDDのSpec形式で確認
→開発＆確認
→コラボレーションが可能に

After BDD

  • Bugs -67%
  • 変更要求 -70%
  • デグレ -60%

新しく出てきた問題（内密に）

  • スコープの変更ができないという問題
    →このスコープではどうやってもできない
    →アナリストに直訴
    →アナリスト：NO 全部やって

なんでか？

  • 社風として、一回企画を通したものは死んでもやりなさい！
    → なんとかならないかと一ヶ月調整
    → 失敗
    → 偉い人に直談判
    → OK

  • TecDDとか言ってきましたが、必ずしもそれだけが解決方法ではない。

    • なんでもいいから問題が解決できればいい

Feature

  • Adroidエミュレータ遅いよね？Genimotionいいらしいよ
    →メンバーからの提案は積極的に取り入れるようにした。

  • TecDDは開発者のものではなくて、アナリストやエグゼクティブを巻き込むように活動をした。
    →プロダクトの全体像を見ながらすすめる必要がある
    →スクラムであるならばプロダクトオーナーがそれを示す必要がある。

結論

  • passionate member
  • 現場主義

Agile2016

  • アトランタでやります
  • ぜひ参加してみたらいかがでしょうか？

#＃ 質問

Technology とあえていったのは？

→ 当時Scrum偏重で、技術を疎かにしがちだったので、そこへのアンチテーゼ

ツール入れればOK?

→ No. ツールを使って、失敗して、そこから学んで進んでもらう

「マグロ船で学んだ「ダメ」な自分の活かし方」を読みました

読んだ本

感想

会社人生で必要な知恵はすべてマグロ船で学んだ の著者であり、
また、ホンマでっかTVでマグロ船評論家として出演されている 齊藤 正明 さんの著書です。

内容としては、「自分が欠点だと思っていることは実は強みでもありますよ」
というメッセージが著者の独特のふんわりした文体綴られた、ある意味非常にポジティブな本です。

今の自分が著者がいうところの「がんばりすぎ」な状態になって、
空回って周りに迷惑や不快感を与えていないか確認するためのチェックリストとしても使えるなぁと感じました。

  • 苦手な仕事には、努力を惜しむべし
  • 一人で頑張らず、周りの人を巻き込む
  • 相手にトクをさせてあげれば、人脈は自然とできてくる
  • 「ナメられる性格」を磨き、人の教えを引き出すべし
  • 「失敗体験」こそ説得材料。記録を怠るべからず
  • 周りを「主役」にしてあげれば、自分の存在価値は高まる
  • 不幸か幸福か。その決定権は完全に自分が握っている

など、どこか力が抜けているものの、じんわり染みてくるような言葉が散りばめられています。

7つの習慣のように、この本を読んだ直後に「よし！やるぞ！」的なモチベーションは起きないかもしれませんが、
定期的にサラッと読み返して、その時点で自分が変にがんばり過ぎていないかをふりかえるネタにする本としてはいいんじゃなかろうかと思いました。

「100円のコーラを1000円で売る方法 コミック版」を読みました

読んだ本

感想

100円のコーラを1000円で売る方法 コミック版 を読みました。

まんがでわかる 7つの習慣に続くまんがで読むベストセラーです。

前回と同じく、活字で読むとそれなりにボリュームがある本のエッセンスを1時間程度でサラッと読めてしまうのが良いです。

マーケティングと言うと我々ソフトウェアエンジニアには縁遠い用に感じますが、
本を読み進めると、プロダクトオーナーなどが考えるべき商品企画の基礎となるような考え方や
ブルーオーシャン戦略、キャズム理論など有名な概念がわかりやすく解説されておりマーケティング素人の私でもわかった気になれました。

中でも印象に残ったのは「顧客満足の式」とよばれる式で 顧客満足は 「 顧客が感じた価値 - 事前期待値 」で表され、
顧客の期待に応えるだけでは結果は0点であり、顧客の期待以上の価値が提供できなければ商品としてプラスの評価にはならないという考え方でした。

実際、詳細にマーケティングを学ぶにはより多くの書籍などに当たる必要があると思いますが、
開発者がプロダクトオーナーなど、企画している方々の考えを知るには非常にいい一冊だと思います。

「まんがでわかる 7つの習慣」を読みました

読んだ本

感想

まんがでわかる 7つの習慣を読みました。

私は、本家の7つの習慣を読んだことがないのですが。

  • 1時間程度でサラッと読める
  • （おそらく）重要なエッセンスだけを抽出してある
    ので、少ない時間で7つの習慣を俯瞰でき、美味しいところだけつまみ食いできて良かったです。

特に、第2の習慣の「終わりを思い描くことから始める」にあった、ミッションステートメントを持つことについては、
40歳、不惑を前にして、自分のこれからを再度考えようと考えていたタイミングにマッチしたのもあり印象に残りました。

なんとなく目標を考えてはいたものの、父、夫、上司、部下など、
自分の役割ごとにミッションステートメントを持つという考え方はより（長期的な）目標を具体的に考える指標になると感じました。

また、第7の習慣の「刃を研ぐ」も同じく自分の（特に短期的な）これからを考える良い参考になりました。

まんがでサラッと読めて、絵も綺麗で、内容もためになるという意味でおすすめできます。
気になったら読み返すのにも時間がかからないという面でも頑張って活字を読むより良いと感じました。

2015年 ふりかえり

年も開けてしまいましたが、2015年もいろいろあったなぁということで、徒然なるままにふりかえって見たいと思います。
特にTryしようとか思わない、安定の意識の低さなのでただのポエムです。

ちなみに仕事のことは仕事でふりかえるので、主に仕事以外のことについてです。

Good

  • コミュニティ関連でさらに人脈が広がった１年でした
    • XP祭りのスタッフ関連や、横浜道場関連、後述の登壇などでたくさんの方と交流＆知り合うことが出来ました。
    • やはり、コミュニティは参加するだけで楽しい＆ためになりますが、運営する側になったほうがさらに得るものは大きいと感じました。
  • コミュニティ以外でも人脈が広がりました
    • 職場のチームメンバー経由で各界の著名人を紹介してもらったりして、思っても見なかった人脈が広がりました。
  • 書籍のレビューをさせて頂きました
    • 貢献が出来たかはなんともいえませんが、書籍が出来ていく仮定を垣間見れ、個人的には貴重な体験が出来ました。機会がいただければまたやりたいです。
    • 世に出ていないものを一歩先に読めるというプレミアム感もなんかいい感じでした。
  • 電子工作に目覚めました
    • Lチカ職人になりました。
    • ハンダ付けがLv1くらいになりました。
    • 一発ネタでズゴック作ったら思いの外ウケて良かったです。
    • でも、その続きのズゴック＋Mackerelは今ひとつだったかなぁ。。。
  • 横浜道場が一旦終了しました
    • 区切りのいいところで一旦けじめをつけられたのは良かったと思います。
  • 登壇させていただきました
    • AgileSamuraiBaseCampでTDD関連のお話をさせていただきました。
    • もともと人前に出ることが得意ではないので、ちゃんと話せたかはわかりませんが、人前で話すことへの抵抗が減った気がします。
    • チャンスを与えてくれた@setoazusaさんありがとうございました。
  • ラーメン二郎デビューしました
    • 職場の先輩ジロリアン諸氏に手ほどきを受け、無事ラーメン二郎デビューができました。
    • その結果、二郎の画像を上げると通常みることのできない数のいいねを貰えるということがわかりました。
    • facebookでいいね！がほしい時は二郎画像！
  • はじめて登山をしました
    • なんでそうなったか経緯は覚えてないですが、職場の登山経験者のプランニング＆エスコートで大山（おおやま）に登ってきました。
    • ヤビツ峠には自転車で何回か登ったことはありましたが、徒歩で登るのは一味違って楽しかったです。
    • なんといっても、帰りがけに呑んで帰れるというのはロードバイクに比べて大きなアドバンテージですね。
  • ダムカードを集めはじめました
    • 自転車の目的地にダムっていうのは意外といいので、どうせならとカードをもらうことにしました。

Sad

  • 英語力が・・・
    • 書籍のレビューアーになるも、英語力が無いので訳の正当性チェックで貢献出来ませんでした。
  • 電気のことが全然理解できていない
    • 電子工作にというか電気系に真剣に向き合って来なかったので前提知識が全くたりませんでした。
    • パーツのスペックシートとか見ても理解できませんでした。なので先人の知恵をGoogle先生経由で拝借しっぱなしでした。
  • 横浜道場
    • いままで長い付き合いで、いろいろなものをもたらしてくれたコミュニティが終わってしまうのはやはり残念な面もあります。

あらてめてふりかえってみても、周りの方々と環境に恵まれ、いろいろなものを吸収させていただいた一年でした。
2016年は形式はどうあれ、周りからもらったものをもう少しアウトプットする力を付けたいなぁとか思ったりしてます。

あと、自転車乗る回数を増やして体重を減らしたい。

ということで2016年もよろしくお願いします。

Atlassian Stashの耐障害性を高めよう その4 分散ストレージ設定編

今回もStashの高可用性を目指してクラスタを組んでいきたいと思います。
前回までで、サーバーと、Stashのプロセスの冗長化は一旦完了したので、今回は一番重要なデータ保存領域の冗長化を目指します。

お知らせ

今までAtlassian Stash を冗長化しようと頑張ってきましたが、つい先日なんとAtlassian Stashがなくなってしまいました。
今度からは生まれ変わった？ Bitbucket Server をよろしくお願いします。

・・・閑話休題・・・

それでは、Stash改めBitbucket Serverのストレージを冗長化したいと思います。

Atlassianの公式によるとストレージは GFS2 + DRBD でストレージの冗長化を行っていますが、
今回は個人的な興味で、GlusterFSを使って冗長構成をしてみたいと思います。

事前準備

VagrantにDISKを追加

Virtualbox コンソール経由で、node01,node02 にDISKを追加します。
Stashのデータに使用するので、保存するデータの容量によって大きさをかんがえる必要があります。
今回は仮に8GBとして データ用にパーティション /dev/sdb1 を作成しました。

GlusterFSのインストール（全ノード）

パッケージのインストール

1
2
3
cd /etc/yum.repos.d/
curl -o glusterfs.repo http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
yum install glusterfs-server

通信ポートの開放

まずは、通信に必要なポートを開放します。
今回は実験用途なのでどこからでも通信可能に設定してしまいます。

/usr/lib/firewalld/services/glusterfs.xml を以下の内容で作成します。

1
2
3
4
5
6
7
8
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>GlusterFS</short>
  <description>GlusterFS</description>
  <port protocol="tcp" port="1111"/>
  <port protocol="tcp" port="24007-24100"/>
	<port protocol="tcp" port="49152"/>
</service>

作成したファイルをもとにファイワォールの設定を変更します。

1
2
firewall-cmd --permanent --add-service=glusterfs
firewall-cmd --reload

GlusterFS Volumeの作成

次にGlusterFSで使用するディスクの準備をします。

ファイルシステムの作成

GlusterFSは共有するボリュームのファイルシステムをXFSにする必要があります。
まずはデータ用のボリュームをXFSで用意します。

1
mkfs.xfs /dev/sdb1

/etc/fstab の末尾にエントリを追加します。

1
/dev/sdb1       /data					  xfs     defaults        0 0

マウントします。

1
mount -a

GlusterFSの起動

1
2
systemctl start glusterd
systemctl enable glusterd

GlusterFSのノード登録

  • node01

    1
    gluster peer probe node02

  • node02

    1
    gluster peer probe node01

GlusterFSのVolume作成(任意の1ノードで実行)

1
mkdir -p /data/atlassian/stash
1
2
gluster volume create stash_vol replica 2 node01:/data/atlassian/stash node02:/data/atlassian/stash
gluster volume start stash_vol

GlusterFSのマウント

マウントポイントの作成

まずマウントポイントを作成します。
既存のStashのデータディレクトリはあとでGlusterFS上にコピーするためリネームして退避しておきます。

1
2
3
mv /var/atlassian/application-data/stash /var/atlassian/application-data/stash.org
mkdir -p  /var/atlassian/application-data/stash
chown atlstash:atlstash /var/atlassian/application-data/stash

fstabの修正

次に各ノードで /etc/fstab にエントリを追加します。

  • node01

    1
    node01:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

  • node02

    1
    node02:stash_vol        /var/atlassian/application-data/stash   glusterfs       defaults        0 0

ファイルシステムのマウント

次に、両方のノードでglusterfsをマウントします。

1
mount -a

既存データのコピー

次に、今までのデータをどちらか一方のノードでコピーします

1
cp -rp /var/atlassian/application-data/stash.org/* /var/atlassian/application-data/stash/.

これで課題だったDISKの冗長化も出来、Stash改めBitbucketServerのクラスタリングが完了しました。
実際の運用では、定期的なデータのバックアップは行う事はあっても、クラスタリングをすることはまれかもしれませんが、
クラスタリングを検討されている方の参考になれば幸いです。

※ このシリーズの記事はあくまで検証用途でクラスタの設定を行っているため、実際の環境では使用に耐えない可能性があります。
実際にHAを構成を行う場合には十分な検証を行うことをおすすめします。

Thinking about INVEST

INVEST

Have you ever heard the acronym “INVEST”?

The INVEST mnemonic was created by Bill Wake and it is introduced in The Agile Samurai(@jrasmusson 2010) .

“INVEST” is as a reminder of the characteristics of a good quality user story,

  • Independent
    • The user story should be self-contained, in a way that there is no inherent dependency on another user story.
  • Negotiable
    • User stories, up until they are part of an iteration, can always be changed and rewritten.
  • Valuable
    • A u ser story must deliver value to the end user.
  • Estimable
    • You must always be able to estimate the size of a user story.
  • Small
    • User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
  • Testable
    • The user story or its related description must provide the necessary information to make test development possible.

quated from wikipedia)

“Valuable” is easy understand Of these six words, So everyone will care
But Testable,Small and Estimable are often forgotten.

If you noticed follow problems, It may be able to solve it by being conscious of INVEST.

  • Story goal is difficult to understand, Because acceptance criteria is not clear.
  • Story is hard to estimate, Because the size is huge.

INVEST User Story

Then I think about an example about the user story that is INVEST.

1
2
As a Administrator,
I want search user by name so that I don't use time for find user in list.
  • Independent
    • OK. This story is inipendent feature.
  • Negotiable
    • OK. This story is not specified implementation.
  • Valuable
    • OK. To improve Administrator’s work efficiency
  • Estimable
    • OK. It story may be modified 1 view (and 1 logic)
  • Small
    • OK. It is simple and small.
  • Testable
    • OK. Story is simple, (please confirm the acceptance criteria properly in PO.)

It is INVEST and good user story.

1
2
3
As a ramen JIRO lovers (sometimes called Jirolian),
I want to know which JIRO is open now
so I wants to go to Jiro as soon as I thought.

And this user story is INVEST too.

Conclusion

INVEST is good practice for writing user story.

How about if you try a Story-Gathering workshop while being conscious of INVEST?

Appendix

INVEST something

With that said, I understood that INVEST was important in thinking about user story.
In, what’s the INVEST in something other than user stories can be applied?

I’m tried.

JIRO

Ramen Jiro is of course technically ramen, but it is somewhat different from any other ramen in Japan.

quated from http://www.ramentokyo.com/2007/06/ramen-jiro.html

Ramen Jiro is introduced in Guardian 2009 The 50 best things to eat in the world, and where to eat them

and Elon Mask was visited.

Is Jiro INVEST?

  • Independent
    • Jiro has some unique distinction. amazing large serving, own rule, etc…
    • someone says “Jiro is not ramen, but Jiro is the Independent food”
  • Negotiable
    • Jiro is negotiable some toppings vegitables (yasai), Backfat (abura), garlic(nin-niku) and depth of taste (karame).
    • If you want to more and more vegitables,backfat and garlic, you shoud say “yasai, abura, nin-niku mashi-mashi”.
  • Valuable
    • Jiro is Cost-effective.
    • Jiro is unique.
  • Estimable
    • While you attend a few times, it will be so as estimated to be either the amount of how much today is eaten.
    • If, when you can not eat too much, it would be nice if I tell half noodles when presenting the meal ticket.
  • Small
    • Jiro’s menu have “small size” (but Jiro’s small size equals ordinaly ramens large size or extra large size.)
  • Testable
    • Jiro might store a total of 40. we can achieve 100% coverage. It’s testable.

Jiro isn’t completely INVEST. but Jiro is extremely unique.

Conclusion

Meanwhile, it is very distinctive ramen Jiro, as there is also saying, “Seeing is believing”, First, What is How about try to experience.

Enjoy “mashi-mashi”.

(日本語版)

INVEST

INVEST という頭文字語をご存知ですか？

“INVEST” とは ビルウェイクにより考案され、アジャイルサムライでも紹介された、よくかけているユーザーストーリーに備わっている6つの要素を表します。

  • Indipendent
    • 独立している
  • Negotiable
    • 交渉の余地がある
  • Valuable
    • 価値のある
  • Estimable
    • 見積もれる
  • Small
    • 小さい
  • Testable
    • テストできる

この中でもValuableはわかりやすいので、誰もが気にするのですが、
意外と見逃し気味なのが、Testable,Small,Estimableです。

  • 受け入れ条件が曖昧でストーリーのゴールがわかりにくい
  • ストーリーが壮大過ぎて見積もろうとしても想像が出来ない

などの状況に気づいたら、INVESTを意識すると解決できるかも知れません。

INVEST User Story

では、INVESTなユーザーストーリーについて例を考えてみます。

1
管理者はユーザーを検索したい。なぜならリストから目Grepするのがキツイからだ。
  • Indipendent
    • OK. 独立したフィーチャーです。
  • Negotiable
    • OK. 実現方法などはまだ交渉（カイゼン）の余地があります。
  • Valuable
    • OK. 管理者の作業効率が上がります。
  • Estimable
    • OK. 開発者が想像できるくらいのサイズです。（おそらく1画面＋1ロジックでしょう）
  • Small
    • OK. 十分に小さいです。
  • Testable
    • OK. ユーザーストーリーがシンプルなので、テストも書きやすそうです。（ただし、POと受け入れ条件は合意して億必要があります。）

このユーザーストーリーはINVESTを満たしていて、良いストーリーと言えるでしょう。

別の例

1
ジロリアンはどの店舗が今営業中なのか知りたい。なぜなら、思い立ったそのタイミングでラーメン二郎へ行きたいからだ。

また、このストーリーもINVESTを満たしていて良いストーリーといえるのでは無いでしょうか。

Conclusion

このようにINVESTを意識することで、ユーザーストーリーがより良くなります。

ユーザーストーリーワークショップなどを行う際には
INVESTを意識しながらストーリーを抽出してみたらいかがでしょうか。

Appendix

INVEST something

ということで、ユーザーストーリーを考える上でINVESTが重要な事はわかりました。
では、今回は少々趣向を変えて、ユーザーストーリーではなく、身近なものにINVESTが適用できるか考えてみました。

jiro

ラーメン二郎とは、

Guardian 2009 The 50 best things to eat in the world, and where to eat them

で紹介され、

http://mogumogunews.com/2015/04/topic_10702/

あの、イーロン・マスクも訪れたラーメン店です。

http://japan.cnet.com/news/offtopic/35053480/

Is JIRO INVEST?

  • I
    • 二郎はラーメンではなく、二郎という食べ物だと言われることもあるほど独自性が高く、一種独特の文化があると言えるでしょう。
  • N
    • 二郎非常に柔軟な調整が可能です。代表的なものは 麺、野菜、背脂、にんにくの量や、味の濃さです。たとえば、野菜と背脂とにんにくをとても多くしたい場合は「野菜、アブラ、ニンニク マシマシ」と店主に伝えることにより、おそらくあなたの希望の結果が得られるでしょう。
  • V
    • 二郎には圧倒的なオリジナリティがあります。これにまさる価値は無いでしょう。
  • E
    • 何回か二郎に通うと、自分のコンディションに応じて何を増やして何を減らすかが見積もれる様になります。体調が悪くあまり食べられない場合は、食券を提示する際に、麺半分などと伝えればいいでしょう
  • S
    • 二郎にもスモールサイズはありますが、これには注意が必要です。二郎のスモールサイズは、一般的な店舗の大盛りか、それ以上に値します。慣れるまではスモールサイズもしくは（もしあれば）ソレより小さいプチサイズにするのが良いでしょう。
  • T
    • 二郎は総店舗数が40店舗弱（内休業中が2店舗？）であるため、カバレッジ100％を達成することも可能であるため、テスタブルと言えるでしょう。また、非常に量が多いため、自分に対する判断力を試されるため、自分自身に対するテストと考えることも出来ます。

そんな、非常に特徴的なラーメン二郎ですが、百聞は一見にしかずということわざもあるように、まずは体験してみるのはいかがでしょうか。

Atlassian Stashの耐障害性を高めよう その3 HAリソースセットアップ編

今回も引き続きStashの高可用性(HA)クラスタを組むべく進めていきたいと思います。

前回 ATLASSIAN STASHの耐障害性を高めよう その２ HAセットアップ編はHAクラスタをくんだものの、
IPアドレスの設定のみで終わってしまい、全くStashの可用性が高まらないまま終わってしまいました。

このままでは表題に偽りありと言われても反論出来ないので、今回こそは、Stashの可用性を高めていきたいと思います。

前回は、ノードが切り替わる際にIPアドレスが自動的にアクティブノードに付与されるように設定を行いました。
ただ、アクティブノードにIPアドレスが付与されるだけでは、Stashにアクセス出来ません。

というわけで今回は、ノードの切り替わり時に自動的にStashが起動する様にします。

前提条件

  • 前回までの設定が終わっている
  • Stashが各ノードにインストール済み＆初期設定済み
  • Stashの自動起動がOFFになっている
  • StashのデータベースはStash以外のサーバーのものを使っている

ここまでの設定が終わっている前提で進めていきます。
Stashはインストーラーを利用しても、tar.gzを利用しても問題ありません。

なお、今回のStashはインストーラーを利用してセットアップしました。

リソース制御スクリプトの追加

今回クラスタの制御に使用しているPacemakerは、一般的なクラスタリソースの制御スクリプトが最初から用意されています。
また、クラスタリソース制御スクリプトが用意されていない場合には、Pacemakerの指定する形式に沿った自作のスクリプトを所定のディレクトリに配置することにより、制御対象のクラスタリソースを追加することが出来ます。

Atlassian Stashも残念ながらPacemakerにスクリプトを用意されるほどにはメジャーになっていないようなので、自作のスクリプトを配置する必要があります。

このスクリプトを一から自作するとなかなか大変なのですが、Atlassian社がサンプルで用意しているリソース制御スクリプトがあるので、今回はそれを拝借します。

CentOS 7.1 + Pacemaker 1.1 の構成では /usr/lib/ocf/resource.d/ 以下に自作スクリプトを配置することによりクラスタリソースが追加されます。

ということで、このファイルを各ノードの /usr/lib/ocf/resource.d/heartbeat に配置します。

1
2
3
cd /usr/lib/ocf/resource.d/heartbeat
curl -o stash https://bitbucket.org/atlassian/stash-ha-example/raw/1397712da2b11ab4894c91446009aacae94fcf3d/vagrant/scripts/heartbeat-stash
chmod 755 /usr/lib/ocf/resource.d/heartbeat/stash

リソースが定義されているかの確認をします。 pcs resource list コマンドの結果に ocf:heartbeat:stash が含まれていればOKです。

1
2
3
4
5
6
7
# pcs resource list
--中略--
ocf:heartbeat:slapd - Manages a Stand-alone LDAP Daemon (slapd) instance
ocf:heartbeat:stash - Manages a Stash instance
ocf:heartbeat:symlink - Manages a symbolic link
ocf:heartbeat:tomcat - Manages a Tomcat servlet environment instance
--以下略--

Stashリソースの定義

リソースを定義する準備が整いましたので、クラスタにリソースを追加します。
下記コマンドを実行して、stashのリソースを定義します。

1
pcs resource create stash_res ocf:heartbeat:stash params stash_user=atlstash stash_home=/var/atlassian/application-data/stash stash_inst=/opt/atlassian/stash/3.11.3 op monitor interval=15s op start timeout=240s

次にstashが単一のノードでしか起動しないように設定します。

1
pcs resource meta stash_res migration-threshold=1

最後に、stashのプロセスと、VIPが同時に同じノードで起動するように設定します。

1
pcs constraint colocation add stash_vip with stash_res INFINITY

リソースを定義した後、クラスタの状態を確認しこのようにstash_vipとstash_resが同じノード上でStartedになっていればOKです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# pcs status
Cluster name: stash
Last updated: Sun Sep 20 10:07:15 2015		Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured
Online: [ node01 node02 ]
Full list of resources:
 stash_vip	(ocf::heartbeat:IPaddr2):	Started node01
 stash_res	(ocf::heartbeat:stash):	Started node01
PCSD Status:
  node01: Online
  node02: Online
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

ノード切り替えの確認

それでは、設定が出来たのでノード障害時に自動的に切り替わるか確認したいと思います。

まず現状を確認します。
諸事情で、node02がアクティブになっています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# pcs status
Cluster name: stash
Last updated: Sun Sep 20 11:03:59 2015		Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node02 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured
Online: [ node01 node02 ]
Full list of resources:
 stash_vip	(ocf::heartbeat:IPaddr2):	Started node02
 stash_res	(ocf::heartbeat:stash):	Started node02
PCSD Status:
  node01: Online
  node02: Online
Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

では、ここでnode02の電源をOFFします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# pcs status
Cluster name: stash
Last updated: Sun Sep 20 11:08:36 2015		Last change: Sun Sep 20 09:32:39 2015 by root via cibadmin on node01
Stack: corosync
Current DC: node01 (version 1.1.13-a14efad) - partition with quorum
2 nodes and 2 resources configured
Online: [ node01 ]
OFFLINE: [ node02 ]
Full list of resources:
 stash_vip	(ocf::heartbeat:IPaddr2):	Started node01
 stash_res	(ocf::heartbeat:stash):	Started node01
PCSD Status:
  node01: Online
  node02: Offline
Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

しばらく後にクラスタの状態を確認したところ無事にnode01に切り替わっていることが確認出来ました。

さいごに

今回で、ようやくStashが切り替わる様になりました。これで可用性が高まって枕を高くして眠れるかと思いましたが、実はまだ設定が足りません。
なんと、Stashはハードディスク上にもデータを保存しているのです。

というわけで次回はディスクを冗長化して、こんどこそ真のStashの耐障害性向上を成し遂げたいと思います。