ウォーターフォールのプロジェクトをちょっとだけアジャイルにする小さな魔法Flicker Little Laddie@finayama
View Slide
ウォーターフォールは問題がいっぱい?いつもやっているウォーターフォールの開発プロジェクト。上手く行くときもあるけれど、ほとんど、何かトラブルが起きている。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
finayama
asei
wakamsha
mosa_siru
i35_267
hakubishin3
kc_nakanishi
peisuke
sugawani
dahatake
chiroito
bun913
yuhattor
jrom
bkeepers
cassininazir
eileencodes
bcantrill
tammyeverts
mongodb
akmur
smashingmag
yeseniaperezcruz
revolveconf
bluesmoon