2015年11月27日金曜日

アジャイルジャパン・プレイベント企画「アジャイル初心者向けセミナー」

この投稿へのリンク

概要

  • 日時:2015年11月27日(金) 13:00~19:30
  • 場所:NECソリューションイノベータ

アジャイルジャパンのイベントが合ったので行ってきた。
その際のメモ。


初心者向け講義

13:00~15:00

  • 発表者:豆蔵 中佐藤麻記子

セミナーの背景

今回は春先にあるアジャイルジャパンのプレイベント
アジャイルジャパンは2016/5/31を予定

宿題

http://www.scrumguides.org/download.html
→Japaneseを選ぶ

アジャイルとは?

  • アジャイルソフトウェア開発宣言
    • 提唱者ごとにアジャイルの手法が様々あるので何が正解かというのが無い
    • XP
    • scrum
    • それぞれで用語も少しずつ違う

今回は情報が少ないXPベースで話をする

エクストリーム・プログラミング

以下のアジャイルプラクティスを最初に取り入れた手法

  • TDD
  • リファクタリング
  • CI
  • 顧客同席
  • ペアプログラミング

4+1の価値を実現するプラクティス
コミュニケーション、フィードバック、シンプリシティ、勇気+リスペクト

アジャイルプラクティスメトロマップ

http://guide.agilealliance.org/subway.html

アジャイルプラクティスの用語集
なんとなくの見方

  • グレーの線が基礎
  • ピンクがXPでよく使われるプラクティス
  • あとは左から右にざーっと見る

これで停車駅を決める⇒今回使うプラクティスみたいなのを決めると分かりやすそう

イテレーション

scrumではスプリントと言う
1週間から3ヶ月(3ヶ月は長すぎると思う)
要件分析から実装・テストまですべての開発を行う
イテレーションの終わりにはリリースできる動くなにかを用意する

会議体

  • 計画会議(スプリントプランニング)
  • レビュー会議(スプリントレビュー)
    • 作ったもののレビュー
  • レトロスペクティブ(ふりかえり)
    • チームのプロセスのレビュー
  • 日次スタンドアップミーティング(デイリースクラム)

ストーリー

ストーリーリスト(プロダクトバックログ)

  • 要件リストのこと
  • カード形式にしておいて優先度順で上から並べる

アジャイルで最低限使われるプラクティスは上記の3つ

アジャイルが継続できない

  • なぜアジャイルなのか?
    • 現状のプロセスに問題があるのでアジャイルを実施することになったはず
  • 価値にたち戻って考える

ウォーターフォール

  • input -> process -> output
  • WFが正しく動くには
    • 入力が正しいこと
    • 途中に落とし穴が無いこと
    • 設定されたゴールが正しいこと
    • 階層化されたプロセスにおいて100%正しくIPOが繋がっていること

アジャイルにたいする誤解

ウォーターフォールできっちりできる事であればアジャイルよりも絶対に効率がよい

アジャイルは少しずつ進んでは会議でチェックする

  • 作るものと作り方を進みながら変えていく
  • 変えてはいけ無いことを決める
  • インセプションデッキ(プロジェクト憲章)

継続的~~

WFと違ってすべて継続的
「アジャイルな計画と見積もり作り」

  • 計画を立て続ける
  • 要件定義をし続ける
  • 設計をし続ける
  • 実装をし続ける
  • テストをし続ける
  • プロセスを変更し続ける

価値にたち戻る

なんのためにやるのか??

  • コミュニケーション、フィードバック、シンプリシティ、勇気のどれかの価値を高めることができるか?
    • プラクティスが実現できない場合も価値にたち戻る

コミュニケーション

ソフトウェア開発で一番重要なのはコミュニケーション

  • 重要なのであればコミュニケーションをとりやすくするためになにをしているのか?
  • コミュニケーションの齟齬を防ぐ方法

フィードバック

  • 進捗
  • CI
  • TDD

シンプリシティ

よりシンプル、コストのかからないものを選ぶ

  • コミュニケーションの取り方
  • フィードバック
  • 設計

勇気

アクションを起こすための勇気/勇気を持てる仕組み

  • 悪い情報が外に出てこなければフィードバックサイクルは回らない
  • 嘘の無いコミュニケーション
  • 現実を受け止める
    • 受け入れてあげないと真実が出てこない

リスペクト

なぜ価値が4+1なのか?

  • 4の価値はプラクティスで実現される
  • 1の価値はプラクティスで実現できない
    • ベースとなること
  • 目指すゴールにたいするリスペクト
    • 完成したら世の中への影響があるんだ!というようなパッション

事例紹介

「事例聞きたい」病
↓ 対処療法で事例を聞かせると・・・
「でもうちの会社では」病

  • 世の中に全く同じチーム、同じ会社なんてものは無い
    • どこかの成功例を持ってきてもうまくいくわけが無い
    • 銀の弾丸は無い

アジャイルジャパン2016 テーマ

“あなたとつくるアジャイル”


今時のスマホゲーム開発事例、アジャイルテスト添え

15:10~15:40

グリー株式会社 Quality Assurance部
西脇春名氏 @haruna_nishi

資料

聞きたい内容

  • アジャイルテストの話が聞きたい
  • デメリットは?

今時のスマホゲーム開発

昔はビックバンテストやってた

  • 初期段階ではスクラムを採用
  • テスト期間が短い
  • 市場トレンドが変わりやすい
  • カジュアルからハードなゲームまで様々なニーズ

アジャイルテストについて

リリースサイクルの中で各サイクルの ストーリー に対するテスト。システムテストや受け入れテストに近いフェーズなので単体テストとかではない。

グリーの場合

  • 本開発が決まった時点で担当がチームにはいる
  • 毎日探索的テストを実施(仕様の理解・実行をその場で行う)
    • 不具合があれば修正
  • リリース前には従来と同様にマニュアルテストを実施する
    • ここで社内標準の品質保証を行う
  • 開発後期になるとメンバーが増えてアジャイルが消滅することもある
    • それでも探索的テストは続ける
  • 品質の底上げに繋がっている

アジャイルテストのメリット

  • 手戻りの最小化
  • 常にアプリを動作させられる環境を作っておくことができる
  • 実機とエミュレータの差分やパフォーマンスが早期でわかる

手戻り最小化

  • いつの変更でエンバグしたかがわかる
  • 品質保証をする最終フェーズでのテスト時まで重大な不具合を見つからないことがなくなる
  • 品質は製品に組み込むものという意識がチームに形成される

常にアプリを動作させられる環境を作っておくことができる

  • 毎日動作できる状態を維持することを意識させることがチームにできる
  • 継続的デプロイ

実機とエミュレータの差分やパフォーマンスが早期でわかる

  • エミュレータでの操作性と実機での操作性の違いがわかる

QA

  • ビジネス的な価値のあるまとまりは?

    • 機能単位
  • デメリット

    • 工数がかかる
    • やる人によってテストのクオリティに差がでる
  • 自動化は?

    • 自動化は特にしていない
    • ゲームは難しい
    • 画面遷移系はできそう
  • 探索的テストは誰がやってるのか?

    • チームごとで違う
    • 仕様を考える人、品質担当、PM的な人
  • どこのタイミングでやってるのか?
    • 朝と夜
  • なにか基準があるのか?
    • 品質担当が決める
    • 品質担当以外は仕様が満たされているかだけをチェック
    • 1時間ぐらい
    • チュートリアルは全部やる
    • チュートリアルには無い機能も大きな機能には実施している

雑感

  • 品質保証は探索的テストだけでは無理そう
  • 従来の品質保証としてのテストフェーズは必要となりそう

KPTが出なかったチームを自己組織化に近づけたふりかえり改善事例

15:50~16:20

yahoo株式会社 パーソナルカンパニー メール本部
川鯉光起氏

聞きたい内容

  • KPTの話を聞きたい

問題発生

  • 毎スプリント計画どうりに終わらない
  • ふりかえりで意見がでない

ふりかえり改善

沈黙

問題
- 発言が出ない
- 改善案が出なくて改善ができないのでふりかえりをやめようとか言い出す
- KPTが出ないとふりかえりができない

対策
- 大切なのは相手の環境や対場を理解すること。
- 批判や提案は後回し

チームを観察して、チームが困っているであろうことを探しだす
- チームに響く内容の問題を提案する方がよい

世の中一般のやり方を積極的にシェアしていく

結果
 ふりかえりの時間に例示をして話すハードルを下げた
 チームにTryを提案するハードルを下げる

費用対効果のよいものからやろう

問題が大量に出るようになってしまい、ふりかえりの時間が非常に長くなった

原因
 問題が大量
 それぞれに改善案を考えるので時間がかかる

対策
 問題と改善案を同時に考えるのを辞める
 みんなで問題の優先順位をつける

結果
 チームが費用対効果の高い問題から解決するようになった

表面的な問題の解決

問題
 毎回同じような問題が起きる

原因
 根本的な解決をしないで表面的な問題のみを解決してる
 同じことを繰り返す

対策
 問題の深堀
  どうして起きたのか?
 問題の整理
  カテゴリ分け
  抽象化

結果
 チームで根本的な原因を見つけられるようになった

自分ではどうにもならない問題

問題
 根本的な原因がチーム外にある
 偉い人がきめたこと

原因
 なにもできないと思ってる

対策
 ボトルネックをスコープの内にする提案
 無理だと思うことの対策を考える提案

結果
 チームが問題解決を考える前向きなマインドになった

まとめ

相手の立場を理解する
うまくいかないコンテキスト探しは大変
事前に仕入れて解決案をストックしておく

QA

  • 注目した観察点

    • チャット内でのネガティブな話
    • 残業
    • スクラムでの理想とされるチームとの差分
  • 毎スプリント計画通りに終わらない

    • 大きな粒度でみつもりをしていたのを細かな粒度でみつもるようにしたら改善した
  • 例示をあげてハードルを下げるの具体例

    • 具体的な見つけた案を恐る恐る言ってみる
    • ○○さんが残業続いてるけども大丈夫なんすかねー?みたいな
  • スクラムマスターがガリガリと改善をしてくモチベーション

    • 社内の憧れている先輩
    • 改善すると社内のすごい先輩が誉めてくれる
  • ふりかえりで工夫したことはなにかあるか?

    • 今回の発表内容を実施した
    • お菓子を食べながら
    • 空気がよくなるようにした
    • ケーキ買って食べながらやった

雑感

  • スクラムマスターを月ごとに交代は面白い試み。自分たちでも取り入れれそう
  • 相手の立場を理解する。チームを観察するってのは大切

アジャイル開発標準化という立場からのアプローチ

16:30~17:00

SBS株式会社
小林信氏

資料公開予定

聞きたい内容

  • 標準化について聞きたい

掴み

よいものを作り上げたい
 それを体現できるのがアジャイル

標準化という仕事

標準化チームがプロセスをつくって開発チームが使う
策定のためにステップを踏んだ

  1. 叩き台としてプロセス策定
  2. 試行錯誤
  3. プロセス改善
  4. 実開発

プロセス策定

  • スクラムとXPをベースにした
  • 実施する会議体、参加者、やり方を定義
  • 企業文化・体制の取り込み
  • 自動テスト環境、使用ツールの提示

施行開発

定義したプロセスで開発実施
スクラムマスターとして参加
失敗した

たどり着いた自分の答え

  • チームメンバが消極的で各イベントでの動きが鈍かった
    • 各々がチームに対して働きかけ、自己組織化する

自己組織化
 コントロールの分散化
 変化する環境へ継続的な対応

 サーバント型のチーム
  リーダー メンバーが自発的に働けるようにサポートする
  メンバー やりたい気持ちで行動する
       言われる前に行動する
       工夫しようとする

アジャイル開発をするにはチームのメンバーを長期的かつ継続的な教育が不可欠
 アジャイル開発者は幅広いスキルが必要

ウォーターフォールでもできる。アジャイルんい繋げる日々のと陸い

野望を持った旗振り役が必要
どうしてそれが必要なのか考える
助けてくれたら「ありがとう」を伝えよう

取り入れたプラクティス
 デイリーミーティング
 ふりかえり
 プランニングポーカー

デイリーミーティング
 アイスブレイク

ふりかえり
 実施タイミング:各工程の1本目が終わったとき

プランニングポーカー
 WFだとリスク高い

アドバイス

「利用者にとって価値のあるシステムを作り上げる」という原理原則を意識する

アジャイルソフトウェア開発の12の原則
リーン7つの原則

メンターを作る

 ホスピタリティ理論
 TOC(制約理論)
 SECIモデル

アペンディックス

QA

標準化は必要なのか?
 大きな枠組みとしての標準化は必要だけども、標準外のことをやることも大切
 標準化はレール。アジャイルは復車線。

ユーザー企業の期待値は何?
 ユーザー企業の期待値はアジャイル開発という言葉が一人歩きしてたので統一見解を作りたかった

チームへの意識付け
 意識付けが手抜きになっていたので失敗した
  言われたからやっている感がぬぐえなかった

タスクの定義を網羅的にする方法
 オブジェクト指向の考え方ができないと網羅的にあげるのは無理
  タスク分割するには基礎的な技術力が必要
 テスト自動化


組込製品開発組織でのアジャイル実践への道のり

17:10~17:40

DADベースのアジャイル開発プロセスの構築と実践
株式会社東芝 インダストリアルICTソリューション社
IoTテクノロジーセンター プロセス・品質技術開発部
石井裕志氏

聞きたい内容

  • 組み込みでの事例が聞きたい

東芝での事例

リリースサイクルの向上が求められる
モノを作ってみないと良し悪しがわからないプロダクトが増えている

導入障壁

組織として守らなければならない文化・制度
 品質保証の体系
 事業戦略
 既存資産の活用

複雑な利害関係
 それぞれの関係者を説得するのが難しい

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

導入事例

プロセス構築
試行プロジェクトへの教育
プロジェクトでの試行
ふりかえり

背景
 組み込み製品のSWとそれを用いたシステム製品
 現在クラウドや携帯端末との連携が求められる

課題
 初期段階で要求を固めるのが難しい
 設計フェーズ以降の着手が遅れがち
 協力会社からアジャイル開発が求められた

目的
 設計、コーディングの着手遅れを減らす
 テストに時間をかける

プロセス構築

既存の品質保証体系とアジャイルのプロセスが合わないことが判明
DAT(Disciplined Agile Delivery)
 アジャイルをスケールアップするためのフレームワーク
 3つのフェーズを定義
 初期計画のフェーズが充実

方向付け
 プロジェクトがアジャイルで実施できるのか判断
  アジャイルでやる目的があるか?
  前提条件を満たすか?
  プロジェクト特性をもとにしたアジャイル開発適合性評価手法
 プロジェクトの計画立案
構築
移行
 従来の品質保証体系

プロセス構築の方法

プロセスの検討WGの開催
 隔週で半年
 参加者:設計、品質保証、支援メンバ(アジャイル)

教育フェーズ

参加者:プロジェクト関係者全員
目的:アジャイル・スクラムベースの仕事の進め方を理解する
体験演習5時間

アンケート結果
 ふりかえりに期待
 課題の早期発見
 スプリントレビューで適宜確認できる
 工数が増えないか心配
 変更要求の押し付け
 追加要求の増加

プロジェクトでの試行

捲土重来
成果物の受け入れ可否判断
マイルストーンレビュー
 プロセスがちゃんと回っているかのレビュー

スプリントレビュー

デモ・単体テストの結果確認
ふりかえり結果の共有
結構時間がかかった
 3~4時間かかった
 仕様確認とかもやってた

バージョンアップチャート

プロダクトバックログを適宜調整

審査会

上長がでてくる
バックログ、バージョンアップチャートを使った

ふりかえり

進捗確認がやりやすかった

プロダクトバックログの粒度が難しい
出張等で連絡がつかないとスケジュールが遅れる

進捗確認に効果があると感じた
要求の管理はしやすいが、初期の粒度に基準がほしい
スプリント期間中の品質可視化ができた

雑感

教育フェーズをきちんと利用できるかが勝負になりそう


ふりかえり

17:45~18:00