Weitere ähnliche Inhalte
Ähnlich wie アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜 (20)
Mehr von Dai FUJIHARA (11)
Kürzlich hochgeladen (11)
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
- 2. 藤原 大
@daipresents
• 楽天株式会社 開発ユニット
• アジャイルグループ マネージャ
• 好きなヒーロー:
ウルトラマンゾフィー
ダイナマン、スーパーワン
キョウダイン、ZZガンダム
http://daipresents.com/
- 12. 1. たくさんのプロジェクトから
WIPを使ったかんばん
http://www.flickr.com/photos/31029865@N06/5845786904/
- 21. 2. 詳細なプロジェクト計画
から軽量なビジネス案
http://www.flickr.com/photos/31029865@N06/5845786904/
- 29. 3. 年間予算から
徐々に追加投資
http://www.flickr.com/photos/31029865@N06/5845786904/
- 31. 4. エライ人が作る
年間計画から
チームによる
計画サイクル
http://www.flickr.com/photos/31029865@N06/5845786904/
- 37. 5. WBSからアジャイルな
見積りと計画づくり
http://www.flickr.com/photos/31029865@N06/5845786904/
- 39. アジャイルな
見積りと計画づくり
•優先順位付けと見積り
•タイムボックスで計画
•頻繁な見直し
- 43. 見積りは確率だ
がコミットメント
は確率ではない
楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO
- 44. 6. プロジェクトから
リリーストレイン
http://www.flickr.com/photos/31029865@N06/5845786904/
- 49. 7. PMBOKから
アジャイル
プロジェクト
マネジメント
http://www.flickr.com/photos/31029865@N06/5845786904/
- 52. Velocity
予定多すぎない? 急激に落ち込んでない?
当初は上がったり下がったり リリース後
安定していない 下がってない?
- 53. かんばんの状態
順調にDONE
しているか?
Doingが増加してい
TODOが増えてない
ないか?
- 54. ゴール
• 仕様どおり
• ビジネス価値が正しかった
• これを安定して継続的に繰
り返すこと
- 57. 8. WFのマイルストン
現実に即した
マネジメント
http://www.flickr.com/photos/31029865@N06/5845786904/
- 62. レガシー リーンアジャイル
たくさんのプロジェクト WIPを使ったかんばん
詳細なプロジェクト計画 軽量なビジネス案
年間予算 徐々に追加投資
エライ人が作る年間計画 分散回転式計画
WBS 見積りと計画づくり
プロジェクト リリーストレイン
PMBOK アジャイルプロマネ
WFのマイルストン 現実に即したマネジメント
- 63. ヒーローは
誰だ?
http://www.flickr.com/photos/31029865@N06/5845786904/
- 64. Javaエンジニアとして働き出す
SIerに就職し横浜に引っ越す
好き勝手やっていながら親に頭を下 03
げて専門学校に行かせてもらう
日記を書きだす 00 サークルにエンジニア
ビリヤードサークルを作る が多いことに気がつく
高校を卒業してフリーターになる
90 ICQでギリシャ人に話しかけられびっく
りして電源を抜いてしまう
Macに出会う、Windows95を使う
- 65. マネージャになる
Agile Japanで発表
デブサミ2012で発表
アジャイルマニフェスト10周年
12
イベント開催に加わる 11
アジャイルコーチ開始
Agile2010に参加
10
はじめて勉強会で参加・発表
09 チームリーダーになる
アジャイル開発に取り組みはじめる
08
数日後、標準化を撲滅しようと決意する
現職に転職。標準化チームに配属される
- 66. 職業エンジニアどうすれば
いいですか?
アジャイルは
バズワードだ 今 会社が○○
だから
アジャイルやって
みたいんですけど
- 73. 話し合いに入れなかった。 報告のレベルがわかりにくい。全体のスケジュールが見えない。 タスク
DONEを共有できていない。タスクがなくなった。 人に任せっきりになっていた。 利用者と相談
ができていなかった。 タスクが多かった。 仕様の理解不足。 横槍り作業を考えるのが大変。 メン
バーに頼りすぎた。 レビューが完了できなかった。 DONEの定義が曖昧。 口頭のほうが早いこと
があった。 デザイン当てに時間がかかる。 レビュー反映に時間がかかる。 テストの時間が足りて
いない。 誰が何をやっているかわからない。 確認ポイントがばらばら。 見積より時間がかかって
いる。 TODOが減ってきた。 これまでのレビューが怪しい。 コミット漏れがあった。 タスク洗い
出しがうまくなかった。 自動化に時間をつかえなかった。 デモを完全な状態で見せたかった。 開
発環境が整っていない。 メインタスク以外のタスクが影響。 体調があまりよくなかった。 タスク
を拾うのが消極的。 影響範囲把握ができなかった。 ドキュメントが古い。 作業遅延の報告が遅
い。 デモが意味なかった。 データが壊れて開発に影響した。ファイルのリリース漏れがあった。
コードが汚くなってきた。 目的を理解せず作業してしまった。 空き時間ができてしまった。 再設
計引き継ぎがうまくいってない。 タスクに入るためのタスクがあった。 寂しい。 リリース自動化
に失敗してしまった。 開発開始まで時間がかかった。 テスト不足があった。 寂しい。 タスクが大
きすぎた。 メンバーに頼りすぎた。 うっかり仕様抜けが発生した。 目に見える成果がなかった。
マージ漏れがあった。 処理内容の理解不足があった。 デバッグが遅い。 チャレンジが足りなかっ
た。 勉強会に参加できなかった。 バグがバグを生み出した。 実機を使ったテストが少ない。 英語
に困っている。 優先順位がわからなくなった。 コミット漏れがあった。 完成するまで先が見えな
い。 スケジュール通りは厳しくなった。 ゴールが不明確な部分がある。 見積り忘れがあった。
チームとマネージャで認識ずれ。 JSではまって時間を消費。 汎用的に作ると時間がかかる。 仕様
を確認せず実装してしまった。 メンバーのフォローが遅れた。 担当していない機能の理解不足…
144の『いまいち』
- 74. まず、見える化をしよう。 準備をしよう。 リーダにDONEを確認してもらう。 アジェンダを準備
しよう。外部のタスクを把握しよう。チェックポイントを作ろう。技術MTGをはじめよう。 口頭
で話そう。 ゴールの共有をしよう。確認者をちゃんと決めよう。 もうちょっと様子を見よう。明日
計画MTGをしよう。レビュー時間をとろう。コミット前に差分確認しよう。 いないときは置き手
紙をしよう。 自動化するレベルを考えよう。全員集合して分担をはじめよう。開発環境も並行して
つくっていこう。タスクボードを朝礼後把握しよう。2週間分はかならずみつもろう。 腹巻きをし
よう。 運用を考慮しよう。資料を残すようにしよう。環境構築も自動化していこう。レビューを
もっとしよう。データを壊さないようにしよう。 勉強会しよう。 デザイナーと話してみよう。見積
りを出そう。朝礼でカバーしていこう。チェックリストを作ろう。状況を整理してから共有しよ
う。 勉強会をしよう。 ENG MTGを活用しよう。最終確認までしたらリリースしよう。作業が止
まらないように動こう。伝える時間を作ろう。 なぜから考えてみよう。 レビューを忘れずにしよ
う。ゴールを再定義してみよう。朝礼を有効活用しよう。遅いと思ったら改善しよう。再計画に時
間をかけよう。 なぜから考えてみよう。 ソースレビューで検知しよう。ブラウザテストに時間をか
けよう。確認手順を統一していこう。1日1タスクを考えていこう。付箋にして見える化していこ
う。 隣の人がを気にかけよう。 朝礼で共有していこう。付箋にして見える化していこう。残った
TODOに名前を書こう。テストを充実させていこう。 勉強会でナレッジ共有しよう。 朝礼で空き
予定も共有していこう。はやめにアラートを出していこう。CIサーバを活用しよう。手でしかでき
ないテストを洗い出せ。 アイデアを出しあっていこう。 ストーリの裏にゴールを書こう。実装の流
れを書いてみよう。システムの理解を深めよう。テスト計画を張り出そう。 小さく作っていこう。
STGなどの環境で確認を強化しよう。タスク洗い出しでDONEの定義。タスクの移動は朝礼でやろ
う。 積極的に学んでいこう。 確認のルールを決めよう・・・
100の『チャレンジ』
- 75. スタンドアップMTGがよかった。タスクボードができた。 メンバーから意見が出た。 ゴールが明
確だった。決定がスムーズだった。3キロ痩せた。 DONEの定義がよかった。ファシリテーション
が良かった。誰が何しているかわかりやすい。 スキルの無さに気がついた。 問題解決の時間が短く
なった。進んでタスクを取りに行けた。メンバーがサポートしてくれた。 サービスを全員で考えれ
た。 台風で早く帰ることができた。機能のブレストがうまくいった。メンバーのことがよくわかっ
てきた。 要件以外の提案が出てきた。 コミュニケーションがとれている。ペアワークがうまくいっ
ている。データ構造が理解できてきた。Rubyを勉強できた。 タスクをプル型でとれた。 リリース
が成功した。既存ユーザの評価が良かった。トラブルのリカバリがスムーズ。 メンバーに元気をも
らった。 周りがよく見えた。処理性能が高くなる実装ができた。デモの自動化が早くてよかった。
自動リリースの範囲が増えた。 集中して開発できる。 開発∼テストの流れを理解できた。TODO
を増やすことができた。インタフェースの検討ができた。免許をとれた。 改善活動を皆でやること
ができた。 メンバーが増えた。開発環境が使いやすい。前よりすぐに人に聞くようになった。設計
∼リリースまで作業ができた。 チームのスピードが速い。 チーム感があった。座席変更がよかっ
た。 全タスクをDONEできた。 アイスが美味しかった。 朝礼の遅延報告が良かった。勉強会がと
てもよかった。リリースに自信をもつことができた。声かけしながらリリースできた。 新しいこと
にチャレンジできた。 メンバーとのペアオペがよかった。情報共有が良かった。 要件からENGが
入ってきている。 メンバーの目標を聞くことができた。設計を経験できている。リリースまでの流
れを理解した。 コードが綺麗とほめられた。 機能のデモが良かった。考えてソースを書くことがで
きた。リリースまでの時間が短縮できた。リリースとテストの効率が上がった。 自分のコードがひ
どいことに気がつくことができた。 新機能開発の立ち上がりが速い。ペアプロが良かった。皆で仕
様を考えた。設計が良かった。 何をやればいいかわかった・・・
142の『よかった』