当たり前といえばそうなんだけどなかなかできないコミュニケーション。
- 会話によって伝える
- 対話を重視している
というのはよく分かった。
最近のウチラ・・・チケットで炎上してるだけだ orz
以下気になったところの抜粋
スクラム
実は日本の80年代の製造業での新製品開発からヒントを得て名付けられた名前
分散開発
推奨しているのは、まずプロジェクトのキックオフと最初の数イテレーション(スプリント)を、一ヶ所で行う。
こここでアナログの「かんばん」に全員で慣れる。さらに、全員が顔をあわせることで、
その後のコミュニケーションに重要となる信頼感を醸成する。
そしてその後、それぞれの場所に分かれて、デジタルツールで情報共有するというやり方だ。
進め方
デジタルツールを使いながら、一つのスプリントぶんのストーリーやタスクだけを印刷して
それぞれの部屋の壁に貼るというチームもある。自分たちで現場のプロセスを形作っていくのがアジャイルの姿勢
リファクタリング
アジャイル開発では、最初からシステムの全体構造を先読みした設計をしない。
全体構造を徐々に変化させながら成長させていく
ソーシャルプラクティス
- 朝会
- タスクかんばん
- バーンダウンチャート
- プランニングポーカー
- ふりかえり
- その他、これから以外にも多数
「共同でゴールに向かう」とは、チームメンバーが役割の垣根を越え、一丸となって開発に臨む様子を表した。
100% の精度を求めないアジャイル的思考で効率をアップ
100% の精度の追求は、一方では膨大な時間のロスを生む。
そこで、とりあえず 80% の精度が確保できていて、残りの 20% の精度を高めるのに倍の時間がかかるのなら、
そこで一度回答としてしまって時間を節約しようと。その代わり、リリース後に残り 20% に起因するて戻りが発生しても、
お互いに怒らないという約束を交わすのです。
ここで、今までのように怒ってしまうと、開発側は「次は怒られないように」と、さらに時間のバッファをとる悪循環が生まれます。
そうした負のスパイラルを防ぐのが「80% ルール」なのです。
スクラムのデメリット
プロジェクト全体を通して膨大なコミュニケーションが必要になること、
また、異種の分野から集まった参加者の考え方の違いで、チーム内に衝突が多く起こることがあげられる。
スクラムと実践知リーダー
「スクラムマスター」は、管理者という立場ではなく、製品開発の場を作るサーバントリーダーであるといえる。
また、「プロダクトオーナー」は製品のビジョンを作り、製品への要求を作るという意味で、製品自身の方向を決めるリーダーである。
フロネシス
実践からの知恵。
現実の状況と文脈の中で、その場で判断・行為ができる実践値実践知を持ったリーダーを、実践知リーダーと呼ぶ。
形式知(ビジョンや原則)だけでも暗黙知(現場の実行力)だけでもない。両者を行き来できるリーダーだ。
