無料ブログはココログ

« 2010年3月 | トップページ | 2010年6月 »

[TiDD] チケット駆動開発はマネジメント - 「もしドラ」を読み始めて -

先日、眠れなくて深夜番組を見ていたら「もしドラ」を説明していました。

「もしドラ」というのは、ダイヤモンド社から出ているちょっと変わった岩崎夏実さん

もし、高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら

というビジネス書です。野球部のマネージャを引き受けた主人公「みなみ」何をすべきかをなやみ、書店で推薦された世界で一番売れているドラーカーの「マネジメント」を読んで、野球部と共に成長するお話です。

TVで見たこと、途中まで読んだこと、岩崎夏実さんのブログ中で読んだことを私なりにまとめると、

1) 顧客を明確にすることで、目標が明らかにする
2) 仕事には働きがいが必要
3) 人を生かす
4) イノベーション

という点が、チケット駆動開発(TiDD)とつながっていると思いました。この本やマネジメントの話はまた別の機会に書くとして、今回はTiDDとの関係を書いてみたいと思います。

TiDDは開発法でありながら、タスクマネジメントの方法です。もちろんマネジメントと関係があるのは間違いないのですが、上記の点はTiDDの特徴を示しています。

1) 顧客を明確にすることで、目標が明らかにする
TiDDはその目標によって使い方が変わる。XP祭り2010のあきぴーさんはきちんと管理するためにワークフローを重視しましたが、私はプロジェクトの元気を取り戻そうとTiDDを導入しました。

2) 仕事には働きがいが必要
もしドラ90ページでは、ドラッカーのマネジメント74ページを引用しています。

働きがいを与えるには、仕事そのものに責任を持たせなければならない。そのためには、(1)生産的な仕事、(2)フィードバック情報、(3)継続的学習が不可欠である。

これは、TiDDにおける、チケットで責任を与えて生産を任せる、見える化やコメントによるフィードバック、繰り返しのリズムに相当するでしょう。

3) 人を生かす
プロジェクトの元気と言うのは、まさに人を生かすことでしょう

4) イノベーション
あきぴーさんの発表にあるように、基本的なルールが多くのプラクティスを生みました。

このように、TiDDにはドラッカーのマネジメントの要素が含まれているのです。だから、プロジェクトがうまくいったのだと思いました。

[TiDD] チケット駆動開発におけるリスク低減法

リスクとは、以下のような定義になっています。

  リスク=問題の発生確率×影響

この式から考えると「リスクが高い」というのは誤用で、「リスクの問題が発生する確立が高い」あるいは「リスクが大きい」というのが、正しい表現でしょう。

従来のリスクマネージメントでは、このリスクを避けるか、貸し倒れ引当金のようにリスクをあらかじめ見込むかの方法がとられていました。近年ではリスク駆動あるいはリスクベースという考え方によって、リスクを少なくするという対処法が取られることが多くなっています。

チケット駆動開発では、チケットの優先順位に従って開発します。1日の作業や1イテレーションあるいは1スプリントなど、一定の期間で実施できる作業を優先順位に従って選択すれば、開発プロセスに関係なく、アジャイル開発の特徴と言われている「スコープの変更」が行えます。

この優先順位を決める際に単に重要度だけでなく、リスクの計算に基づいてチケットの優先順位を考えたなら、チケット駆動開発でリスクを低減することができます。さらに、リスクを考慮した上でチケットを分割すればより効果的でしょう。

具体的に考えると、早く実現したほうが良い(リスクが小さくなる)場合と、遅らせたほうが良い場合があるでしょう。

1.早めに実現した方が良い場合

基本的に、将来の方向性が決まる場合です。

- 性能や実現可能性の技術検証
- ユーザインタフェースのユーザビリティなどの不確定要素がある
- 継続する開発の見積もりに利用する
- 影響を受ける作業が多い(クリティカルパス)
- ビジネス上重要

2.後回しにした法が良い場合

後戻りが難しいものは、決定を遅らせた方が場合もあります。

- 何らかの影響により変更の可能性のある
- ビジネス上重要でない

これらを元に優先順位を考える場合、具体的な影響度を考えにくい場合もあるでしょう。そのような場合は、影響度を5段階あるいは10段階にランキングすれば、大まかな計算が可能になるでしょう。

また、チケットの分離・分割も効果的です。ある程度の規模があり、内部にお依存関係がない場合、リスクの含まれる部分と含まれない部分を分割して、ふさわしい時期に実施することが考えられます。

単純に分割できない場合も、アーキテクチャや実装を考える際にリスクのある部分を分離できるように「抽象レイヤを入れて分離する」という方法もあります。ただし、現状のリスクだけを考えると良い方法ですが、将来にわたって問題がないかを良く検討してください。

日本の契約形態では、チケット駆動開発を用いても容易にスコープを変更できない場合もあるでしょう。しかし、同じソフトウェアを開発する場合でも、実施する順番やチケットの分割を工夫すれば、少ないリスクで開発することは可能なのです。

[TiDD] チケット駆動開発の概要と体験談

社内向けに講演する機会がありましたので、XP祭りのスライドを元にまとめてみました。

発表概要

 小規模かつ高機能なソフトウェア開発の増加、環境のオープン化、ビジネス環境の変化など、近年増加する困難さから、BTS(障害管理ツール)を用いてタスクを管理するTiDD(チケット駆動開発)が注目されています。本発表ではこのTiDDの概要と体験談をお話しします。

 まずTiDDの概要として、普及の背景、歴史、事例、と共にTiDDとは何かを説明します。次にTiDDの体験談として総合文教ソリューションUniVisionのカスタマイズ開発での体験談を報告します。体験談のプロジェクトでは、リリースが近づくにつれ、細かな作業が増えて困っていました。そこで、TiDDを導入したところ、作業の抜けが少なくなっただけでなく、プロジェクトが元気になりました。

良書の条件 - プロになるためのWeb技術入門 -

かつては、雑誌の記事にも良い記事がありましたが、ソフトウェアの技術の幅が広がっているのに紙面の関係で大局的な内容か、ピンポイトで深堀をしているかのどちらかで、良い本が求められている時代だとと思います。

しかし、技術の変化が激しくて、良書が減って手順ばかりを書いたいわゆるハウツウ本が増えるようになってしまいました。

「なぜ、あなたはWebシステムを開発できないのか」というショッキングなサブタイトルがつけられたこの本は、そのような時代にかつての良書を求めて書かれています。

私の思う良書はこのような本です。

  • 技術の表層的な説明でなく、なぜ、そのような技術が必要になったか、背景が歴史と共に書かれている。
  • ある程度理解している人でも、じっくり読むと楽しめる工夫がある
  • 部分的に読んでも得るものがある
  • 良くまとめられていて重くない

ソフトウェアの開発に関わっていると担当した技術についてはわかるのですが、担当しなかった技術が抜け落ちて、全体を理解できていないことがあります。ベテランと呼ばれている人に、基本的なことを尋ねると、怪訝な顔をする人は多いのですが簡潔に説明できる人が少ないのはそのためでしょう。

今本を読んでいると、「自分だったらもう少しこの辺も説明できる」というところもあるのですが、読み進めていると著者が取捨選択してバランスをとったのだということが感じられます。

まだ読書中ですが「これ悪くないよ」とおすすめできる本だと思いました。

[TiDD] チケット駆動開発はプロセス改善!

プロセス改善と言えばCMMが登場した際のインパクトは大変なものでした。ソフトウェア組織を5段階に分類・評価すると共に、過去のソフトウェア工学の成果もそれにあわせて5段階に整理した結果は、説得力のあるものでした。その後、色々な意見が出てマトリクスモデルも出ましたが、インパクトが大きかったのはやはり5段階の分類でした。

その後、この手の分類は数多くありましたが、チケット駆動開発も分類してみましょう。

レベル1:TiDD前夜
大変ですが、開発できなくはないレベル

レベル2:TiDD開始
徐々に繰り返し作業に習熟する段階
日々の個人プロセスである、担当チケット確認、実施、チケット更新のリズムで繰り返され、習熟していきます。
プロジェクトもイテレーションごとのリリース計画、チケット登録、チケット解決、リリース、ふりかえり、が繰り返され、習熟すると共にプロセスの改善も進みます。

レベル3:プロセスの一般化と分類
ワークフローを組織文化に合うように変更します。チケットの種類によってワークフローを変更すれば、効率的に高品質なソフトウェアを開発できるようになるでしょう。また、チケットのコメントや議論の記録によって、ソースのトレーサビリティが向上します。

レベル4:見える化
チケットの見える化によって、定量的な管理が可能になります。スコープ(対象作業)を管理することでアジリティも向上します。
見える化によってコミュニケーションが活発になり、モチベーションが高まります。

レベル5:プロセスの進化
定量的な管理が可能になると、ツールの導入やツールによる自動化など、新たに試行と評価を実施しながら、プロセスを改善することができます。プロジェクトは徐々に進化していきます。

レベル5を達成しても会社の宣伝になったりはしませんが、ソフトウェア開発の喜びを取り戻すことができます。
レベルの順に成長するわけではありません。少人数のプロジェクトであっても、このような改善を一度に行える点がTiDDのすごいところだと思います。

C++にはまる、TCLにはまる

この1年で色々な経験をしましたので、ちょっとまとめておきます。

C++にはまる

かつてK&Rが母国語であった私にとっては変な言語です。変なことをする私が悪いんですけど、なんだかな~

  • 参照を渡す際に++をつけるとコンパイルエラー
まあコンパイラの都合もわかるし、結合の強さを考えると当たり前です。でも、エラーメッセージを表示する際に参照の渡せる引数すべてに&をつけて混乱させるg++は嫌いです。

  • Unsigned優先
めったに使わないからsignedが優先だと勘違いしました。条件式にあってはまりました。

  • sortで無限ループ
STLを使って並べ替えをしようと、<演算子の判定で値が同じ場合にtrueを返してはまりました。悪いのは私です。

  • gcov
便利ですよね。良い意味ではまりました。

TCLにはまる
  • 参照(左辺値)と値(右辺値)が明確で、右辺値には$が必要なのですが、結構はまります。

shとかbashと同じで好きになれません。

  • upvarで指定した引数の元の名前を指定するとリンクされている変数の名前が入っています。

まさかそんなことになっているなんて、、、

  • proc はグローバルかつ後勝ちなんですね。

やっぱりRubyが思い通りに書けて楽ですね。

ソフトウェア開発の教訓

最近思ったことです。

リスクに気づけ!(優先順位をつけよう)
こまめにチェックしろ!(作業の後には確認)
デグレも注意!(影響範囲を安易に考えない)
まねるな!考えろ!(イメージしてますか?)
力ずくでなく、後につながる方法で(無駄な努力はやめよう)

判断しても強制するな!コミットさせろ!(自主性を尊重しよう)
視野を広く!(トータルで勝て!)
怒るな!教えろ!(部下の味方になれ!)

« 2010年3月 | トップページ | 2010年6月 »