Agile Tour Osaka 2011( #agileto2011 ) 参加メモ
「Agile Tour Osaka 2011」へ参加した際の自分向けメモです．
日時 ：2011/10/08 10:45-18:00
場所 ：大阪産業創造館
参加者数：30人位からスタート。最終的に60人位
参考 ：http://kokucheese.com/event/index/16868/
■プログラム
- 10:45-11:45 オープニング
- 11:00-12:00 セッション1
- 13:00-13:30 セッション2
- 13:45-14:45 セッション3
- 15:00-16:00 セッション4
- 16:00-16:25 LT
- 16:25-16:40 クロージング
- セッション2,3とパラレルセッションでワークショップ
■感想
- 東西に限らず，参加者が抱えている課題は似たような気がする．
- アジャイルUPに関してはScott Amblerが発表し，いくつかの本が出たあと動きがを感じられなかったが，藤井さんおよびOGISさんが動きを作り出しそうで注目していきたい．
- アジャイルソフトウェア開発に関する研究文献の集まる場がないことを再確認
- 現在は，他の実践系のソフトウェア論文として投稿されている．
- 藤井さんが導入，森崎さんがプラクティス，吉羽さんが組織，についての話でまんべんなく話を聞けた．
- LTで朗読を聞いたのは人生2度目だったが，今回のUltimate Agile Storiesの紹介朗読も衝撃的だった…
- パラレルセッションで開催されたので仕方ないが，西村さんによるインセプションデッキ作成ワークショップもでたかった．とりあえず資料だけでも読む．
Head First Inception Deck
View more presentations from Nishimura Naoto
□以下メモ（誤りも含んでいるかとおもいます）
■オープニング
- 司会：前川(まえかわ)さん
- 持って帰って，何か起こすイベントになったらいいな
- 挨拶：細谷さん(オーガナイザー)
■セッション1：アジャイル開発の普及を阻むものを受け止め、乗り越えよう
- 講演者：
- 藤井 拓さん
- 概要：
- 4月からソフトウェア工学センターからアジャイル開発センターになった．
- http://www.ogis-ri.co.jp/rad/r-01adc.html
- 外板向けのビジネスでアジャイルを強化していきたい．
- 経験としては，10強の中規模プロジェクトからはじめ，30人強の大規模プロジェクトなどいくつかのものを経験している．
- 反復開発をお客様に理解してもらいづらい．
- これが普及の障害になるのではないか．
- 反復開発をお客様に理解してもらいづらい．
- 1stトライ：メインフレームからオープンへに移行．停止不可．複雑なデータ構造
- 1週間毎にやること決めて反復
- 統一プロセス
- 納期守ってリリース
- お客様に積極的に支援いただいた．
- 開発手法の理解（体験），顧客テスト
- 準委任契約
- 2ndトライ：メインフレームからオープンへ移行．
- 統一プロセス
- 納期守ってリリース
- お客様に積極的に支援いただいた．
- 開発手法の理解（体験），モデルでのコミュニケーション，ユースケース設計
- 準委任契約
- 3rdトライ：リクルート業
- 経験の結果
- 普及の課題
- お客さまのニーズ
- なぜアジャイル開発が必要か
- 信頼関係
- 信頼関係を築くためにはどうしたらよいか
- モデルを見てもらうための関係をどう築くか
- 日本固有の課題
- 現行からの移行
- 開発メンバーの教育と開発の成功をどう両立できるか
- お客さまのニーズ
- お客様のニーズ
- アジャイル開発は変化への対応を目指すがニーズとは何か
- 不確定性が絡む開発
- マーケットの反応，ビジネス上の効果，技術的リスクが不明な開発
- 不確定性が絡む開発
- リリーススケジュール厳守
- リリースが遅れるとビジネスに大きな影響がある
- アジャイル開発は変化への対応を目指すがニーズとは何か
- アジャイル開発に取組む2種類のお客様
- 信頼関係の構築
- アジャイル開発に対する不安の解消
- お客様側の不安
- 最終的に何ができるかわからない
- 開発会社側の不安
- 無限に仕様変更ができると思われるなどの過度の期待がかかる
- 現状からの移行
- 開発メンバーの教育
- 現状を変えることのリスク
- いままでの開発プロセスでおこなっていたことを，どのように実現するのかわからない
- アジャイル開発を適用する開発規模や開発期間
- 現状は，開発期間が3ヶ月くらいで不確定性が高いものに適用している．
- 長期間に及ぶ開発には不確定性が多いため，長期間の開発にも適用していきたい．
- ForresterResearchの調査結果
- 欧米で約20%が反復，30%がアジャイル開発
- これから普及していくのではないか．
- 欧米に対抗する意味でも．
- 解決策
- アジャイル開発と統一プロセスの統合
- 反復開発プロセス
- リスクをどんどん下げていく
- 計画を柔軟に変更していく．
- 統一プロセス
- 統一プロセスのフェーズ目標
- 方向づけ
- 開発企画とアーキテクチャ候補を策定
- 推敲
- 作成
- 移行
- 本番リリースレベル
- 方向づけ
- RUPのベストプラクティス
- AMDD(Agile Model Driven Development)
- http://www.agilemodeling.com/essays/amdd.htm
- 紙やホワイトボードでかろうじて役に立つ程度のモデルを作成する
- ライフサイクル
- 初期フェーズでは，時間をかけずに，とりあえずのモデリングを行う
- AMDDのワークフローの役割の内容は決まっていない
- アジャイルUPは何に役立つか
- 不安の解消
- 長期的なマイルストーンの設定
- 必要な成果物を作る
- 現状からの移行
- 要求変更を受けいれる部分を残す
- 段階的な移行を可能にする
- 作業や成果物を考える材料を提供する
- モデルによる品質向上やコミュニケーション精度の向上
- 不安の解消
- 測定の活用
- SouthernSCOPE
- SCOPEマネージャーを雇う，FP法で初期の費用とスケジュールを見積もる，など計6ステップ位
- OGISではFPではなくCOSMICを利用している
- 機能規模の算出方法
- 正味機能規模
- 変更機能規模
- COSMIC
- データ移動に注目しているので，DBアクセス以外の通信も測定可能
- 測定時にはUIのモックなどを使っている
- COSMICは決まったものなので，理解してもらいやすい
- データ移動に注目しているので，DBアクセス以外の通信も測定可能
- 開発労力と機能規模は正の相関
- 機能規模生産性を評価できる
- 普及の将来
- 成功事例が集まってくると普及が加速するのではないか
- スライドはOGISのWEBに上げる予定
- Q:信頼関係と統一プロセスの関係が繋がらないが？
- Q:プロセスと開発規模の関係お
- Q:お客様を巻き込んでテストをしっかりできないとだめなのではないか．テストはどのくらいしているのか．
- A:お客様がテストすることは受け入れテストくらいで，ものによっては納品検収的なものもある．
- Q:アジャイルUPにおいて，お客様と共にかろうじて役に立つ程度のモデルを作成する際には，自由な記法で行うのか．
■セッション2：チームの自律性を発現する仕組み作り 〜 ThoughtWorks Studios を使ったアジャイル開発のすすめ 〜
- 講演者：
- 設楽 秀輔（したら しゅうすけ）さん
- 概要：
- 自己紹介
- アジャイルの普及促進グループのリーダ
- コンサル，教育，営業
- ツールの紹介
- アジャイルの普及促進グループのリーダ
- 特徴的なツールになっているので，なぜそうなっているのか，背景とコンセプトを紹介
- アジャイルなチーム運営
- 継続的改善の文化
- 今日はその中の自律性，タスク管理を話す
- 自律性とは
- チーム外進捗管理方法
- ストーリ割り当て
- 反復の管理
- 今回は説明パス
- チーム内進捗管理方法
- 毎日チェックする
- チームが主体的にチェッックする
- 計画にそっているか
- 毎日チェックする
- 自律性を発揮するには習慣を変える
- 従うルールを変えるだけで実現可能
- "タスクは優先度順に変更する"など
- ルールの変更の実効性確保
- 習慣の変更はそれなりに大変なので．
- 従うルールを変えるだけで実現可能
- タスクボード
- 習慣を変えるための道具としてタスクボードが良い．
- 優先度の高いストーリーから処理する
- タスクの完了条件を明確にしてパーセント管理しない
- タスクをくだく
- 滞留しているタスクを重点的にチェックする
- 間違った使い方も多い
- WBSのチケット化
- 作業単位ごとにチケット作ってしまう．
- チケットに進捗率を記入する．
- ストーリごとに担当者が決まっている．
- WBSのチケット化
- ThoughtWorks Studio
- mingle
- メイン
- PJ,タスク管理
- go
- 構成管理，CI
- CIだけであれば機能過多．Jenkinsのほうがすっきり
- 上級者向け
- twists
- Seleniumをラップしてつかえるようなもの
- 上級者向け
- mingle
- mingle
- ポスグレがバックで走っている
- ストーリの下にタスクがぶら下がっている
- ストーリもタスクもDBで管理しているので構成変更も容易
- タスクをドラッグでステータス変更できる
- Q:タスク大きくなったらどうなるのか
- A:縦に並ぶ
- Q:タスクを細かく砕くのはどうしたらいいのか
- A:人に合わせて同じ粒度で砕く
- A:縦のベクトルにきってあげる．ストーリの区切り方に近いが．
■Ultimate Agile Stories Iteration1
- 細谷さん解説
- 人によってスタンスが違うので，アジャイルを一言で言うのが難しい
- 逆に好きに書いてもらったら面白いのではないだろうか．
- 並びの法則
- 細谷さんの独断と偏見で決めた
- 自分語り(歴史系)が並ばないようにした
- 夏コミターゲットなので，Ite2は12月くらいから始動しようかと．
- 11/10@大阪でTechLion開催
- その際に誕生秘話話す
■セッション3：関係者に理解してもらえるアジャイル開発にむけて 〜採択されたアジャイル開発の学術論文から説明のパターンをさぐる
- 講演者：
- 森崎 修司(@smorisaki) さん
- 概要：
- 関係者全員がそのスタイルやプラクティスに合意することによって、アジャイル開発の本質が発揮されることを多くの方が感じていると思い ます。しかしながら、単に「顧客の価値を最大化する」「変化に強い」「小さく失敗できる」とメリットを示すだけで、いつも関係者が理解を示してくれるとは 限りません。他との比較やなぜそれがうまくいくかを納得してもらう必要があります。学術論文も同様で論文で主張している内容をうまく評価できているかが採 択の基準の1つです。 本セッションでは論文採択率30%未満の国際会議においてアジャイル開発を研究テーマとした学術論文の主張や評価の方法からパターンを紹介します。これを もとにセッション会場全員で関係者の巻き込み方を議論できればと思います。
AgiltTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
View more presentations from smorisaki
- 論文査読をおこなっていると，アジャイルに関する論文が結構出てきている．
- プラクティスがアジャイルでない時，ある時
- 試行錯誤してみたい：
- ない時は次の版
- ある時はそのイテレーションでトライする
- 優先順位の変更：
- ない時は今やっていることを終わらしてから
- ある時はやること変えて後回しにすること決める
- 試行錯誤してみたい：
- 論文の査読をおこなっていると，採録・不採録となるアジャイル論文の違いが見えてくる．
- the International Symposium on Empirical Software Engineering and Measurement(ESEM)のプログラム委員
- 27,28本査読した
- the International Symposium on Empirical Software Engineering and Measurement(ESEM)のプログラム委員
- 落ちるパターン
- Ultimate Agile Storiesに詳細を書いている
- 前提の明確化
- 他との関連
- 他の開発プロセスや既存の慣習との関連が書かれている
- 比較対象・評価基準
- 試行・事例・観察Pj
- 事例は数多く，かつ，長期間のものがよい
- 試行・事例+シミュレーションの合わせ技というものもある
- 実施には試行していないが，こうなるだろうというExample Senarioをつけているものもある．
- 例題1
- 目的：ユーザにオンサイトにいてもらうこと
- 対象：ユーザを説得する
- タイミング：契約前のプロジェクト計画中
- ソフトウェア：委託開発の業務システム
- 何を課題と設定するか
- どのような事実をもって理解してもらおうとしますか
- オンサイトでない時のメリット・デメリットは何ですか
- 起こりうる課題が何であると説明するか
- 課題：確認にかかる時間かけるのはもったいない
- ロスしている時間を計測する
- お客さんの時間を拘束することはデメリット，メリットはより高い価値のソフトウェアを提供する
- 時間拘束以外に，整理して話ができない
- 例題2
- 目的：透明性を確保する
- 対象：プロジェクトメンバと管理職を説得する
- タイミング：プロジェクト計画の途中
- ソフトウェア：内製の製品
- 何を課題と設定するか
- どのような事実をもって理解してもらおうとしますか
- 透明性によるメリット・デメリットは何ですか
- 課題：メンバと管理者の工数の感覚に違いがある
- 自分たちの作業見積もりと実績を記録してずれていることを認識してもらう
- 全員の工数の感覚が統一される．実際のデータを見ながら具体的な議論できるのがメリット．
- 記録に手間がかかる．
- 興味があれば，Ultimate Agile Storiesを参照．
- 本に詳細がある
- 現場にフィードバックするまでにがagile tour osaka
- 実りある改善を．
■セッション4：アジャイル開発と組織
- 講演者：
- 吉羽 龍太郎(@Ryuzee) さん
- 概要：
- 誕生日祝いをするチームに3ヶ月くらいでなった．
- 資料：http://www.ryuzee.com/contents/blog/4260
Agileと組織
View more presentations from Ryuzee YOSHIBA
- 十年前はうさぎとカメの競争だったが，今は揺れる水面を猛スピードで突き進むものになっている
- そのために迅速な意思決定，素早く具現化することが必要
- 従来の企業だと，決定だけで半年かかることもある．今では，それでは遅い．
- そのために迅速な意思決定，素早く具現化することが必要
- 変化しなければ緩やかに死んでいく
- 組織に対する背任
- トヨタ生産方式，は良い本．おすすめ．
- Scrum導入時に守破離の守からきちんとやるべき
- うちではできない，と勝手に制約かけない
- 学習する組織，は良い本．おすすめ．
- ビジョンの作り方は5種類
- 命令，説得，テスト，相談，協創
- 成功する組織は協創
- 組織の多様性は強さ
- Scrum Boot Camp でも女性が入るなど多様性があったほうがうまくいっている
- 権限の7レベル
- 指示する，売り込む，相談する，同意する，アドバイスする，問い合わせる，移譲する
- すべての権限は移譲できるわけではない
- 責任に関して，チームで議論すると良い．
- 何をしなければならないのか，ということに関係する．
- 〇〇してはいけないというルールを，〇〇しようというルールに変えると良いのではないか．
- やる気が出てくるのではないか．
- まともな生活をしたくてアジャイル開発をしたいのなら，チームの人もそうなのではないか．
- きちんと説明したらチームの人も参加するでしょ．
- Q:冒頭のチームはどんなダメ状態で，どんなことをしたのか．
- A:カンバンボード．チームの会話を増やした．ある程度やると，勝手に活性化していく．
- Q:どうして，それを選んだのかということが大事なことを再認識した．
- A:同意
■LT
- 5分
- 川端さん(@agilekawabata)
- 中村さん(@yohhatu)
- しんどいを楽に，つまらないを楽しく，
- お客様からのフィードバックを知りたい．
- お客様の目的から見て，どうだったのか．
- 因果関係は難しい．数字は出せない．人もばらばらになってしまう．
- フィードバックを得ることができたら，どうなるか．
- よりよい価値を届けることができるのではないか．
- 懇親会で話しましょう
- 阪井さん(@sakaba37)
チケット駆動開発によるアダプタブル・ウォータフォール開発
View more presentations from Makoto SAKAI
- 西さん
- 川端さんのUltimate Agile Stories(UAS)の記事の一部を読む．
- 前川さんのUASの記事の一部を読む．
- 細谷さんのUASの記事の一部を読む．
- 阪井さんのUASの記事の一部を読む．
- 西さんのUASの記事の一部を読もうとして終わる．
■クロージング
- 前川（まえがわ）さん挨拶
- マネージャー視点だが，アジャイルをやっているところは強さがあると感じる
- 細谷さん挨拶
- かなり充実したセッションだった．
- これからもイベント企画していく
