プログラマの思索

【1】下記の記事を読んで、Redmineによるチケット駆動開発はアジャイル開発の実装なのだ！と改めて認識して震えた。
下記の記事はスクラムの話なので、Redmineによるチケット駆動開発と直接関係ないけれど、考えたことを書く。
＃あくまでも感想。

塹壕より Scrum と XP

◆Scrum and XP from the Trenches v.2.2　日本語訳（PDF)ダウンロード

1.Scrumのスプリント計画はRedmineのロードマップと同じ。
どのスプリントにどのストーリーを入れるか、という話は、どのバージョンにどのチケットを入れるか、という視点に置き換えられる。
XPならイテレーション計画に相当するだろう。

2.チケットの取捨選択の基準は、スコープ、重要度、見積の三角形だ。
品質を下げることは許さない。

お客はスコープ、重要度の決定権がある。
開発者は見積の決定権がある。
品質は開発者が保証するものだが、品質を下げれば、全ての作業が泥沼にはまるから、それは条件に入れない。

見積もりがお客の意見と合わなければ、スコープや重要度を変更すると書かれている。
この意見は同意する。
チケットの取捨選択の基準は、結局、実現する機能を分割して削るか、優先順位付けして削るしかないのだと思う。

無理して開発しても、デスマーチになって、品質が下がって、そのプロジェクトは誰もコントロールできなくなる。

3.スプリント計画の長さは3週間らしい。
記事では、色々試して固定してみろ、と書かれている。

僕の感覚では、ロードマップのバージョンの期間は1週間単位にしている。
つまり、月曜から作業を始めて、金曜には結果が出るようにしている。
できるだけチケットの作業は細かくした方が、開発者は動きやすいみたい。
1週間でできなければ来週に回す。

スプリントの長さは、開発チームや工数の規模で異なってくるだろう。

4.見積もり速度の話も面白い。
これは、稼働率に相当する。

1日8時間の労働とみなしても、実際の稼働率は1日6時間のことも多い。
トラブル続出で電話対応していたら、1行のプログラムも書けずにそれだけで1日が終わる。
普通は、仕様書を読んだり、ミーティングがあったり、稼働率は落ちる。

5.Techストーリーは非機能要件のタスクで、この作業を意識している。
環境構築、ビルド作業、テストデータ作成などのタスクが相当するだろう。

これらの内部作業は、お客様には見えないけれど、開発チームにとって重要だ。
だから、この工数やコストも考慮に入れる必要がある。

6.スプリントバックログこそがRedmineのチケット変更記録だ。
つまり、ステータス＝終了となったチケットの履歴一覧。

この記録から、バーンダウンチャートを描くことは可能。
「バーンダウンチャート」とは、受入テストを通過した要求数を差し引いた未完了の残要求数を
下向きグラフ化したもの。
プロジェクトファシリテーション(PF)のツールとして頻出される。

バーンダウンチャートで進捗を見える化する

残工数で進捗を把握する意味でCCPM的発想とも言える。
つまり、後何日で開発が終わるか、バーンダウンチャートが書ければ予想できる。

Redmineにはバーンダーンチャートは存在しないが、DBにチケット情報があるからプログラムを書けば実現可能だ。

7.「今日何をするか判らない」の人の扱いが面白い。

もしそれほど重要でないのなら、チームから外すようにしよう。
もしその人物が重要なら、「導き手」役のできる誰かとペアを組ませるようにしよう。

アジャイル開発といえども厳しさはある。

8.スプリントの振り返りの話も面白い。

僕は、Redmineのチケット集計結果を連想した。
Redmineでは、トラッカー・開発者・機能別などでチケットの状態などの集計結果を見ることができるから、これを見ながら振り返りができる。
リポジトリ欄の統計を見れば、開発者ごとの月別のリビジョン・コミット回数のグラフがあるから、誰が一番貢献したか、すぐに分かる。
ソフトウェア工学の知識を有効に使って、振り返りを使えば、改善点を洗い出せる。

9.この言葉にしびれた。

継続的な設計の改善は、殆どTDDの実施による自然な副産物なんだ。

10.「多分受け入れテストフェーズは回避できない」章はロードマップ作成の要注意点だ。
「Scrumチームから提供されるコード品質の最大化」のためには、下記2点が有効だという。

10-1.テスタをScrumチームに参加させる

実際の業務シナリオに沿うから、受入テスト時は手動テストが多いし、そうならざるを得ない。
その時に、選任のテスタがいれば、プログラミングでないタスクを彼が拾ってくれる。

10-2.スプリント毎の作業を減らす
チケット駆動開発を実践すると、基本は「チケットを捨てる」のが重要になってくる。
納期は決まっているのだから、作業を優先順位づけして、最優先の作業から始めて、残りは捨てる。
実際は、優先順位の低いチケットは延期する。

全ての作業(チケット)を終了させようとすれば、納期間近になった時に一つも作業が完了できていないだろう。
優先順位の決定がない完璧主義は悲惨な結果をもたらす。

特にデスマーチプロジェクトでは、タスクが溢れてしまって、完了した作業よりも積み上がる作業の方が多いだろう。
火消し役のリーダーは、まず、各メンバーにアサインされたタスクを全て降ろして気持ちを楽にさせた後、タスクの棚卸しから始めることだろう。

チケットの状態をリアルタイムに正確に把握する所から、プロジェクト管理は始まる。

11.「スプリントサイクル VS 受け入れテストサイクル」は、チケットの取捨選択の基準の一つを示している。
つまり、新規機能の開発よりも、バグ修正を優先すること。

チケット解決の優先順位の基本パターンなのだ。

12.「どうやって複数のScrumチームをハンドルするか」「チームを特化するか…否か？」はチーム運営の観点から非常に面白い。

僕は大きなチームの不利な点を踏まえてなお、一つのチームに拘るつもりだ。

13.「コードブランチ」の章は、ソース管理のブランチモデルの話。
元ネタはここだったかもしれない。

【2】もう一つ面白い記事がある。
下記の記事は、スクラムを中国で導入して成功した例と失敗した例を分析している。

改善、成功と失敗: 中国でのスクラム導入

記事によると、スクラム導入の成功と失敗の違いは、上層部の支持があるか、そして、メンバーがスクラムの概念を理解しているか、という点。
だが、スクラム導入よりも、会社やチームに改善プロセスを生む能力があるかどうか、に鍵があるような気がする。