« 2014年9月 | トップページ | 2014年11月 »

2014年10月

2014/10/28

Redmineでコミュニケーションを非同期化する

日経ITProの記事を読んで、Redmineの利用に関して考えさせられたのでメモ。
ラフなメモ書き。
特にメッセージはない。

【元ネタ】
記者の眼 - 忙しいIT現場だからこそ“残業ゼロ”、あるプロマネが取った策とは:ITpro

【1】IT業界は残業が多い。
あるいは、正月や深夜の本番リリースによるシフト勤務、または、本番障害による夜間コールなど、勤務時間が不規則になりがち。
技術者は疲弊しがち。

生産性向上が逆に、空いた稼働率の隙間を埋めてしまう悪循環があるのだ。
例えば、プロジェクト運営をうまく回して早帰りしていると、他の火を噴いている案件から、人をよこせ、と言われて、チームのメンバーを引き抜かれて、生産性を落とす場合がよくある。

だから、日本のSIでは生産性を上げても、はかどっていないような仕事ぶりをする

【2】(2/3)記者の眼 - 忙しいIT現場だからこそ“残業ゼロ”、あるプロマネが取った策とは:ITproの記事で興味を引いたのは、下記の文章だ。

(引用開始)
 もちろん、利用部門からの問い合わせをすべて断るわけにはいかない。
そこでリーダーの大石氏が、原則すべての問い合わせに対応する。メンバーに確認が必要なときは、大石氏が課題管理ツール「Redmine」にチケットを発行。開発業務が一段落した際に、メンバーに対処してもらう。
「コミュニケーションを非同期化すれば、隙間時間を有効に活用できる」(大石氏)。
(引用終了)

チケット管理によって、コミュニケーションを非同期化する。
つまり、ペアプログラミングのように、同じ時間帯に同じ場所で対面でコミュニケーションするのではなく、チケットでワンクッションおいて、違う時間帯に違う場所でコミュニケーションするわけだ。

実際、チケット管理が有効な状況は、チームのメンバーがプロパー社員と請負契約のパートナー社員の構成のために違うフロアに物理的に離れている場合や、日本の設計チームと中国のオフショア開発チームのように地理的に離れている場合に有効だった。

物理的、地理的に離れている場合は、電話やメールでやり取りするしかないが、電話は割り込みして作業を中断させるし、メールは大量のレスで分からなくなってしまいがち。
チケットでやり取りすれば、チケットのコメントが一つのスレッドになるし、ソースやWikiへのリンクやファイルの添付も簡単だ。

また、違う時間帯にチケットでやり取りできるのもいい。
チケットのやり取りは、ペアプログラミングならぬ「ペア作業」なのだ。

実際、障害の修正と検証のやり取り、QAに対する質問と回答のやり取りは、開発者とテスター、開発者と設計者の間でチケットをキャッチボールのようにやり取りし、最後はCloseされる。
この種のやり取りは、40代の中年SEよりも20代の若手PGの方がすぐに馴染んでくれる。

【3】そんな内容を振り返ると、「Googleはコードレビューを非同期ペアプログラミングとみなしている」という過去の記事を連想した。

コードレビューは緩いペアプログラミング: プログラマの思索

コードレビューはペアプログラミングの代替手段: プログラマの思索

現代は、非同期なコミュニケーションの手法は、チケット管理だけではない。
SkypeやGoogleHangoutもあるし、チャットやFacebookメッセージ、SNSなどたくさんある。
最近なら、リモートワークに関する手法がそれに当てはまるだろう。
コミュニケーションのIT化が、逆に、ソフトウェア開発を人間化し(humanize)、チーム間の人間関係を強化してくれる。

非同期コミュニケーションの実現方法として、チケット管理にはどんな特徴があるのか、今度整理してみる。

| | コメント (0)

2014/10/26

Redmineのチケットのウォッチャー操作に関する課題

Redmineのチケットでウォッチャーを操作できるプラグインredmine_watcher_filterについてメモ。

【元ネタ】
ayweak/redmine_watcher_filter

Redmineのプラグインを作ってみる - ayweekendの日記

Redmineのプラグインを作りたくなった経緯 - ayweekendの日記

Redmineのウォッチとウォッチャー | Redmine.JP Blog

Feature #4511: Allowing to add user groups as watchers for issues - Redmine

Redmineでは、チケットを更新するタイミングで、チケット更新メールが流れる。
この機能は、チケットの更新内容を強制的にメール通知させることで、関係者にチケットを最新化させようという気持ちにさせてくれる。
チケットは、放置したり、進捗90%のままにしてはダメなのだ。
常に、チケットに作業記録を残し、別の人へ自分の手元から離すように運用すべき。

「チケット管理は、チームでチケットを消すゲーム」という感覚で作業すべきなのだ。

しかし、Redmineでチケット管理の運用が軌道に乗ると、チケット更新通知メールがうざったくなる。
1日で20通ものメールが来ると、チケット更新以外に重要なメールを見落としがちになる。

だから、メールによる通知機能では、チケットの作成者と関係する人だけに限定するように普通は運用するだろう。
Redmineチケットには、ウォッチャー機能があるので、それで代用できる。

Redmineのウォッチとウォッチャー | Redmine.JP Blog

しかし、Redmineのユーザが50人、100人と増えてくると、チケットごとに関係者をウォッチャーに選択するのは面倒になってくる。
だから、チケット作成時、更新時に、ウォッチャーを画面上で簡単に選択して編集できる機能が欲しくなる。

僕が調べたところ、現時点では、RedmineのVer2.5では、ウォッチャー機能のプラグインとしては、ayweak/redmine_watcher_filterぐらいしかないように思う。

ayweak/redmine_watcher_filterでは、チケット作成時に、ウォッチャーを、ユーザグループ、プロジェクトに属するメンバー、プロジェクトに属するメンバーのロール単位で選択できる機能を追加してくれる。
つまり、チケット作成時に、チケットに関係する人たちをウォッチャーに選択する時に、ayweak/redmine_watcher_filterプラグインを使うと便利。

ただし、ayweak/redmine_watcher_filterはチケット作成の場面だけで有効であり、チケット更新後にウォッチャーを編集するにはRedmineのデフォルト機能を使うしかない。

本来は、チケット集計画面で、チケットを右クリックで選択した時に、ウォッチャーを操作できるような機能があるとなおよい。
Ver1.xの頃は、下記のプラグインで実現できていたが、Ver2.xでは使えないようだ。

MKinsideさんはTwitterを使っています: "@akipii こらのプラグインです。Watcher Sellection by Groupと合わせて使ってます。 Redmine - Context menu watchers - Plugins http://t.co/BNe9QSC"

Context menu watchers - Plugins - Redmine

Watcher Sellection by Group - Plugins - Redmine

alvila/redmine_watchers_by_group

ウォッチャー操作の使い勝手を向上する機能改善は、以前から本家にも下記チケットであげられているようだ。

Feature #4511: Allowing to add user groups as watchers for issues - Redmine

【追記】
こんな意見もある。

OjaさんはTwitterを使っています: "ウォッチャはめんどいので、Atomやチャット/IRC連携系でどうにかできないのだろうかとはよく考える RT @akipii Redmineのチケットのウォッチャー操作に関する課題 http://t.co/1jXfbV73bn"

上記の意見の通り、ウォッチャーの機能改善が本質的な問題ではなく、チケット更新の情報共有をRedmineのどの機能(RSS、チャット、メールなど)で実現するのか、ということが本来の課題になるのだろう。

ウォッチャー機能、さらには情報共有を実現する機能については、今後も考えていく。

【追記2】
2017/1にredmine_watcher_filterプラグインが更新されて、Ver3.3.xにも対応された。
感謝。

ayweak/redmine_watcher_filter: This is a Redmine plugin. This plugin filters issue watchers and checks/unchecks them, by groups, roles and custom field values.

| | コメント (0)

2014/10/24

開発環境に関する最近の動向

開発環境に関する最近の動向について、リンクしておく。

【元ネタ1】
1分でわかるJIRAの現在と進化

夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ

KDDI Cloud Blog | アジャイル開発を支える舞台装置、最適な開発ツールを求めて

アジャイルな現場になるためのツール環境【ET West】

序盤、中盤、終盤、隙がないよねさんはTwitterを使っています: "Redmine/Jenkins とか使ってる方たちはどうやって追跡できるようにしてるのか気になる / “KDDI Cloud Blog | アジャイル開発を支える舞台装置、最適な開…” http://t.co/CQZtge6sVW #development #atlassian"

Jira+GitBucket+Stash+Bambooの製品群を見ると、Jiraチケットが起点になって、人と成果物が密接に関連付けられている。
そのおかげで、トレースするのが非常に簡単になっている。
障害の影響調査、変更理由の調査などで、Jiraのトレーサビリティが非常に役立つ。

同様の環境は、Redmine+GitLab+Jenkinsでも可能だと思う。
但し、Jiraに比べると、トレーサビリティの保証が弱いと思う。

RedmineチケットとGitのソースは相互リンクできるし、Jenkinsのビルドログからも追跡できる。
しかし、GitHubのような仕組みの実現は多分弱い。
Gitでプルリクエスト、フォーク、マージ(Pull)のイベント操作で、チケット発行やチケットCloseも自動で実現したいのだ。

RedmineをGitHub化するアイデア: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

【元ネタ2】
JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこね

インフラの継続的デリバリー - naoyaのはてなダイアリー

伊藤直也氏の記事のリンク: プログラマの思索

akipiiさんはTwitterを使っています: "テスト環境はDockerでビルド単位に作っては使い捨て。時代はこのレベルまで進んできたのか。JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこね http://t.co/x8gFT5rirk"

「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」 チャド・ファウラー氏 - Publickey

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

アジャイル DevOpsの記事: プログラマの思索

アジャイル開発を実施するための開発基盤の最新動向を抑えたいなら、最近は伊藤直也さんの言動に注目すればいいだろうと思う。
Webの記事を読むと、非常に示唆に富む内容が書かれている。

単に、GitHubを使ったアジャイル開発だけではない。
インフラ構築も自動化したり、TDD+CIをサーバーインフラ構築にも適用してしまう。

インフラの継続的デリバリー - naoyaのはてなダイアリーによれば、「DNS レコードを Pull Request を merge した契機に自動で更新」するとか、こんな所までインフラ構築はプログラミング化されているのか!と驚かされる。

「イミュータブル・インフラストラクチャ」という言葉も、伊藤直也さんのWebのどこかの記事で知ったし、インフラ構築の自動化周辺は要注目。

JenkinsとDockerでTravisっぽいCIサーバを育ててみている - オープンソースこねこねでは、さらに、テスト環境はDockerでビルド単位に作っては使い捨てしている。
ここまで進化できれば、もはや開発環境と本番環境の違いはないに等しい。
本番環境もすぐに作れるから。

本番環境が重くなったら、Dockerで新規に作ってリリースするだけでいい。
本番環境は、データ移行はのぞいて、環境が綺麗な状態から稼働できるわけだ。

以前から、クラウドやインフラ構築の技術をアジャイルな開発環境へ適用する動向にずっと着目していたが、もはや今となっては当たり前みたいだ。

さらに、伊藤直也さんのWebの記事を読むと、単にアジャイル開発を導入するだけでなく、チーム運営をオープンソースに似た活動にする考えを持っている点に興味が惹かれる。
ツールを使ってアジャイルに開発するのではなく、開発チームの組織化にも有効に使っているわけだ。
チーム内のコミュニケーションをいかに活発化し、見える化し、透明化していくか、にすごく力点を置いている。
その辺りに僕はすごく興味がある。

この辺りの動向も注目していく。

| | コメント (0)

2014/10/17

RedmineとGitLabを連携すると、RedmineをGitHub化できるか

RedmineとGitLabを連携することで、RedmineをGitHub化できるのではないか、というアイデアをメモ。

【元ネタ】
Redmine/GitLabと連携したい - Void of Knowledge

akipiiさんはTwitterを使っています: "多分Jira→Redmine、GitLab→Stash、Jenkins→Bambooに対応付けられるはず。Redmine+Git+GitLab+Jenkinsを総合的に利用した少人数チームでのプロジェクト管理のベストプラクティス http://t.co/oKsAiKfioV"

RedmineをGitHub化するアイデア: プログラマの思索

長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

【1】GitLabはGitHubを真似たオープンソースのGitリポジトリ管理ツール。
ブランチ管理やプルリクエストがすごく簡単にできる。

このGitLabとRedmineを連携できれば、RedmineをGitHub化できるのではないか。
つまり、Redmineで不足しているGit連携機能をGitLabで代替できるのではないか。
トピックブランチ、プルリクエスト、git-flowモデルをGitLabで実現し、Issue管理はRedmine、というように、使い分けて運用するのだ。

ちょうど、アトラシアンのツールが、チケット管理はJira、Git管理ツールはStashで使い分けているのと同じ。
アトラシアンのツールの例を考えると、RedmineにGit管理機能を追加して機能追加するのではなく、チケット管理とGit管理は別々のツールで実現して、相互連携した方が良いのかもしれない。

【2】但し、GitLabを使う場合に注意すべき点はいくつかある。

一つは、RedmineユーザとGitLabユーザが同一になるように設定すること。
つまり、チケット登録できるユーザとGitへコミットできるユーザは一致させた方が、運用しやすい。
できれば、Jenkinsユーザも同一にできれば、運用がより楽になる。

Redmine・Gitlab・Jenkins のログインパスワードの管理が大変になったので OAuth 化した - すえひろがりっっっっ!

2つ目は、GitLabで設定したGitリポジトリをRedmineでも閲覧できるように設定すること。
RedmineのGitリポジトリは、bareリポジトリしかサポートしていないので注意。

GitLabとRedmineを連携させる - Qiita

GitLabとRedmine連携 CentOS 6.5編

3つ目は、GitLabのIssueをRedmineのチケットで置き換えるような設定にしておくこと。
そうすれば、チケット管理はRedmineに統一できるから、Redmineの優れたワークフロー管理やチケット集計機能が使えるようになる。

Redmine/GitLabと連携したい - Void of Knowledge

GitLabとRedmineを連携してみるの巻 - アルパカDiary

色々考えてみる。


| | コメント (0)

アジャイルムーブメントの歴史のリンク

アジャイルムーブメントの歴史をリンクしておく。
ラフなメモ。

【元ネタ】
5分で分かるアジャイルムーブメントの歴史 - fkino diary(2014-10-14)

アジャイル宣言が出てもう10年以上経つ。

歴史を振り返ると、1999年がエポックメイキングだったように思える。
XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」第1版のあとがきには、1999年のOOPSLAで「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」が飛ぶように売れていた、と書かれていた。
この年からXP旋風が起きて、日本にも伝えられて、平鍋さんを中心に日本でもアジャイルコミュニティが生まれた、と認識している。

そして、アジャイル開発の理念を実現する開発プロセスはたくさん出てきたが、その中で残って、確立されたものは、スクラムとXPだけだろうと思う。

でも、FDDからパーキングロットチャート、DSDMからMoscowによる優先度付け、などのアイデアも生まれ、アジャイル開発の本流の一つの手法に混じり込んでいる。
その他の消えていったアジャイル開発プロセスも、そのアイデアや手法は、アジャイル開発の本流に統合されていったのだろう。

歴史は面白い。

| | コメント (0)

2014/10/14

RedmineをGitHub化するアイデア

RedmineをGitHub化するアイデアをラフなメモ書き。

【元ネタ】
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok

GitHub でチケット駆動開発とプルリクエスト駆動開発を併用する - mallowlabsの備忘録

はてなブログチームの開発フローとGitHub(前編)。GitHub Kaigi 2014 - Publickey

はてなブログチームの開発フローとGitHub(後編)。GitHub Kaigi 2014 - Publickey

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能: プログラマの思索

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

伊藤直也氏の記事のリンク: プログラマの思索

【1】なぜRedmineにGitHubの機能を実現したいのか?

RedmineはSVNとの連携を前提にしている。
でも、今の開発はGitHubを利用するのが当たり前。
GitHub-flowが非常に使いやすいのだ。

ちょっとしたアイデアの開発、障害修正、機能追加は、masterからfolkして、トピックブランチ上で色々試す。
出来上がったら、マージする対象のリビジョンを指定して、プルリクエストを送る。
コミッタがOKなら、masterに取り込まれる。

ブランチをいくら作っても簡単に管理できる。
いつでもブランチをマージできるのは心強い。

SVNのマージは非常にやりにくかった。
CVSはファイルごとにタグ付けしてマージしていたから、なおさらだ。

プルリクエスト駆動の開発は、動くソースを中心に開発が進むから、アジャイル開発と凄く相性が良い。
わざわざチケットを発行して、ソース変更のリビジョンを紐づけなくても、コミットログそのものがチケットのような働きをする。
チケット管理がコミットログに置き換わったような開発スタイル。

【2】Redmineに取り込みたいGitHubの機能は、フォークとプルリクエストだ。

【2-1】フォークは、No Ticket, No Mergeの運用ルールを実現する。
チケット無しにフォークできない。
ブランチにはチケットIDの情報を持たせる。

Redmineでは、RedmineプロジェクトにGitリポジトリを連携する設計思想だ。
だから、RedmineチケットにGitリポジトリを連携付ける機能はデフォルトにはない。

そこで、RedmineチケットIDをブランチ名にしてフォークを強制するプラグインを使う。
色んな実現方法があるはず。

Git+Redmineな人におすすめのフックスクリプト集 - みずぴー日記

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)

あるいは、Redmineプロジェクトとリポジトリを強制的に連携付けるプラグインがあるので、そのやり方を真似れば実現できるような気がする。
つまり、チケットを作成した後、Gitブランチを紐付けるような機能を持たせれば良いと思う。

SCM Creator (+Github) - Plugins - Redmine

RedmineとSubversion・Git・Mercurialのリポジトリ(ともに同じCentOSサーバ上)の連携(リポジトリの作成とアクセス・認証) | misty-magic.h

Redmine+SVN/Gitの環境構築 (3)|パークのソフトウエア開発者ブログ|ICT技術(Java・Android・iPhone・C・Ruby)なら株式会社パークにお任せください

[Alminium][Redmine]複数のリポジトリを作る場合の注意点 | Developers Pit

いずれの方法にしても、「チケット発行→ブランチをフォーク」という流れ。
逆に、「ブランチをフォーク→チケットを自動発行して、チケットに紐づける」流れで実装できないのか?

【2-2】プルリクエストは、No Ticket, No Mergeの運用ルールを実現する。
チケット無しでマージできない。

今の所、下記のプラグインは、ブランチをマージした時に、チケットを自動でCloseする機能を実現する。
つまり、「マージ完了→チケットを自動でClose」の流れ。
この機能は確かに素晴らしい。

mikoto20000/redmine_git_branch_hook

但し、本来のプルリクエストは、「チケット発行→パッチをチケットに添付→チケットを自動でClose」の流れではない。
「リビジョンを指定→チケットを自動発行→コミッタがマージしたらチケットを自動でClose」の流れだ。

つまり、マージしたいリビジョンを指定して、コミッタにメッセージを送信する時に、チケットが自動で発行されるのがミソだ。

気になるプラグインは、下記のプラグインだ。
「Github like pull requests plugin for redmine.」と書かれているので、それが本当なら、プルリクエストをRedmine上で実現してくれるはず。

xueqiu/redmine_pull_requests

【3】git-flowモデルは、Redmine上にどのように実現できるか?

一つのアイデアは、Redmineのマルチリポジトリ機能を使って、masterとdevelopをRedmineプロジェクトに対応づける。
そして、トピックブランチ、フィーチャブランチ、ホットフィックスブランチは、Redmineチケットに対応づける方法。

Redmine 1.4新機能紹介: 一つのプロジェクトで複数のリポジトリに対応 | Redmine.JP Blog

一方、下記の記事のように、git の base リポジトリで HEAD の向き先を変更し、masterの代わりに常にdevelopを表示させる方法。

Redmine で git を参照する際、既定ブランチを develop にする | オフィスウーム

但し、再び他から push があると HEAD の向き先が戻ってしまうので、リポジトリのフックを使ってミラーリポジトリに push すると同時に再設定させる。

この手法の利点は、masterよりもdevelopの方が開発者にとって身近であり、頻繁に使うリポジトリなのだから、developを優先して表示できること。

【4】フォークやプルリクエストの機能も、「フォーク→チケット発行」「プルリクエスト→チケット発行」「マージ(pull)→チケットClose」を実現したい。
つまり、リポジトリの操作をRedmineの画面上で行った後、勝手にチケットが自動で発行されたり、チケットが自動でCloseされる運用を実現したいのだ。
換言すれば、リポジトリの操作を実行した時に、チケット登録・Closeのフック処理を実装する必要があるわけだ。

他にも実現できる方法があるか調べてみる。

| | コメント (1)

2014/10/13

【告知】第7回redmine.tokyo勉強会を開催します~テーマはRedmine利用時のアンチパターン

2014/11/15土にredmine.tokyo第7回勉強会を開催します。

【元ネタ】
第7回勉強会 - redmine.tokyo

第7回redmine.tokyo勉強会 - PARTAKE

第7回redmine.tokyo勉強会 懇親会 (夜の部) - PARTAKE

(引用開始)
shinagawa.redmine あらため、redmine.tokyo の第7回勉強会を開催します。

Redmine利用時のアンチパターン、システム統合事例、新バージョン情報の他、LTを予定しています。

また今回、実験的にオープンディスカッション形式のセッションを行います。
申し込み時のアンケートで下記について意見を募集していますので、ぜひご回答ください。

1.Redmineをどのような用途で使っていますか。またはどのような用途で使えることを期待しますか?
2.Redmineを使ってみた上での問題点、または、これからの利用を考えるうえでの懸念点。

日時
2014/11/15(土) 13:00~

場所
東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー15F

Twitterハッシュタグ
#redmineT
(引用終了)

【1】私は、以下の内容で講演します。

タイトル:「RedmineのFAQとアンチパターン集【2014年度版】(仮)」

概要:
プログラマ上がりのプロジェクトリーダーは、チーム運営やプロジェクト運営の経験が不足しているため、Redmineのチケット駆動運営が上手くいかない状況が時々あります。
その原因の一つは、チームや案件の制約条件の違いによって、チケット管理を微妙に変えて運用することに気付かなかったこともあります。
今回は、自分の経験談を元に、チケット駆動開発のアンチパターンを説明します。

【2】講演の目的とねらい

おかげさまで、「Redmineによるタスクマネジメント実践技法」は4年経った今でも出版されています。

さかばさんはTwitterを使っています: "おかげさまで増刷(第7刷)が決定しました。累計部数は9,500部。ヒット作品まで、あと一息です。/ 小川 明彦 の Redmineによるタスクマネジメント実践技法 http://t.co/PxuwT2uFxQ"

私は、Redmineで初めてアジャイル開発を実践し、チケット駆動開発という開発プロセスを定義しようと色々模索していました。
そして、Redmineが今後発展する方向のアイデア: プログラマの思索にも書いたように、6個のテーマを今も思索しています。

【2-1】アジャイル開発への適用
【2-2】チケット駆動開発のプラクティス集 or パターン言語
【2-3】Redmine運用のアンチパターン集
【2-4】Redmineの運用パターン集
【2-5】開発基盤としてのRedmine
【2-6】メトリクス収集ツールとしてのRedmine

今回の勉強会の発表テーマは、【2-3】Redmine運用のアンチパターン集の続きです。
2011年に第1回RxTStudy勉強会で発表した時は、「空っぽのロードマップ」「停滞したチケット」「工程単位のバージョン」などのように、Redmineを入れたのにアジャイル開発の良さを発揮できないアンチパターンを紹介しました。

当時の発表資料「RedmineのFAQとアンチパターン集」はいつの間にか、5万ビューを超えるスライドになってました。
おそらく、紹介したアンチパターンは、皆さんの琴線に触れる場面があったのでしょう。

一方、2014年の第7回redmine.tokyo勉強会では、以前はアジャイル開発の観点を中心に据えたのに対し、今回はチームの規模や案件の種類の観点での失敗事例を集めてみました。
具体的には、以下の観点で、自分の経験談を含めて、アンチパターンを紹介したと思います。

・5人の小規模チーム x 20人の複数チーム
・自社開発 x オフショア開発
・大規模な受託開発案件 x 小規模な保守案件

| | コメント (0)

2014/10/12

ウォーターフォールとアジャイルを例えた絵が分かりやすい

ウォーターフォールとアジャイルを例えた絵が分かりやすいのでメモ。

yuki_omoriさんはTwitterを使っています: "このイメージ。 "@akipii: 良い絵。RT @tw_teria: ウォーターフォールとアジャイルの分かりやすい例え http://t.co/zFS6Xvz6A2""

最終的なゴールが見えていないソフトウェア開発では、アジャイル開発が向く。
WF型開発では、計画段階で、システムのあるべき姿を詳細な部分まで見通すのは難しい。

試行錯誤しながら、顧客と新製品を開発する感覚でソフトウェア開発していく時に、アジャイル開発は向く。
誰も正解を知らないのだ。

そんなことを思うと、倉貫さんの「納品のない受託開発」は、まさにそんなマーケットを意識して、アジャイル開発を実践されているのだろうと思う。

| | コメント (0)

長沢さんの「モダンなチーム開発環境のフリー利用可能な資料」が素晴らしい~プルリクエストはJiraにあってRedmineにない機能

長沢さんのモダンなチーム開発環境のフリー利用可能な資料が素晴らしいと思った。
長沢さんのJira資料を読むと、RedmineよりもJiraの方がチケット管理の環境が一歩進んでいる印象を持った。
その理由を書いてみる。

【元ネタ】
モダンなチーム開発環境のフリー利用可能な資料を公開

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

GreenHopper を使用した Bamboo と Bitbucket の自動化 | Atlassian Japan

Stash 3.3: タスク機能を利用してプルリクエストの進捗状況を追跡 | Atlassian Japan

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

【1】JiraでもRedmineでもチケット管理の手法は同じだし、SVNやGitのような構成管理ツールとチケットを連携する機能も手法も同じ。
しかし、JiraがRedmineよりも優れている点は、Git連携の機能強化の部分にあると思う。

換言すれば、Gitからのブランチ派生、Gitのmasterへプルリクエストする機能が、JiraはRedmineよりも優れていると言える。

Jiraでは、Git上でトピックブランチを作ると、チケット画面にブランチのリンクが作られる。
例えば、障害修正やちょっとした仕様変更が発生したら、トピックブランチを派生させるが、そのトピックブランチがチケットに自動で連動されている。
つまり、トピックブランチを派生させるタイミングで、チケットへブランチにリンクする機能をフックしているわけだ。

Jiraのチケット画面を見ると、ステータスが「提案済み」「オープン」では「ブランチを作成」リンクがあるので、チケット画面上でワンクリックでトピックブランチを関連付けることができる。
つまり、「No Ticket, No fork」の運用が、Jiraではチケットの一機能に含まれているので、開発者にトピックブランチの運用を強制できるし、開発プロセスを標準化することもできる。

この運用は、「No Ticket, No fork」に相当する。
すなわち、トピックブランチは必ずチケットにリンクさせて、相互追跡可能にする。
この機能と運用の利点は、トピックブランチの修正が全てチケットに記録されること。
「No Ticket, No Work」の運用のGitブランチ版と言える。

【1-1】但し、Redmineのデフォルト機能には、「No Ticket, No fork」をサポートする機能はない。
そこで、RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインを使うのが良いだろうと思う。

mikoto20000/redmine_git_branch_hook

redmine_git_branch_hookプラグインを使えば、チケットIDに対応付けたトピックブランチを自動生成してくれるから、「No Ticket, No fork」をRedmineの一機能に実現できる。
しかし、Redmineチケットにブランチのリンクを貼ってくれる機能はない。
その点は残念だ。

【2】そして、ブランチを作成後、Jiraチケットのステータスが「進行中」ならば、「1個のブランチ」というリンクが表示される。
また、トピックブランチ上の修正は、自動でチケットに記録され、「1件のコミット」というコミットログが残る。

つまり、チケットのコメント履歴とブランチのコミット履歴は、「No Ticket, No Commit」の運用ルールによって、相互リンクされている。
この運用によって、なぜこんなIF文の多い修正をしたのか、なぜこんなパッチを作ったのか、という変更理由や本来の要件を追跡できるようになり、その後の機能追加や障害修正で役立つ。

この部分は、Redmineならば、コミットログに「refs #12」のように書く運用を義務付ける必要がある。
できれば、Redmineでも、チケット番号をコミットログに書く運用をしなくても、自動でチケットにリビジョンが紐づけられるような機能があればよい。
Jiraでは、そのような機能が実現されているのだから。

【3】また、Jiraチケットでは、ビルドが終了して通過できれば「1件のビルド」という履歴が残る。
Jiraでは、Bambooというビルド管理ツールを組合せて実行するようだ。

この機能は、Redmineなら、Hudson Pluginで実現できるだろう。
Hudson Pluginを使えば、チケット履歴にビルド履歴が表示され、ビルド番号とチケットを紐付けることができる。
また、チケット欄に、ビルド成功・ビルド失敗も表示されるので、ビルド失敗ならば、すぐに対処するような運用を課しても良い。

Hudson - r-labs

【4】さらに、Jiraのトピックブランチ上で修正が終わり、masterへマージしたい時、プルリクエストを送ることができる。
Jiraでは、プルリクエストを送ると、Stashというコードレビューツールでコードレビューが行われ、それがOKなら、masterにマージされるという運用になっているようだ。
つまり、プルリクエストは必ずコミッタまたはライブラリアンのレビューを通過するという運用が、ツール上で実現されている。

Jiraチケットでは、ステータスが「レビュー中」にプルリクエストを送ると、「1件のプルリクエスト」というリンクが貼られる。

但し、僕がまだ理解できていない部分は、Jiraのプルリクエスト機能はJiraのどの画面から送信するのか?、ということだ。
おそらく、Gitのトピックブランチへコミットした後、プルリクエスト対象のリビジョンを指定した時に、プルリクエストのボタンがGitリポジトリ画面にひょうじされるのではないか、と想像する。
つまり、GitのCherry-pickによるマージ作業を実施している時に、プルリクエストを送信できるようにしているのだろう。

そうすれば、Git画面上でプルリクエストを送ると、Jiraチケット画面に「1件のプルリクエスト」リンクを表示するような機能がフックされる仕組みを実現すればいい。

そのプルリクエストが承認されて、検証環境へデプロイされれば、Jiraチケットのステータスは「解決済み」へ変わる。
最終的に本番環境へデプロイされれば、Jiraチケットは「完了」ステータスになる。

この運用は、「No Ticket, No Merge」と呼ばれる。
つまり、プルリクエストを送り、そのプルリクエストが承認されれば、マージされてチケットもCloseする運用だ。
Jiraが優れている部分は、プルリクエスト機能を持ち、プルリクエストが承認されるタイミングで、チケットのステータスが自動的に変更される機能を持つことだ。

【4-1】しかし、Redmineでは残念ながら、「No Ticket, No Merge」はデフォルトの機能では実現されていない。
但し、RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索にも書いたが、Redmineでは、redmine_git_branch_hookプラグインが、プルリクエスト相当に似た機能を持っている。

かんばん!~もし女子高生がRedmineでスクラム開発をしたら(6):Redmine×Gitのハーモニーは涙のチケット駆動開発!? (3/3) - @ITにも、その運用方法が一部記載されている。

mikoto20000/redmine_git_branch_hook

redmine_git_branch_hookでは、チケットIDを含むトピックブランチをマージした時に、自動的にチケットをクローズする機能を持つ。
つまり、マージするタイミングで、チケットのステータスを「解決」または「完了」へフックして自動で変更してくれる。

だが、これは「プルリクエストに似た機能」としか言えない。
コミッタまたはライブラリアンがプルリクエストを受け付けて、承認するかReject(差し戻し)するか、という機能は実現されていない。
本来なら、この部分もRedmineで実現されるべきだ。

本来のプルリクエストは、「リビジョン指定→チケットの自動発行」であり、「チケット発行→リビジョンを指定してパッチを添付」の流れではないのだ。
残念だが、redmine_git_branch_hookプラグインは、「リビジョン指定→チケットの自動発行」まで実現してはいない。

【5】以上のように、JiraとRedmineのGit連携の機能を比較すると、Jiraの方が優れている機能がある。
なぜ、このようにチケット管理ツールのGit連携に力を注ぐべきなのか?

その理由は、モダンなチーム開発環境のフリー利用可能な資料を公開で長沢さんが書かれている。

換言すれば、最大の利点は、チケットと構成管理配下のソースのコミット履歴を連携することで、トレーサビリティを完全に実現することだ。

(引用開始)
したがって、ウォーターフォールだからとか、アジャイルだからとかではなく、追跡可能性が常に維持されている環境にしたいわけですが、そのためには、開発者をはじめとしたチームメンバーにかなりの負担を強いることになります。それこそ、本業よりも、情報収集や更新作業に費やさなければならないくらいに。
ただし、これをやっておかないと、バグ1件ですら満足に対応できない事態にすぐに陥ります。なので、よりよい開発環境にすることはとても重要になってきています。
(引用終了)

WF型開発でも、設計書とソースのトレーサビリティを重視する動きは過去も今もあるが、普通は、Excelの設計書の変更履歴や、Excelのリリース管理台帳で管理しがちだ。
それでは、過去の履歴を検索したり、調査するのに、Excelの山から逐一検索する手間がかかる。
また、ソースや設計書は頻繁に修正するから、トレーサビリティを維持するために、Excelの設計書や管理台帳を保守するコストもかなり大きい。
変更履歴の入力ミスは結構あるし、修正履歴やリリース履歴が多くなるほど、保守が面倒になって、最終的に誰も保守しなくなる。

アジャイル開発では、開発環境をツールでできるだけ自動化し、成果物の構成管理やトレーサビリティをツールで実現する方向へ進化している。
そして、TracやRedmineから生まれたチケット駆動開発は、「No Ticket, No Commit」の運用ルールによって、成果物とソースのトレーサビリティを自然に運用できる開発基盤を提供した。

【6】しかし、TracやRedmineは、Subversionを前提としているため、Gitのようなブランチ管理とマージ方法とチケット管理ツールを連携する機能が貧弱だ。
つまり、トピックブランチのように一時的に生成され、その修正パッチをプルリクエストで送り、コミッタの承認を得るという仕組みが、RedmineやTracでは実現されていない。

したがって、GitHubで皆が普通に使っているプルリクエストがRedmineで使えない現状があるために、Redmineが最近の開発環境の進化から遅れているようにも見受けられる。
ただし、JiraはGit連携を強化しているように思える。

そもそも現代の開発では、プログラマはGitで構成管理するのが普通であり、タスクをチケット管理するのも普通だ。
なのに、RedmineではGitとうまく連携できていない課題がある。

「nanapi勉強会 vol4」に参加してきました - 勉強会ログ

akipiiさんはTwitterを使っています: "最近の開発プロセス事情がすごく参考になる。RedmineやJenkinsはもう古いのかもしれない。「nanapi勉強会 vol4」に参加してきました - 勉強会ログ http://t.co/ckXqVEUFBU"

DQNEOさんはTwitterを使っています: "@akipii 非エンジニアが多い環境だと、Redmineは充分有効だと感じています。Githubと併用した場合に、Redmine issueとGithub PRどうやって紐づけるかが悩み。"

akipiiさんはTwitterを使っています: "@DQNEO ご指摘の通り、RedmineでもGitHubやJiraのように、チケットにブランチのリンクを付けて、プルリクエストをRedmineのUI上で操作できるようにすべきだと思います。Redmineをもっとアジャイルな開発環境にしたいんですよね。"

RedmineのGit連携の機能強化はどのように実装すべきなのか、どのように運用すべきなのか、という課題は、今後も考えていく、

AgileTourOsaka2014に参加してきた。
テーマは「パタン特集」。
パターン言語とは何か、現場の経験知をパターン言語にするコツが分かった。
とても有意義な勉強会だった。
ラフなメモ書き。

【元ネタ】
10月11日 AgileTourOsaka2014

Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しました

AgileTourOsaka2014 #agileto2014 のまとめ - Togetterまとめ

KenColle/AutomationPatternLanguage

パターンを使うもう一つの動機~パターン言語の構築よりも設計・実装・運用のノウハウをカタログ化する: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集: プログラマの思索

チケット駆動開発のナビゲーションマップ #Redmine: プログラマの思索

以下、勉強会のログを書いておく。

【1】パターン名は解決策である。
名前は体を表す。
パターン名が解決策とその問題を連想させるのが良いパターン。
パターン名からピンとこなければ、良いパターンとはいえない。
解決策をパターンの名前にする。
パターン名から、すぐに行動を起こせるかどうか。

懸田さんのワークショップでは、いかにダイエットして健康的な生活にするか、というテーマでパターン言語にする話。
各チームでパターンを作ってみると、「エクストリーム通勤」などメッセージ性はあるが、だからどう行動するのか、分かりにくいパターンが多かった。

【2】アンチパターンは状態を表す。
アンチパターン名は、問題を表す。
解決策ではないから、アンチパターンはパターンではない。

アンチパターンは、パターンの結果文脈に含まれるべきもの。
つまり、パターンを適用した結果、フォース(力の衝突、利害関係者からの圧力の衝突)は解決されたが、その結果が良い場合もあれば、予期しない副作用やリスクが出てくる時もある。
その時にアンチパターンが出てくるだろう。
例えば、パターン病の人のように、何でもかんでもパターンを適用してみたら失敗した、という時もアンチパターンに含まれるだろう。

例えば、テスト自動化パターン言語では、パターンとアンチパターンが関係付けられていたが、本来はアンチパターンは必要ない。
アンチパターンは、パターンの結果文脈の一つにすぎないから。

【3】フォースとは、力の衝突。
パターンは、利害関係者の力の衝突を解決するのではなく、「力の衝突をいなす」だけ。
パターンを適用した結果、良い結果になる時もあれば、副作用が起きて別のリスクや課題が出てくる時もある。

その時は、別のパターンを当てていく。
パターンは、現状をいきなり変えるのではなく、漸進的に変えていく。

【4】パターンはスケールしていく。
パターンはツリー構造ではない。
セミラティス構造、つまりネットワーク構造。
地形、建物、オブジェ等の場をネットワーク構造でパターンをつなげる。

スケールとは、パターンの一種のカテゴリ(?)

例えば、アレクサンダーの建築パターンは、大中小の3種類のスケール。
大:地形、環境、場所
中:出来事、行動、習慣
小:道具、ツール

例えば、デザインパターンのスケールは、生成・構造・振る舞いの3種類。

スケールには2種類ある。
時系列という横軸、利害関係者の人数という縦軸。

時系列にパターンを関連付けると、シーケンスのパターンになる。
例えば、テスト自動化のパターン言語がその例。
自動化開始→自動化導入→普及・終焉という時系列でパターンを関連付けているので、すごく理解しやすい。

では、テスト自動化パターンでは、スケールを成熟度別にできないか?
CMMIみたいに。
例えば、あるパターンを適用してアンチパターンが出たならば、それはレベル1。
そのアンチパターンを乗り越えたら、レベル2のように、成熟度別にできないか?

スケールは一つだけではうまくいかない。
幾つかのスケールを組合せると良くなる。
例えば、XPがまさにそう。
XPの12個のプラクティス単体では、品質や効率化について何も触れていないが、それらのプラクティスを全て実行すると、初めて、高品質で効率の良い開発が生まれる。(生成される)

例えば、スクラムパターンは組織パターンの一種。
スクラムパターンでは、スケールを時系列(リリース>スプリント>デイリー)でも分けるが、利害関係者の規模でも分けている。

EnterpriseArchitectureは、ツリー構造かつ階層化しているが、失敗した。
ビジネス向けシステムをアーキテクチャをビジネス・情報・アプリケーション・データに階層化したが、階層のつながりや組合せの方法が具体的に書かれていないので、苦労している。

【5】パターンは、最重要な基本的なパターンからスケールの単位で派生していく。
基本的なパターンは「センター」と呼ばれる。

例えば、組織パターンでは、「信頼された共同体」を起点として、他のパターンが派生していく。
例えば、「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」では、「エバンジェリスト」を起点として、他のパターンが派生する。

例えば、リーンスタートアップでは、MVPを中心に、プロダクトを洗練させていく。
途中で、ピボットで方針を変えたり、Build→Measure→Learnでプロダクトを進化させていく。

【6】パターン言語とは、関係者で紡ぎ合う物語。
基本的なパターンから派生したパターンを関連付けて、絵日記にしてストーリー化すると、パターン言語になる。

いつ、どこで、誰が、どんな問題を抱えていて、パターンを適用して、解決して、どんな結果になったのか。
絵日記というストーリーに、パターンが言語として自然に組み込まれる。

例えば、「ドメイン駆動設計」では「ユビキタス言語」パターンでは、「声に出してモデリングする」という解説がある。
ドメインをチームの言語とするには、モデリングした結果を声に出して、チーム全員で情報共有して理解できるまで、噛み砕く。

【7】プロジェクト・ランゲージは、場に適した実現可能な戦略。
パターン言語をあるドメインに適用した戦略。
具体的なプロジェクトに、パターン言語を適用し、パターンがドメイン特有の文脈やフォース、問題に適用できるか、検証し、その結果をパターン言語にフィードバックし、洗練させていく。

例えば、ソフトウェア開発のそれぞれの現場に対し、一つのストーリーであるパターン言語を適用してみて、その現場特有のドメインに適用できるようにパターン言語を改善していく。
その結果をパターン言語へフィードバックし、パターン言語を洗練させていく。

パターンは仮説。
パターンは実現したいイメージ。

パターン言語やプロジェクト・ランゲージを評価検証する時、その評価基準は、感情をモノサシにする。
パターンを適用した結果、楽しいですか?
パターンは、そのコンテキストやフォースにしっくりきますか?
パターンを適用した結果、なぜそう感じるのか?

最終的には、QWAN(無名の質)につながる。

【7-1】パターンは成長すべき。
アレクサンダーのパターン言語は「A Pattern Language」。
つまり、不変なパターン言語ではなく、アレクサンダー個人が見つけたパターン言語。
皆のパターン言語を集めて、洗練させて、一つの体系にできれば「The Pattern Language」になる。

俺のパターンが皆のパターンへ変わる。
だから、皆も自身でパターンを作ってみよう。

アレクサンダーの建築パターンは、「人の集まる場所」に注目している。
人が集まれば、コミュニケーションが生まれ、コミュニティが形成されていく。
コミュニティという場で、住民が自分たちの街を少しずつ漸進的に改善していく。

【7-2】小林さんの話。
伊丹市内を散策した時、鉄の柵と竹の柵があった。
どちらのほうが良いのか?
普通は、竹の柵は壊れやすく、鉄の柵の方が長持ちするから、鉄の柵の方が良い。

しかし、鉄の柵は、業者に頼まないと修理できない。
一方、竹の柵は住民が修理しやすい。
住民が竹を取ってきて、すぐに自身で改善できる。

良いパターンは当たり前な概念。
でも、言葉になっていない。
だから、パターンは暗黙知を見える化する。

【8】XPは場の設計を重視している。
「朝会(デイリースタンドアップ)」は組織パターンから出てきた。

XPは全体を重視している。
技術だけのプラクティスでは不足。
コミュニケーションだけのプラクティスでも不足。

XPは比較的広い観点で作られた、プロセスのパターン言語。
プラクティスを分離して、単体だけでは考えられない。

パターン指向リファクタリングは、パターン病という病気も生み出した。
リファクタリングにデザインパターンを適用しなければならない、というバイアスがかかった。

パターンはフォースをいなすだけ。
フォースを変えない。

アジャイルプラクティスはパターン言語か?
アジャイルコミュニティはパターンコミュニティの人達から生まれた経緯を考えれば、多分Yes。

【9】「パターンが生成的である」とはどういう意味か?

例えば、XPやアジャイルのプラクティスがそう。
技術的なプラクティスやコミュニケーション、チームビルディング、ファシリティに関するプラクティスを全て実践した結果、高品質で短納期の製品が作れる。
単体のプラクティスだけでは、品質や納期、効率化の効果は現れない。

XPのプラクティスはカッコイイ。
パターン名にメッセージ性がある。

例えば、「ドメイン駆動設計」の「ブレイクスルー」が、パターンが生成的になった結果のタイミングに相当するだろう。
つまり、モデルのあるべき姿は分からないが、モデルを綺麗にして分かりやすくしたい、という気持ちを持ってリファクタリングし続けると、ある時点で、急にモデルの見通しが良くなる。
それがブレイクスルー。

【10】自分の経験から、パターンにできるか?
パターンにするには、同じような状況で、3回パターンを適用して経験しているか?

繰返し性からパターンが生まれる。

パターンは難しい。
自分で、しょぼいパターンを書いて初めて分かった、と。

だから、シェパーディングで、ペアになってパターンを書いて評価してもらうと良い。
レビューアとレビューイの役割と同じ。
パターンのフィードバックをしてくれる。
構造的に見てくれる。
状況が分からない、フォースが分かりにくい、など、的確なアドバイスがもらえる。

【11】僕の感想:

たくさん刺激を受けた勉強会だった。
チケット駆動のパターンを未完成にしたからテスト自動化のパターン言語を見た時はやられたと思った笑。

テスト自動化のパターン言語は、ちゃんと時系列に関連付けられて、時系列の観点のスケールで区別されている。
また、一つのストーリーで、パターンやアンチパターンが語られている。

そういうストーリーを聞くと、そうそう、テスト自動化ではそんな落とし穴があるよね、せっかく自動化を頑張ったのにいつの間にか保守されなくなるよね、など、共感できる。
正直、すごいなーと思った。

KenColle/AutomationPatternLanguage

過去に僕が書いたチケット駆動のパターン言語は以下の通り。
テスト自動化パターン言語に比べれば、ナビゲーションマップまでストーリー化できておらず、中途半端だ。
まだアイデア段階にすぎない。

チケット駆動のプラクティスをナビゲーションマップに試しに書いてみたが、ストーリー化できておらず、パターン言語にはなっていない。

それが今後の課題。
チケット駆動のプラクティスもパターン言語で体系化して、広めたい。
アジャイルの現場、WF型開発の現場、大規模な受託案件の現場、小規模な保守案件の現場、など、色んなプロジェクトランゲージを作り、最終的なパターン言語としてストーリーを作り、皆が暗黙知として認識しているプラクティスを明示したいのだ。

【追記】
Agile Tour Osaka 2014でパタン・ランゲージのワークショップを担当しましたの記事の一節をメモ。

(引用開始)
日本におけるパタン・ランゲージの第二次隆盛がきている?

私のワークショップ後に、@Posauneさんがテスト自動化のパターンランゲージの発表されていました。

この発表を聞いていて感じたのは、自分達でパタンをまとめ、Githubに置いてフィードバックをもらえるようにして、どんどんコラボレーションし改善していく、これこそまさに、数年前から構想していて(未だ心が折れてできていない)現場パタン構想(GembaPLoP)のひとつの現れなのかしれない、ということです。

他にもチケット駆動のパタン・ランゲージを@akipiiさんがまとめているという話も聞きました。
(引用終了)

懸田さんの別資料もリンクしておく。


| | コメント (0)

2014/10/10

TestLinkの資料リンク

オープンソースのテスト管理ツールTestLinkの資料をまとめておく。

【1】TestLinkの使い方

TestLinkの機能や画面の使い方はコチラ。
慣れるまでに、コツがいる。
画面操作は、iPhoneやRedmineなどに比べると、あまりイケテない。
但し、オープンソースなので、皆で修正すればいいと思う。

【2】TestLinkをアジャイル開発へ適用した事例紹介

ETWest2009で発表した事例。
個人的には、TestLinkを使って初めて、漸進的開発(小規模リリース)と反復型開発の違いを体感できた。

【3】TestLinkのプラクティス

SEA関西で発表した資料。
TestLinkは単なるテストケース管理ツールではなく、テスト管理手法のベストプラクティスが含まれていると思う。

【4】TestLinkにExcelのテストケースをインポートする方法

テスト管理では、必要悪だが、どうしてもExcelのテストケースと同期する必要がある。
Excelでテストケースを作りこんでおき、そのExcelをTestLinkへ一括インポートできれば、運用がすごく楽になる。
なぜなら、ちょっとしたシステムでもテストケース数は数千~数万くらいは作る必要があるからだ。

Ver1.7までは、有志が作ったExcelマクロを使うしか無かったが、Ver1.8以降は、TestLinkのインポート機能が使えるようだ。

| | コメント (0)

2014/10/09

「アジャイルなオフショア開発」の資料リンク

「アジャイルなオフショア開発」の資料が素晴らしいので、リンクしておく。

個人的な経験では、オフショア開発が楽しかった、とか、案件として成功できた、という記憶があまりない。
ブリッジSEの善し悪し、日本側では手配師だけでオフショア側にプログラマを用意するという開発体制など、正直、あまり良い印象はなかった。

でも、オフショア開発は、昨今のリモートワークの流れの中で再評価されている気もする。
オフショア開発の魅力は、日本のPG単価に比べると1/4~1/10まで安いことだろう。
オフショア開発のプロジェクトマネジメントさえ上手くいけば、コストメリットが効く。

しかし、製造業がオフショアで工場を操業することと、ソフトウェア開発部隊をオフショアに置いて開発するのはやっぱり質が違うと思う。

そんな中でも、オフショア開発にアジャイル開発を取り入れて、開発プロセスを改善していく事例は非常に興味深い。

上記の資料で興味深かったのは、インドの話。
インドは、世界的に見れば最大のオフショア開発先。
上流工程の知識、実績が豊富。
英語での対応が可能。
優秀なエンジニアの確保が難しい。
そして、「世界標準の開発手法(日本の開発手法と異なる)」の部分がすごく気になる。

日本の開発手法は製造業のプロセスを真似たWF型開発だろうが、世界標準の開発手法とは一体何なのか?
日本の開発手法は独特すぎて、逆に世界標準から遅れているのだろうか?
ちょっと気になる。

| | コメント (0)

@kawakawaさんの「C#実装から見るDDD」資料が素晴らしい #dddosaka

@kawakawaさんの「C#実装から見るDDD」資料が素晴らしいのでメモ。

レイヤ化アーキテクチャ、責務のレイヤ、値オブジェクト、エンティティ、リポジトリのプラクティスについて、ソースを交えながら、分かりやすく説明してくれている。
やっぱり、ソースを見るとなるほど、と思う。

僕もDDD@大阪勉強会で、仕様クラスやサービスクラスの使い方を知り、改めてDDDの奥深さを感じた。
後藤さんが言うように「ドメイン駆動設計は、オブジェクトからメソッドを引き剥がすのですよ」という言葉を思い出させる。

他に、@kawakawaさんが絶賛されていた増田さんの資料も載せておく。
とても分かりやすい。

かわべ たくやさんはTwitterを使っています: "ドメイン駆動設計Before/Afterの写真が凄く判り易い。端的に違いを表現してる!  / 私がドメイン駆動設計をやる理由 #domaindrivendesign #ドメイン駆動設計 http://t.co/gJGXWifvjU @SlideShareさんから"

| | コメント (0)

2014/10/08

ワークフロー改善はBPRと同じ

官公庁の業務システム改革に関するCIOの話と、Redmineによるプロセス改善の話が妙に似ているなあ、と思ったのでメモ。

【参考】
「わからないからわかるようにしてくれ」:日経ビジネスオンライン

syotaroさんはTwitterを使っています: "redmineによるプロジェクト管理で実現しようとしているのは、ただの業務効率化ではなく、企業のワークフロー定義なんだよなぁ。ワークフローが定まっていないスタートアップでは、ここの取り組みがすごい重要なんだと思っている。"

BPRとは 〔 ビジネスプロセス・リエンジニアリング 〕 【 Business Process Re-engineering 】 - 意味/解説/説明/定義 : IT用語辞典

【1】官公庁や大企業の業務システムは、とにかく業務が複雑だ。
過去のしがらみ、法律、社内の歴史で蓄積されたノウハウや膿がたくさん積もり積もって、現在の業務が出来上がり、その業務を実現するようにIT化しただけのシステムが多い。
すると、何故こんなに複雑なワークフローや画面項目、帳票を増やしているのだろう?と思う時が多い。

業務をIT化する場合、今ある業務をそのままコンピュータに載せるわけではなく、業務フローの改善も実は含まれている。
IT化によって、無駄な作業が自動化され、必要な担当者が減るからだ。
すると、不要な担当者のいる組織の仕事がなくなり、組織構造をスリム化するような影響を与える。
最終的には、IT化は、業務の変革を通じて、組織の改革までやり通さなければ、意味が無い。
これが、BPRになる。

しかし、日本の企業も官公庁も現場が強いので、IT化で人減らしになったとしても、組織構造はそう変わらない。
看板だけ変えただけで、組織構造がスリム化しない場合が多い。
だから、IT化によって、逆に紙の帳票が増えたり、ワークフローが逆に煩雑になったり、業務システムを回すために人出が逆に増えたりすることもある。
本末転倒だ。
笑ってしまうようだが、実際の現場ではよくあることだ。

しかも、官公庁も大企業も予算で動く。
予算が確保されないと、業務システムの開発が始まらない。
普通は1~3月にかけて、来年度の予算枠が確定し、4~5月に実行稟議があって、6~7月にようやく予算を使ったシステム開発が行われる。
すると、受託システム開発を1年の枠で提案したのに、実は9ヶ月で実施しなければならない、といった本末転倒な事態になりやすい。

日本人は変な所で几帳面すぎるので、融通が利かない。
皆おかしいと思いながらも、仕方ない、と思って、従来のまま仕事している人が非常に多い。

本来は、IT化によって、業務を効率化し、抜本的に見なおし、組織構造も変えていくべきなのだ。
業務システム開発は最終的には、BPRの課題が含まれていなければ、システム化の効果が出ない。

【2】Redmineでチケット管理していると、ワークフローやカスタムフィールドがどんどん増えていく。
最初は1つのチームで運用すればよかったから、シンプルなワークフローで十分。
しかし、他チームもRedmineを使ってみたい、と言い出して、Redmineの運用が拡大していくと、他チームのやり方を反映したワークフローやカスタムフィールドが増えていく。

トラッカー名が違うだけで、ワークフローもチケット項目も一緒なのに、何故、そんなにトラッカーを増やすのか?
そんなにたくさんのステータスを増やして、ワークフローをスタンプラリーにして、本当に回るのか?
そんなにたくさんのカスタムフィールドを増やしても、どうせチケット集計しないくせに、何故増やすのか?
入力が大変になるだけなのに。

IT化は、従来のワークフロー、つまり開発プロセスの変革を伴う。
従来の開発プロセスが見える化されるのは良いが、それをそのままRedmineに実現するだけでは、BPRにはならない。
Redmineにおける開発プロセスのあるべき姿を実現しなければ、既存のAsIsの開発プロセスをそのままRedmineに乗せただけで、抜本的な改革にはならない。
本来は、思い切って、従来の開発プロセスを廃止したり、既にRedmineで定義されているワークフローに、PLもSEもPGも合わせるべきなのだ。

とは言え、そういうノウハウは、実際にRedmineで試行錯誤しなければ、実感できないだろう。

僕も、過去6年間、あちこちの現場にRedmineを作っては、運用を他の人に譲り渡し、Redmineにはまって、Redmineを使いこなすことでどんどんプロジェクト管理能力を上げていくプロジェクトリーダーを見てきた。
一方、ワークフローやカスタムフィールドが野放しに増えていき、後で収拾がつかなくなるようなRedmineも見てきた。

だからこそ、今になって思うのは、自分の中で、Redmineの運用のあるべき姿を持つことが一番大切だと思う。
そして、そのイメージを周囲の人達に問いかけて、普及すべきだと思う。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」にあるエヴァンジェリストのような役割で、どんどん広げていくべきだと思う。

僕の中では、Redmineによるチケット駆動開発を通じて、完全チケット方式によるアジャイル開発に移行すべきだ、と思っている。

| | コメント (0)

2014/10/04

プロダクトマネージャに必要なスキルは何か?~「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法」の感想

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」を買って読んだ。
プロダクトマネージャに必要なスキルが書かれている気がした。
感想をメモ書き。

【参考】
『世界で闘うプロダクトマネジャーになるための本』8月22日発売です。:シロクマ日報:ITmedia オルタナティブ・ブログ

【1】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」は、アメリカのシリコンバレーで、プロダクトマネージャとして働きたい人に対し、採用ノウハウを提示する本だ。
Google、Apple、Amazon、Microsoft、Facebook、Yahooのような大手IT企業がどんなプ資質のロダクトマネージャを求めているのか、という裏事情がよく分かる。

少なくとも、世界の最先端の企業では、受託開発案件のプロジェクトリーダーではなく、世界の最先端のソフトウェア製品を生み出すためのプロダクトマネージャを必要としているわけだ。
だから、日本でこのノウハウがすぐに使えるかどうかは分からない。

【2】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」の目次を見れば分かるが、後半では、履歴書の書き方、転職の面接で受けるであろう質問について詳細に書かれている。
面接の質問の種類として、プロダクトマネージャに必要とされる行動、見積り、プロダクト、ケース(事例)だけでなく、コーディングに関する質問もあるのが面白い。

コーディングに関する質問では、計算量やアルゴリズムに関する内容が多い。
おそらく、ビッグデータによる分析の実現方法の能力を問われているのだろう。
練習問題があるので、解いてみると面白いかもしれない。

【3】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」を読むと、「採用基準」や「ビジネスリーダーへの キャリアを考える技術・つくる技術」の内容を連想させる。

採用基準」では、日本人がグローバルリーダーになるにはどんなスキルが必要なのか、を提示していた。
ビジネスリーダーへの キャリアを考える技術・つくる技術」では、若手社員が管理職や経営者にステップアップするにはどんなスキルが必要なのか、マネジメントの断層を提示していた。

では、「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」は何を提示しているのか?
世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」では、プロダクトマネージャに必要なスキルは何か、を提示している。
注意すべき点は、プロダクトマネージャ≠プロジェクトマネージャだ。
受託開発案件のプロジェクトリーダーに求められる能力とは完全に一致しない。

実際、「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」の第2章「プロダクトマネージャの役割」では「プロダクトマネジメントに対する誤解」として、「プロダクトマネージャはプロジェクトリーダーである」という説明がある。

プロダクトマネージャの職務は「チームが優れたプロダクトを出荷できるようにする」ことだ。
簡単に言えば、「プロダクトのミニCEO」だ。
つまり、プロダクトのビジョンと戦略、ロードマップを提示し、チームに対する直接的な権限も持つ。

【4】プロダクトマネージャは顧客側に立つ。
この意味は、プロダクトを使う顧客の観点で、プロダクトに必要な機能は何か、を探り、決定し、リリースすることだ。
プロダクトの種類には、GoogleのWeb検索エンジンもあれば、iPhoneのようなスマートフォンというハードウェア製品もあるし、Facebookの一機能もある。
それらプロダクトを使うユーザが何を求めているのか、そのニーズを見極め、プロダクトのゴールと機能を実現する。

そんな話を聞くと、プロダクトマネージャは、Scrumのプロダクトオーナーに似ている。
製品のロードマップや製品の戦略、ROIの観点から、プロダクトバックログを決めて、開発チームへ作業を指示するわけだ。
もちろん、プロダクトオーナーはプロダクトのアーキテクチャに詳しくなければならないし、アーキテクチャの実現や選択にも権限と責任を持つ。

【5】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」で最も興味深いのは、米国の大手IT企業が求めるプロダクトマネージャのスキルや理想像だろう。
たとえば、Google、Apple、Amazon、Microsoft、Facebook、Yahooの事例が挙げられている。
一部抜粋してみる。

【5-1】Google
・他企業に比べて、組織全体の透明性が高い。
 フルタイムのGooglerは、ほとんどのコードとドキュメントにアクセスできる。
 エグゼクティブチームは、全てのGooglerから質問を受ける機会がある。

・主にコンピュータサイエンス先行の新卒者を積極的に採用する。
 MBAホルダーよりも、修士号や博士号を重視する。

・Google、Microsoft、Facebookなどは、気軽で楽しい職場。
 無料の食べ物や飲み物、無料のマッサージなどの素晴らしい待遇が自慢。

・Googleのプロダクトマネージャ(PM)は、分析スキルが非常に重視される。
 データ分析がPMの主な仕事。
 検索と広告部門のPMは、利用状況のログから新しいプロジェクトのアイデアを考え出す。

【5-2】Apple
・トップダウンでサイロ型。
 プロダクトの方向性はエグゼクティブチームとデザイナーが厳しくコントロールしていて、社内のエンジニアはそのビジョンを実行するマシンのように働く。

・Apple製品を熱狂的に支持している人を求めている。
・ハードウェアとソフトウェアの両方を知っている人を積極的に採用する。
 コンピュータサイエンスだけでなく、電子工学や機械工学も知っていると良い。

・社員に長時間働くことを期待され、倹約が重視される。
 自社のミッションに駆り立てられているため、週末出勤や真夜中の電話対応もいとわない。

【5-3】Microsoft
・プロダクトマネージャは、MSでは「プログラムマネージャ」と呼ばれている。
 他企業に比べて、プログラムマネージャとプログラマの比率は1:3であり、プログラムマネージャがかなり多い。
 他企業では、プロダクトマネージャとプログラマの比率は1:10くらいらしい。

・プログラムマネージャには、大局的な視点で考え、問題を解決し、きちんと仕事を完成させることを求める。

・製品のビジョンと戦略はトップダウン。
 部門内におけるプロダクト戦略は、とてもまとまりがある。
 複数チームが同じゴールに向かって進んでいる感覚があり、2つのチームが競合する機能に取り組んでいることはめったにない。

【5-4】Facebook
・他企業に比べて最も技術面を重視し、技術に明るいプロダクトマネージャを求めている。
 実際、プロダクトマネージャ自身がプロダクトの初期プロトタイプを自作することは珍しくない。

・他社の従業員を雇用する目的で、その会社を買収する場合が多い。
 すると、その企業の設立者やCEOがプロダクトマネージャとして迎えられる場合が多い。

・ユーザがどのようにFacebookを使い、どんな問題にぶつかっているか、を観察することから多くのアイデアが生まれる。
 だから、Facebookのプロダクトマネージャは、ユーザの大量の行動履歴を分析し、注目すべき課題を見つけ、シナリオを作り、何を作りたいか、を提案する能力を求められる。

【5-5】Amazon
・MBAホルダーが重視される、など。

こんな内容を読むと、、Google、Apple、Amazon、Microsoft、Facebookの企業文化がうかがい知れる。
すごく面白い。

【6】「世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~」で更に興味深い点は、プロダクトマネージャに求められる能力が一覧されていることだろう。

【6-1】新卒者は以下のスキルを身につけよう。
・コンピュータサイエンスを主専攻または副専攻にしよう。 

・専攻を2つ選ぼう。
 コンピュータサイエンス以外に、ビジネスやマーケティングがよい。
 ソフトウェア技術とビジネスの両面に興味を持とう。

・グループ研究、リーダーシップのスキルも身につけよう。
 チーム運営で役立つ。

・MBAはプロダクトマネージャとして役立つ。
 ビジネスやマーケティング、グループ研究、リーダーシップ発揮などでいろんな知識が得られる。

【6-2】エンジニアはプロダクトマネージャに転身するのに、適した立場にいる。
プロダクトマネージャは、技術的な経験をベースにビジネスやマーケティングの観点が必要とされるから。

エンジニアあがりのプロダクトマネージャに必要な観点は以下の通り。

・顧客本位に考える。
 この意味は、プロダクトを使うユーザの観点で、プロダクトの機能を考えたり、プロダクトのコーディングを考えること。
 顧客本位の姿勢を身につけるには、実際にプロダクトを使っているユーザと話すのが一番良い。
 それができないなら、システムのログを解析したり、カスタマーサポートのチケットを読むことから始めよう。

・大きく考える
 この意味は、プロダクトのビジョン、ゴール、戦略、ロードマップなどを大局的に考えること。
 どのように作るのか、ではなく、これまでにない新しいプロダクトを作るために必要なことを考えることに専念する。
 
 世界を変えるには?
 もし私が魔法の杖を持っていたら、という仮定のもとで、ブレインストーミングする。
 プレスリリースを書いて、製品のロードマップを書く。

・説得力あるコミュニケーションを身に付ける
 論理的な説明方法とちょっとしたカリスマ性も身につけよう。
 リーダーシップを意識的に発揮して、チーム運営することが求められる。

他にも、アメリカの実際のプロダクトマネージャのインタビューが記載されていて、なるほど、と頷く点もあった。


| | コメント (0)

RedmineでGoogle Apps認証する方法

RedmineでGoogle Apps認証する方法の記事があったのでメモ。

【参考】
ちくちゅう@TokyoさんはTwitterを使っています: "Redmineの認証をGoogleAppsにできるのか。 http://t.co/lfHHycKn8g"

Knowledge for Google Products: 【まめ知識】RedmineでGoogle Apps認証!

Google AppsアカウントでRedmineのOpenID認証 - s5ot.send(:blog)

Redmine Memo - redmine で OpenID を利用する — Redmine Memo v2011-05-02 documentation - red.sicafe.net

RedmineでOpenID連携: プログラマの思索

社内で、RedmineやらJenkinsやらSVN、Gitなどたくさんの開発ツールを入れてくると、認証が面倒になる。
OpenIDのように、一つのIDで全てのWebアプリが使えるようにしたいものだ。

以前、RedmineでOpenID連携: プログラマの思索で調べたけれど、最近なら、Google Apps認証が一番簡単かもしれない。

Knowledge for Google Products: 【まめ知識】RedmineでGoogle Apps認証!を読むと、ログイン画面にGoogleApps認証ボタンが出てくるので、便利そう。

RedmineユーザのメールアドレスをGMailアカウントにしておけば、GMailアカウントのGravatarも表示されるので、チケットの起票者や更新者が文字列ではなくアイコン表示される。
そんな機能があるだけも、ITSの利用度合いが変わってくるから不思議なものだ。



| | コメント (0)

2014/10/02

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine

@akahane92さんのSQIP2014発表資料「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がついに公開された。
Redmineを、SIerのソフトウェア保守のうち、内部統制に適用した事例になる。

【元ネタ】
本会議2日目 9/12 | ソフトウェア品質シンポジウム 2014

本会議2日目 9/12 講演テーマ・講演者紹介 【経験論文】 「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証
赤羽根 州晴 氏 | ソフトウェア品質シンポジウム 2014

赤羽根 州晴 氏 発表資料「「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証」

赤羽根 州晴 氏  経験論文「「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証」

【1】@akahane92さんの論文のストーリーは以下で理解している。

SIのソフトウェア保守において、内部統制の諸問題として、実際は完全性、追跡性、効率や品質などの問題がある。
そこで、RedmineというITSを適用することを着目し、さらにチケット駆動開発の運用ルールを適用してみた。
その結果、チケット完了率が高くなった、チケットの完了所要日数が短くなった、さらに重大な障害件数の減少などの効果が得られた。

【2】上記の論文で興味深い点はいくつかある。
最も興味深いのは、Redmineの運用から得られた定量データだ。

個人的に興味深い点は、ITS運営の定量的メトリクスとして、「チケット完了率,チケットスループット(完了所要日数の平均と分布),添付ファイル指数,説明欄文字数(平均),チケット密度」があげられている点だ。

チケット累積枚数:約12万枚
チケット発行数:約3千枚/月
チケット完了率:93%

この数字を見ると、1日約150枚のチケットが起票されているから、かなりの頻度だ。
これほど大量のチケットが登録されると、チケットが放置されやすいリスクがある。
しかし、チケット完了率が93%という数値を見ると、発行したチケットは最終的には9割以上は完了ステータスでCloseされている。
これはすごい。

僕の経験では、現場ごとに違うけれども、チケットは放置されやすい。
チケット管理が上手くないチームは、1年以上も放置されたチケットがあり、誰もその内容が分からなくなり、手を付けられなくなる。

【3】では、チケットが完了されるまでに、どれだけの所要日数がかかっているのか?

2週間以内に発行チケットが完了:全体の50%
3ヶ月以内に発行チケットが完了:全体の80%
チケットの平均完了所要日数:44日

この数字を見ると、発行されたチケットの半分は2週間で消化されているから、かなり作業効率が良いと思われる。
「チケットの平均完了所要日数」は、リードタイムそのもの。
つまり、チケットの発行日から完了日に至るまでの経過日数の平均。
リードタイムが長い場合、チケットが放置されている状況を示す。
上記の定量データでは、平均完了所要日数は44日だが、中身にはばらつきがある。

僕の経験では、ソフトウェア保守ではなくソフトウェア開発になるが、4人で1ヶ月50枚というVelocityの案件があった。
その案件は作業効率も良く、チームの雰囲気も良かった。
たぶん、赤羽根さんの現場も、チケットのやり取りのおかげで、かなり活発に作業されているのだろう。

ここで重要なメトリクスとして、「チケットスループット」(作業効率)が出てくる。
「チケットスループット」という概念は、リーンソフトウェア開発に出てくる「サイクルタイム」と似てる気がする。
TOCっぽい。
すごくインスピレーションを感じる。

【4】Redmineが今後発展する方向のアイデア: プログラマの思索にも書いたけれど、チケット駆動開発から得られるメトリクスの知見を一度整理したい。
ソフトウェア工学の歴史では、メトリクスの研究は1970年代から信頼度成長曲線など、たくさんのメトリクスが発見され、調査されてきた。
しかし、実際の現場ではほとんど知られていないし、使われてもいない。

その理由は、メトリクスが得られても現場では効果が余り得られないというメトリクスの罠もあるが、メトリクスの収集コストが高かったこともあるのではないか?
Redmineではチケットにデータが集約されるから、好きなだけメトリクスを出力することができる。

Redmineから得られるメトリクスにはどんな種類があり、どの場面で効果的なのか?
その内容を整理してみたい。

| | コメント (0)

« 2014年9月 | トップページ | 2014年11月 »