無料ブログはココログ

« サーバントリーダーシップを否定すると嫌な上司になっちゃう件 | トップページ | 支援者としてのリーダー - 「リーダーシップ3.0」を読んで - »

[#TiDD] チケット駆動開発のパタンランゲージを作りたい

あけましておめでとうございます。年初にあたって夢を書きたいと思います。

モチベーション

2009年からチケット駆動開発のブログ記事を書いていますが、未だに具体的な実施方法を体系的にお話ができません。

もちろん [#TiDD] チケット駆動開発の「ライトウィング」と「レフトウィング」 の様な概念的なお話はできますし、書籍チケット駆動開発に書いたようなプロジェクトの状況にあわせたテーラリングの方法などは説明できます。

しかし、アジャイル開発ではタスクカードをチケットにするとか、ウォータフォール開発ではWBSをチケットにしたり、備忘録としてチケットを使う、というようにベースのプロセスが必要です。

このため、チケット駆動開発を実施するには、現状の問題点を明らかにした上で、その現場にふさわしい実施方法を決める必要がありました。

標準化の問題点

普通に考えれば、成功したプロジェクトを参考に標準プロセスを定める事になるでしょう。標準化すれば、そのプロセスを理解して、過去の問題を改善し、管理し、ツールによる実行や支援が可能になるでしょう。

その反面、教条主義に落ち入り易く、チームは考える事をやめて、ルールを守る事がゴールになってしまいます。底上げはできるものの、目指すべき自分たちで考えて改善する文化を育てにくくなってしまいます。

チケット駆動開発にはたくさんの利用方法があり、様々な問題が解決可能です。多くの人たちが、自分たちで考えて、工夫する事で、開発をよりよいものにしているのです。固定化を目的とした標準化はちょっと違う様に思いました。

プラクティスだけでもない

そこで、過去の経験に基づいてプラクティスを集めれば良いと考えました。“No ticket, No commit!”のようなプラクティスを揃えておけば、それらを組み合わせてソフトウェア開発が実践できるからです。

チケット駆動開発のプラクティスが示されることで、議論が容易になりました。「 “No ticket, No commit!”は実施してますが、 “No ticket, No work!”は実施していません。」といった感じです。

しかし、共通化してパターンを抜き出したものは参考になるものの、どのように自分たちのプロセスを構成すれば良いかは現場の工夫に任されたままでした。

パタンランゲージに期待するもの

そこで、パタンランゲージなら標準化と多様性のバランスが取れるのではないかと期待しています。

パターンというとあたり前の繰り返しの様に考えてしまいますが、心からの良い変革を示します(美しさは変化の中にある - パタンランゲージ - #agileto2015)。単調な建物が延々と並んでいると飽きてしまいますが、途中に講演があり、並木があり、木漏れ日があったなら、良い心地がするでしょう。そのような変革です。

それは単独で存在するのではなく、様々なレベルのパターンがあり、それらが組み合わさって、心地よい風景を表すものです。([#agileto2014] コーディネートは全体で - Agile Tour Osaka 2014「パタン特集」 -)。

このようにパタンランゲージがランゲージであるのは、心に響く様々な言葉を紡ぎ合わせて良い小説が構成される様に、様々な心地よいパタンを組み合わせて、全体が構成されるからです。

プロジェクトが始まろうとするとき、様々なイメージをするでしょう。ソフトウェアの事、お客様とのやり取り、チーム作り、メンバー間の情報共有、などなど、様々な視点と様々なレベルでプロジェクトを考えて、プロジェクトの準備を進めていきます。

単なるプラクティスとしてチケット駆動開発を利用するのではなく、心地よい変革としてチケット駆動開発を様々なレベルで取り入れ、それらをうまくつなぎ合わせる事でプロセスを構成していく。そんなことをはじめていきたいと思っています。

参考リンク

[#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである -
[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -
[#TiDD] プロセスプログラミング3(改) - ファシリテーション -
[#TiDD] プロセスプログラミング4 - チケット駆動開発 -

標準化のトレードオフ その1 -  標準化のパターン -

標準化のトレードオフ その2 - 本当に狼男ですか? -
標準化のトレードオフ その3 - 応用のできない習熟 -
標準化のトレードオフ その4 - 慣性の法則 -
標準化のトレードオフ その5 - 従来法と改善 -
標準化のトレードオフ その6 - スクラムの形式知が大切な理由 -
標準化のトレードオフ その7 - リーンソフトウェア開発の考える仕組み -
[#TiDD] 標準化のトレードオフ その8 - チケット駆動開発はソリューションライブラリ -

[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性
[#TiDD] プロセスモデリングの課題からチケット駆動開発を考える - きょうわたしたちに救い主が生まれた -
[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -
[#TiDD] チケット駆動開発の3要素
[#TiDD] アダプタブルな開発を実現するチケット駆動の3要素

このエントリーをはてなブックマークに追加


« サーバントリーダーシップを否定すると嫌な上司になっちゃう件 | トップページ | 支援者としてのリーダー - 「リーダーシップ3.0」を読んで - »

ソフトウェア」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

コメントを書く

コメントは記事投稿者が公開するまで表示されません。

(ウェブ上には掲載しません)

« サーバントリーダーシップを否定すると嫌な上司になっちゃう件 | トップページ | 支援者としてのリーダー - 「リーダーシップ3.0」を読んで - »