-
Notifications
You must be signed in to change notification settings - Fork 47
Readingagilesamuraiinesm20110615
1.2 から再開
-
マスターストーリーリストはジョナサン語(以下、JR語またはJR Word)。 ** いわゆるプロダクトバックログとか、マスターバックログ("塹壕より"に載ってるとかいう話)
-
お客さんが欲しいものを、ユーザーストーリーとして記述する。
-
顧客が優先度をつけて、開発者が見積もる。
-
価値が高いものから順にソフトウェアに "変換する" (実装や実現ではなく変換という表現がcool!)
-
計画を信頼できるようにして、開発チームが自分たちの限界を超えた成果をあげることを約束しないように、ベロシティをとる。標本をとる。
-
何のためにポイントを出すかをきちんとお客さんと話す。
-
やると決めたことをやるのがアジャイル、やれないことをやるのはアジャイルではない。
-
非現実的な計画を、いつかできるような風にお客さんに思わせるのは一番不誠実。お客さんと一緒に信じることができる、現実的にできる形で伝える。
-
きちんと「完了」の定義をする (コンセンサスをとる) ことが大事
-
本番にリリースできる状態まで持っていっていることで「完了」となる。動くところまでやらないと「完了」ではない
-
要求とは発見されるものなので、プロジェクト開始時に決めておいてくださいというものではない。
-
優先順位をつけて、一番優先順位が高いものからやる。優先順位であって、優先度じゃない(どれも優先度:高、にしがち)。
-
真実を認めれば、不安やストレス・プレッシャーから解放される。やり方はひとつじゃないよ。
-
かつて、アリスター・コーバーンが提唱した Crystal という開発プロセスがあったが、いまいち先取りすぎて流行らなかった。ものはよかったのだが...
-
開発方法論バトルに生き残ったメジャーな開発手法は3つ。スクラム、XP、リーン。スクラムは捺印ナビリティが高い。XP は万能 (著者が XP 厨でバイアスがかかっている) 。リーンの説明は優等生的回答だね。
-
ひとつとして同じプロジェクトはなく、書籍や開発手法ですべてをカバーすることはできず、自分 (たち) できちんと考えることが大事。
開発手法としてのカンバンは、スクラムと違ってスプリントがない。Kanbanとkanbanの違いとかあるけど、なんかよくわかんないよね。そのレベルが気になるレベルに到達できるといいけど。
日本でカンバンに一番詳しい人が社内にいるよ? そこを見ればチーム(組織)の何かがぱっとわかるというのがカンバン、トヨタのカンバンは、ちょっと前風にいうと一個流しといわれているもの。ただし、実際のところはいくつでもよく速く流すことが大事。
海外では部署間、会社全体でカンバンを使おうという動きが盛んらしい、そういえば、クックパッドでは「お客様の声」を常に見える場所に表示しているけど、あれもいわゆるカンバン
- 人は自分の得意分野にこだわりすぎる傾向があるし、役割を与えるとそこに捕われるので、分断された細かい役割は作らない。
- 成功に寄与するなら役割など関係なく何でも協力する
- アジャイルチームは品質に責任を持つのはチーム。あらゆる作業が品質作業であり、品質管理部門というものはない。
この図は @m_seki が昔から言ってることなんだよね。
この開発工程を時間軸でスライスした図だけど、従来は分析、設計、実装、テストの順となっているところがアジャイルチームでは、分析、テスト、設計、実装という順になっているのに気がついた? 試験に出るよ。
-
同じ場所で仕事をすることでコミュニケーション時の摩擦が減らすことができ、信頼関係を築きやすい。ずっとは難しければ最初だけでも。
-
プロジェクトは最初が肝心。プロジェクトがはじまる前にも、きちんと開発者を集められるくらいの予算を用意しておくとかできることはある。
-
ジョナサンにかかれば、スティーブ・ジョブズもアジャイルサムライ。
-
積極的に関わってくれるお客さんがいないプロジェクトは嘆かわしい。
-
お客さんの役割を知ることは、アジャイルチームとしてとても重要なこと。
-
まずやることは「これから2週間、お客さんの仕事を解決します」という。次に、それを実行 (実現) する。そして、それを繰り返す。
-
信頼関係を築くためには、信頼貯金を貯めていくこと。
- 2011年6月22日(水) 10:30 から 11:30。続きは 2.3 。
- ReadingAgileSamuraiInESM20110622