basyura's blog

あしたになったらほんきだす。

アジャイル開発とスクラム

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント


当たり前といえばそうなんだけどなかなかできないコミュニケーション。

  • 会話によって伝える
  • 対話を重視している

というのはよく分かった。
最近のウチラ・・・チケットで炎上してるだけだ orz

以下気になったところの抜粋

スクラム

実は日本の80年代の製造業での新製品開発からヒントを得て名付けられた名前

分散開発

推奨しているのは、まずプロジェクトのキックオフと最初の数イテレーション(スプリント)を、一ヶ所で行う。
こここでアナログの「かんばん」に全員で慣れる。さらに、全員が顔をあわせることで、
その後のコミュニケーションに重要となる信頼感を醸成する。
そしてその後、それぞれの場所に分かれて、デジタルツールで情報共有するというやり方だ。

進め方

デジタルツールを使いながら、一つのスプリントぶんのストーリーやタスクだけを印刷して
それぞれの部屋の壁に貼るというチームもある。

自分たちで現場のプロセスを形作っていくのがアジャイルの姿勢

リファクタリング

アジャイル開発では、最初からシステムの全体構造を先読みした設計をしない。

全体構造を徐々に変化させながら成長させていく

ソーシャルプラクティス

  • 朝会
  • タスクかんばん
  • バーンダウンチャート
  • プランニングポーカー
  • ふりかえり
  • その他、これから以外にも多数

「共同でゴールに向かう」とは、チームメンバーが役割の垣根を越え、一丸となって開発に臨む様子を表した。

100% の精度を求めないアジャイル的思考で効率をアップ

100% の精度の追求は、一方では膨大な時間のロスを生む。
そこで、とりあえず 80% の精度が確保できていて、残りの 20% の精度を高めるのに倍の時間がかかるのなら、
そこで一度回答としてしまって時間を節約しようと。その代わり、リリース後に残り 20% に起因するて戻りが発生しても、
お互いに怒らないという約束を交わすのです。
ここで、今までのように怒ってしまうと、開発側は「次は怒られないように」と、さらに時間のバッファをとる悪循環が生まれます。
そうした負のスパイラルを防ぐのが「80% ルール」なのです。

スクラムのデメリット

プロジェクト全体を通して膨大なコミュニケーションが必要になること、
また、異種の分野から集まった参加者の考え方の違いで、チーム内に衝突が多く起こることがあげられる。

スクラムと実践知リーダー

「スクラムマスター」は、管理者という立場ではなく、製品開発の場を作るサーバントリーダーであるといえる。
また、「プロダクトオーナー」は製品のビジョンを作り、製品への要求を作るという意味で、製品自身の方向を決めるリーダーである。

フロネシス

実践からの知恵。
現実の状況と文脈の中で、その場で判断・行為ができる実践値

実践知を持ったリーダーを、実践知リーダーと呼ぶ。
形式知(ビジョンや原則)だけでも暗黙知(現場の実行力)だけでもない。両者を行き来できるリーダーだ。