Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ウォーターフォールのプロジェクトをちょっとだけアジャイルにする小さな魔法
Search
finayama
November 28, 2012
Technology
1
690
ウォーターフォールのプロジェクトをちょっとだけアジャイルにする小さな魔法
finayama
November 28, 2012
Tweet
Share
More Decks by finayama
See All by finayama
How to make a project plan
finayama
0
270
WBS(WorkBreakdownStructure)を作るときに知っておきたい7つのこと
finayama
1
890
Other Decks in Technology
See All in Technology
歴史から学ぶ、Goのメモリ管理基礎
logica0419
14
2.7k
[PR] はじめてのデジタルアイデンティティという本を書きました
ritou
1
800
ファインディにおけるフロントエンド技術選定の歴史
puku0x
2
1.4k
RALGO : AIを組織に組み込む方法 -アルゴリズム中心組織設計- #RSGT2026 / RALGO: How to Integrate AI into an Organization – Algorithm-Centric Organizational Design
kyonmm
PRO
3
1.1k
1万人を変え日本を変える!!多層構造型ふりかえりの大規模組織変革 / 20260108 Kazuki Mori
shift_evolve
PRO
6
1.2k
First-Principles-of-Scrum
hiranabe
4
2k
松尾研LLM講座2025 応用編Day3「軽量化」 講義資料
aratako
15
5k
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
5
1.5k
Introduction to Sansan Meishi Maker Development Engineer
sansan33
PRO
0
330
Redshift認可、アップデートでどう変わった?
handy
1
140
kintone開発のプラットフォームエンジニアの紹介
cybozuinsideout
PRO
0
510
あの夜、私たちは「人間」に戻った。 ── 災害ユートピア、贈与、そしてアジャイルの再構築 / 20260108 Hiromitsu Akiba
shift_evolve
PRO
0
590
Featured
See All Featured
Music & Morning Musume
bryan
46
7k
Testing 201, or: Great Expectations
jmmastey
46
7.9k
Scaling GitHub
holman
464
140k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
40
Un-Boring Meetings
codingconduct
0
180
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Fireside Chat
paigeccino
41
3.8k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
1
600
Facilitating Awesome Meetings
lara
57
6.7k
The World Runs on Bad Software
bkeepers
PRO
72
12k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
1
50
VelocityConf: Rendering Performance Case Studies
addyosmani
333
24k
Transcript
ウォーターフォールのプロジェクトを ちょっとだけアジャイルにする 小さな魔法 Flicker Little Laddie @finayama
ウォーターフォールは問題がいっぱい? いつもやっているウォーターフォールの開発プロジェクト。 上手く行くときもあるけれど、ほとんど、 何かトラブルが起きている。 Flicker splorp
ウォーターフォールが問題なの? 窓の外を見てみよう。 ビル建設のプロジェクトは、ちゃんと竣工日に出来ている。 ソフトウェアよりビル建設の方が (物理的に)大変そうなのに。 でも、キチンとできているよね。 Flicker williamcho.
ウォーターフォールが問題なの? ウォーターフォールと言うしくみに問題があるのか、 それともソフトウェア開発プロジェクトのやり方に 問題があるのかな。 あるとしたら、どんな問題があるのだろう。 Flicker Steve Corey
顧客に何を届けるのか知っている? このチームは何を作るために編成されたのだろう。 顧客に届けるシステムはどのようなものか、チーム全員で 共有されているのだろうか。 もし、共有されていないなら、なぜ、しないのだろう。 もし、共有されていたら、チームメンバはどう思うだろう。 Flicker cateringcom
誰が何を出来るのか知っている? 顧客にシステムを届けるこのチームは、 どのようなスキルを持つプロフェッショナルが 揃っているのだろう。 一緒に働くメンバが、何が得意なのか知らないで、 どうやって一緒に共同作業をするのだろう。 Flicker [N]atsty
そのWBSは何ができたら終わり? 顧客に届けるシステムの作業はWBSに展開されている。 そのWBSは、どのような状態になったら“終わり!” にしていいのだろう。 セルフレビューが終わったら? チームレビューが終わったら? レビューの指摘が完了したら? それとも、 チェックインしたら? Flicker
drj1828
隣のメンバは何をしているの? プロジェクトがデスマになる真の原因は“意思疎通”だとおも うんだけど、そうなら“もっと“意思疎通したい。 なら、チームの意思疎通は、いつするのが良いのだろう? 週1回で十分なのだろうか? でも、プロジェクトが佳境になると毎日するはなぜだろう。 Flicker Adam Bognar
ウォーターフォールのプロジェクトを ちょっとだけアジャイルにする 小さな魔法 Flicker Alexandria Mezzano LaNier
プロジェクト開始時のミーティング プロジェクトを開始するときにチーム全員が参加して キックオフミーティングをしよう。 ポイントはこれだ。 1.全員参加する 2.図と表を使って“何を作るのか” 共通認識を持とう 3.マスタースケジュールでマイルストーンを共有しよう 4.全員でこの時点でどこにリスクがあるか共有しよう Flicker
City of Raleigh, NC
得意技を披露しよう プロジェクトをキャリーするチームメンバが、 どんな得意技を持っているか共有しよう。 自分が困ってから一人ひとりに聴いて回るのは、やめよう。 Flicker WSDOT
工程ごとの完了状態を定義する WBSは、工程ごとに完了の状態が決まっているものだ。 設計工程なら、すべての設計が終わらないと工程だって、 終わらない。 テスト工程は、仕様書とテストがあるから2つの種類の 完了状態があることに注意しよう。 WBSをキチンと完了の状態にして、 はじめて“終わった”と言えるのだ。 Flicker jpconstantineau
毎日朝会しよう プロジェクトが佳境になって朝会を始めるのは、 遅れては困るタスクがあるからだ。 最初のタスクだって遅れたら困る。なら最初から朝会しよう。 ポイントは、 1.昨日の実績 2.今日の予定 3.困っていること を担当するメンバ自身が“数分で”チームに伝えること。 この場で検討会をしちゃいけない。
それは必要な人だけでやる。 Flicker Own Page One