« 2012年8月 | トップページ | 2012年10月 »

2012年9月

2012/09/30

git-flowのMercurial版hgflow

git-flowのMercurial版hgflowがあると聞いたのでメモ。

【元ネタ】
hgflow - wyukawa’s blog

紹介マニアどらふと版: hgflowを試してみる

yinwm / hgflow / wiki / Home ? Bitbucket

yinwm / hgflow / wiki / UserManual ? Bitbucket

(分散)バージョン管理システムの組織化

subversionでのブランチマネジメント - TIM Labs

git-flow による構成管理とRedmineの関係: プログラマの思索

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【1】hgflowを使うには、yinwm / hgflow / wiki / Home ? Bitbucketからhg clonwして、mercurial.iniへ

[extensions]
hgflow = /PATH/TO/hgflow.py

を追加するだけ。
yinwm / hgflow / wiki / UserManual ? Bitbucketに書いているように、hg flow initから始まり、後はgit-flowのコマンドと同じだ。

【2】(分散)バージョン管理システムの組織化の資料はとても分かりやすい。
メインラインモデルとgit-flowモデルに対し、ブランチ管理の考え方の違いをうまく説明している。

メインラインモデルでは、develop=trunk。
つまり、メインラインは開発中のコードラインであり、最新の機能がコミット済み。
そして、このtrunkからリリースすればリリースブランチ、特定目的であれば、トピックブランチやタスクブランチが分岐される。
Redmineの開発はメインラインモデルで運用されている。

/ - リポジトリ - Redmine

重要な点は、メインラインはリリース可能なコードラインとは限らないこと。

本来のメインラインの定義は、メインラインの定義: プログラマの思索に書いた通り、「最新の機能を持つ」が「リリース可能」とは限らないが、アジャイル開発を運用しているならば、事実上、メインラインは「リリース可能」なコードラインにならざるを得ないと考えている。

git-flowモデルでは、stable=trunk。
つまり、メインラインはリリース済みのコードライン又はいつでもリリース可能なコードライン。
開発者は、特定の期日までに開発するマイルストーンブランチをtrunkから派生し、ブランチ上で作業後、trunkへマージする。
masterブランチはtag専用で、リリース時に作られるだけ。

マイルストーンブランチには、序盤の開発と終盤の開発の2種類がある。
序盤は、新機能の開発であるフィーチャブランチが多いだろう。
終盤は、バグ修正のホットフィックスブランチやリリース作業を事前準備するためのリリース準備ブランチが多いだろう。

特に、git-flowないしhgflowを使うならば、ブランチはITSチケット単位に作り、story/#11などのようにチケット番号で分かるようにした方が運用しやすい。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索にも書いたが、チケット単位にブランチ管理する手法は、「No Ticket, No Commit」の拡張版を生み出す可能性を秘めていて、今後の運用で重要な役割を担うと思っている。

但し、第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索にも書いたが、git-flowモデルを採用したChiliprojectはソース管理がとても複雑化しているのに対し、メインラインモデルを採用した本家のRedmineは頻繁なバージョンアップに伴い、どんどん使いやすくなっている。
この辺りの違いについても、次回の品川Redmine勉強会で議論してみたいと思っている。

| | コメント (0)

ソフトウェア構成管理はチケット駆動開発がサポートする

もう絶版になっているが「ソフトウェア構成管理の悪夢」の一節に、ソフトウェア構成管理の基本成分が書かれていたのでメモ。

ソフトウェア構成管理に至るまでの道のり: プログラマの思索

SW構成管理とはそもそも何なのか?: プログラマの思索

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索

チケット駆動開発がもたらした新しい観点part2~トレーサビリティの拡張: プログラマの思索

Subversion・Git・Mercurialの比較: プログラマの思索

ソフトウェア構成管理の基本成分は4つある。

1・コンポーネントのバージョン管理
2・開発環境ん管理
3・ビルド管理
4・工程管理

1つ目は、ソフトウェアの各部位のライブラリのバージョン管理。
特定のLinuxディストリビューションのgccのバージョンが古い理由は、SCMの負の遺産だろう、という例がある。
90年代から始まったホスト中心の開発からクラサバ・Webへのオープン開発への移行という歴史的背景からすれば、DB・Webサーバー・プログラミング言語・フレームワークなどの各種バージョンを組み合わせて実装する時のサポートに相当するだろう。

2つ目は、開発者の環境におけるバージョン管理の実装。
本では、CVSが相当すると書かれているが、現代ならば、SubversioやGit、Mercurialが相当するだろう。

3つ目は、コンパイルとデプロイ、リリースの管理に相当する。
Cのmakeが例にあげられていたが、現代ならば、AntやMaven、rakeが相当するだろう。
この役割を担う人は、「リリースOKかNGか」を出すのがその責務になる。
今ならば、Jenkinsがその役割を自動化しているだろう。

4つ目は、要件の変更、ソース修正の変更管理、ドキュメント整備などが相当する。
これらの作業の管理のために、CMマネージャ(構成管理マネージャ)という役割を作り、CMマネージャはプロジェクト内部の交差点に立つ交通整理役を担う。
普通は、この役割は、バージョン管理ツールや開発者、QA、プロジェクトリーダーなどの各種役割に分散されているだろう。

CMマネージャは普通はライブラリアンと呼ばれる役割に相当するだろうと思う。
最終的なソフトウェア製品をリリースする役割を担うだけでなく、製品のバージョン管理や変更管理にも責任を伴う。

ソフトウェア構成管理の悪夢」が出版されたのは1999年なので、今から読むとかなり古くなっている部分もある。
特にCMマネージャ、ライブラリアンの役割は、現代ならば、おそらく消え去る役割だと思っている。

製品のバージョン管理や変更管理を支える作業を人手で行なっていた時、その役割を担う専門担当者が必要で、開発者やリーダーから情報を収集し、管理していた。
でも、今は、GitやMercurialで高度なバージョン管理が行えるし、ビルド管理はJenkinsが代用しているし、要件や仕様やソース修正の変更管理はRedmineやTracなどのプロジェクト管理ツールが代用しつつある。

つまり、チケット管理システムがCMマネージャの役割を担当することで、作業を自動化するだけでなく、その役割を透明化してしまった。

他にも、XPのトラッカーの役割はTiDDがサポートする: プログラマの思索にも書いたが、XPでも、プロジェクト内部の進捗情報を収集する役割としてトラッカーという担当者がいたけれども、その役割はチケット管理システムが吸収した。

そんなことを考えると、昔は人力作業でやるしかなかったために、プロジェクトの管理作業を複数の役割を持つ担当者に細分化してサポートさせていたが、チケット駆動開発はそれらの作業者を吸収して、少人数のチームでも効率よく開発できる環境を提供しようとしていると言える。

Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう: プログラマの思索

それによって、チケット駆動開発がアジャイル開発を更に進化させるのではないか、ソフトウェア開発組織のあるべき姿を提示できるのではないか、と直感している。

Twitter / sugimoto_kei: 昨晩の関西IT勉強宴会で、@akipii さんの話を聞いて感じたのは、チケット駆動開発というのは、マネージャの管理ワークの大部分をメンバに移管する基礎を提供することによって、「管理」という仕事の性質と分担を変革しようとする試みではないかということ。単なる自動化じゃないんだよね。

Twitter / akipii: @sugimoto_kei はい、その観点でチケット駆動開発を体系化しようとしています。ERP導入によって女性の事務員が不要になり組織構成が変わってしまうように、チケット駆動開発は単なる管理作業の自動化だけでなくソフトウェア開発組織のあるべき姿を提示できるはずと思ってます

| | コメント (0)

2012/09/28

Pandocでテキストファイルからドキュメント生成

以前から、テキストファイルからWord、PDF、epub出力するツールを探していた。
Haskellで作られたツールPandocでようやく意図できたものが出力できたのでメモ。

【元ネタ】
『ソフトウェアの基礎』のePub版を公開しました。 - みずぴー日記

Pandocのリンク: プログラマの思索

Pandoc - Demos

【インストール】
Windowsでは、ワンクリックインストーラーを使えば、HaskellのGHCを入れなくてもツールを導入できる。

Pandoc - Installing

pandoc --help
で認識すればOK。

Rubyのgem、Pythonのeasy_installに相当するHaskellのライブラリインストールコマンドcabalをインストールするのは面倒だったから。

【epub, word出力方法】
Pandoc - Creating an ebook with pandocに従って、ProGitのテキストファイルをepubやWordへ変換してみる。

まずGitHubから、ProGitのテキストファイルを落とす。
ProGitの本文はmarkdownで書かれているので、TracのWikiに慣れていれば誰でも簡単に修正できる。

git clone http://github.com/progit/progit.git

cd progit/ja

以後、Windowsではコマンドに失敗するとファイルが消えてしまう。
失敗したら以下のコマンドで元に戻す。
git reset --hard

タイトルファイルを作る。
vi title.txt

% Pro Git
% Scott Chacon

epub用のメタデータファイルを作る
vi metadata.xml

<dc:rights>Creative Commons Non-Commercial Share Alike 3.0</dc:rights>
<dc:language>en-US</dc:langue>

以下のコマンドを実行する。

pandoc -S --epub-metadata=metadata.xml -o progit.epub title.txt \
01-introduction/01-chapter1.markdown \
02-git-basics/01-chapter2.markdown \
03-git-branching/01-chapter3.markdown \
04-git-server/01-chapter4.markdown \
05-distributed-git/01-chapter5.markdown \
06-git-tools/01-chapter6.markdown \
07-customizing-git/01-chapter7.markdown \
08-git-and-other-scms/01-chapter8.markdown \
09-git-internals/01-chapter9.markdown

progit.epub が作られる。
目次も作られているし、iPod touchでStanzaやiBooksに入れれば、読みやすい。

但し、図の画像ファイルがepubに入っていないので、その部分はPerlコマンドで一括置換する必要がある。

perl -i -0pe \
's/^Insert\s*(.*)\.png\s*\n([^\n]*)$/!\[\2](..\/figures\/\1-tn.png)/mg' \
*/*.markdown

Wordで出力するには、以下のコマンドを実施すればいい。

pandoc -f markdown -s title.txt \
01-introduction/01-chapter1.markdown \
02-git-basics/01-chapter2.markdown \
03-git-branching/01-chapter3.markdown \
04-git-server/01-chapter4.markdown \
05-distributed-git/01-chapter5.markdown \
06-git-tools/01-chapter6.markdown \
07-customizing-git/01-chapter7.markdown \
08-git-and-other-scms/01-chapter8.markdown \
09-git-internals/01-chapter9.markdown \
-o progit.rtf

PDF出力するには、pdflatexを入れないと駄目なので止めた。
rtfファイルをWordで開けるので、印刷モードでPDF出力すれば問題ない。
完全な自動化とは言いづらいが。。

でも、テキストファイルならばGitやMercurialでバージョン管理でき、差分が分かりやすいので、書きやすくなる。
執筆記事や講演資料などもmarkdownで書けるならば、章立てや整形も楽ちん。

Pandocは出力形式が豊富なので問題ない。
最近のドキュメント生成ツールは、epub出力がデフォルトみたい。
epub出力できれば、スマフォで簡単に読めるし、通勤電車や待ち時間のような隙間時間に、本を広げる場所も必要なく気軽に読めるのが良い。

【追記】
本当は、Sphinxを使いこなしたかったが、Windowsとはとても相性が悪い。
PythonやSphinxはインストールできるものの、PDF変換ライブラリrst2pdfやWord出力ライブラリのインストールにいつも失敗する。

おそらくWindowsでPythonを動かそうというのが間違っている気がする。
やはりプログラミングをバリバリこなしたいならば、Unixが良いのだろう。

最近思うのは、Windowsでプログラミングしづらいこと。
RubyやPython、Java、Perlなどのプログラミング言語、GitやMercurial、Subersionのようなバージョン管理ツールはOSにデフォルトで入っていて欲しい。
MicrosoftはOfficeにこだわりすぎて、時代に遅れ始めている気がする。

Microsoft決算、上場後初の赤字 aQuantive買収の営業権減損で - ITmedia ニュースというニュースはIT業界ではほとんど話題にもならなかったが、僕にとっては衝撃的だった。
実際、Microsoftは、AppleやGoogleに比べるとスマートフォン開発に乗り遅れていて、ポストPCをようやく追い駆け始めている。

| | コメント (1)

RedmineとTracの機能比較part3

RedmineとTracの機能比較の記事があったのでメモ。
かなり詳しく説明している。

【元ネタ】
RedmineとTracの比較

Twitter / akipii:かなり詳しい比較結果 RT @ruimo: 良くまとまってる。若干Redmine寄りな気もするので、Trac寄りな人の意見も聞いてみたい。 http://www.02.246.ne.jp/~torutk/swetools/redmine/comparison_redmine_trac.html …

RedmineとTracの機能比較: プログラマの思索

Tracのワークフロー: プログラマの思索

(引用開始)
【比較のまとめ】
・ツール管理者がUNIXのコマンドライン環境に馴染んでいない場合、Redmineの管理が容易である
・開発管理に用いる場合で、開発チームが複数からなる開発プロジェクトでは、Redmineがチームごとの開発管理と全体の開発管理を複数プロジェクトで管理することができる
・ユーザー(アカウント)管理は、Redmineは用意されているWeb上でユーザー管理ができるがTracはApache側のユーザー認証設定とTrac側の権限管理を行う必要がある
・ワークフローを複数種類設ける必要があるならRedmineが容易である
・チケットを階層化(親子関係)し、階層配下のチケットの集計を行うならRedmineが容易である
・チケット同士の相互リンクはRedmineが容易である
・開発管理に用いる場合で、チケットのブレークダウンが必要なら、親子チケットを持つRedmineが管理容易である
・開発管理に用いる場合、Wikiページの階層構造を積極活用するため、階層構造の変更が容易なRedmineがWikiページのメンテナンス容易である
・チケットとリポジトリの連携は、チケットからのトレーサビリティを必要とするならRedmineが容易である
・リポジトリを専用マシンで動作させたいならRedmineが容易である
・Subversion以外のバージョン管理ツールと連携するならRedmineが容易である
・情報共有の基盤としてチケット管理以外にも活用するならRedmineが容易である
・リアルタイムでプロジェクト固有なチケット集計・分析レポートを作成するならWikiにSQL結果を埋め込めるTracが容易である
(引用終了)

拙著「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」では、Redmine・Trac・Mantisについて、それぞれのツールの使い方と比較結果を詳しく書いたので、参考にしてみてください。

個人的には、プロジェクト管理ツールはもっと根付いてもいいと思っている。
Excelに書いたドキュメントは、共有ファイルサーバーにおいても、何が書いてあるのか一目で分からないから誰も読みはしない。
日本のSIでは、暗黙知というノウハウや独自の運用ルールをたくさんのExcelドキュメントに書けば、業務革新や組織貢献につながるという節があるが、特に最近は時代の流れに合わなくなっていると思う。

| | コメント (0)

2012/09/26

なぜ日本ではチケット駆動開発が注目されるのか?

アトラシアンブログでチケット駆動開発の記事が公開されました。
Part1は@sakaba37さん、Part2は私の予定です。

なぜ日本ではチケット駆動開発が注目されるのか?(ゲストブログ) | Atlassian Japan

また、今月号の日系Systemsには、@daipresentsさんや@haru_iidaさんがRedmineを導入した事例やインタビューが掲載されています。

記者の眼 - RedmineやTracで勘違いや書類探しの手間をなくそう:ITpro

日経BP書店|商品詳細 - 日経SYSTEMS

日経SYSTEM10月号でRedmine導入事例を掲載していただきました | 世界 - daipresents!!

日本の現場では、チケット駆動開発は事例として当たり前になりつつあるのでしょうか?

| | コメント (0)

2012/09/25

チケット駆動開発はフィードバック管理システム

チケット駆動開発フィードバック管理システムだと思う。

Twitter / akipii: #kansumi 及川さんの話を聞いて思う事。チケット管理システムはフィードバックシステムであること。顧客に価値ある製品を届けるには顧客の数多くの評価を収集し分析して製品にいち早く反映する仕組みが大事。でもフィードバックを集める仕組みがまだ発展途上

Twitter / akipii: 及川さんの話を聞いて思う事。顧客のフィードバックを生かすだけでなく顧客に問題発見、問題修復を支援してもらう仕組みの一つがアジャイル開発かな。#kansumi

フィードバックを収集し、集計できて、議論した結果をまとめたりして、ユーザの力を利用できるのが最大の利点。

フィードバックは、チケットで収集される。
フィードバックの内容は、障害報告もあれば、機能改善の提案、パッチ付きの提案、開発チーム自身の振り返りの運用改善、など様々だ。

顧客から、リリースしたソフトウェアに対し、これバグじゃないの、という障害報告。
熱心なファンから、リリースしたソフトウェアにこんな機能を追加したら、さらに使い勝手が良くなるのでは、という機能改善の提案。
熱心なユーザから、あのバグはこのパッチを当てれば直るよ、とパッチ付きの提案。
開発チームがリリース直後にふりかえりミーティングを実施して、障害検証のワークフローのこの部分はやりにくかったから、この運用に変えよう、と運用改善の提案。

それらフィードバックをチケット化すれば、チケットに優先度、期日、カテゴリなどの属性を付けて集計すれば、色んな観点で分析できる。
障害報告の多い機能は、回帰テストを増やそう。
機能改善の多い箇所は、開発の優先度を高めるようにしよう。
運用改善のために、既存のワークフローに新たなステータスを追加して、ペア作業しやすくしよう。
パッチをもらったから、コードレビューしてOKならリリースしよう。

チケットにするまでに、フォーラムでチャットみたいにユーザと議論してもいい。

ユーザからのフィードバックを収集するだけでなく、ユーザ自身に問題発見してもらい、問題解決のアイデアを出してもらう。
さらには、ユーザ自身にパッチを作ってもらうように、問題修復を手伝ってもらう。

たくさんのフィードバックを効率的に管理したい。
全てはチケットファースト。

フィードバックがチケット駆動開発の価値観の一つ。

【参考】
チケット駆動開発はステータス追跡システム: プログラマの思索

| | コメント (0)

2012/09/22

パターンランゲージの形式と正当性

パターンランゲージについて調べ直している。
コプリエンの組織・開発工程のパターンランゲージの序文がとても意味深だったので、理解できたことをメモ書き。
プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集」にも記載されている。

【元ネタ】
生成的開発プロセス・パターンランゲージ

はじめに

生成的開発プロセス・パターンランゲージ - lamuuの勿忘草日記

Scrum:超生産的ソフトウェア開発のための拡張パターン言語

- XPとパターン Ralph Johnson'sの見解

- 組織パターンとプロセスパターン(石井 勝)

【1】アレグザンダーが生み出したパターン言語というアイデアを、IT業界にも使えないか、という発想が生まれた。
GoFもケントベックもカニンガムもコプリエンもその流れにいる。
その辺りの経緯は「パターン、Wiki、XP ~時を超えた創造の原則」に詳しく書かれていて、とても面白い。

GoFはデザインパターンというプログラミングの定石ともいえるパターンを作った。
コプリエンは、その直前に「生成的開発プロセス・パターンランゲージ」という論文で、ソフトウェア開発の組織・開発工程のパターンランゲージを42個提唱した。

【2】パターン言語の特徴は、「特定の状況(Context)で発生した問題(Problem)に対して解決法(Solution)を提示する」という定型的なスタイルで簡潔に形式知を説明してくれること。
例えば、GoFのデザインパターン24個も、ある特定の状況の特定の問題に対して有効なのであり、すべての状況で有用なのではない。

例えば、システム提案時に、顧客の現在の業務を洗い出した後、システム化であるべき姿を提示するプロセスがある。
このプロセスは、AsIs(現状の姿)に対するToBe(あるべき姿)を提示するわけだが、パターンはまさにその形式に当てはまる。
つまり、現状の問題点に対し、パターンが問題解決してあるべき姿を提示してくれるわけだ。

パターンの形式はいくつか流派があるが、コプリエンの形式はアレグザンダーのそれに近いらしい。

パターン名称(Pattern Name):
問題の解決の仕方などが直感的にイメージできるような名前。

別名(Alias):
上記のパターン名称の別名。すべてのパターンが別名を持っているわけではない。

問題(Problem):
解決したい問題。

コンテキスト(Context):
問題が発生しているまわりの状況や、問題を解決しようとしている人が置かれている状況。

影響する事柄(Forces):
問題解決に際して影響を与える事柄や考慮しなければならない事柄。

解決策(Solution):
問題解決策。

結果として生じるコンテキスト(Resulting Context):
問題を解決したことによって生じる状況。

論理的根拠(Rationale):
パターンが効果があることの論理的な根拠。

上記のパターン形式が従来のノウハウのような経験知よりも優れているのは、どんな問題に対して解決法が有効であるのか、というだけでなく、パターンで問題解決した後、どんな変化が生じるのか(結果として生じるコンテキスト)、パターンが有効であることの根拠の説明などを一貫して説明できること。
特に、影響する事柄(Forces)や論理的根拠(Rationale)では、他のパターンと組み合わせた方が良いとか、パターン適用後に別の問題が発生したら他のパターンを使え、など、パターンの関連性についてとてもよく考えられている。
パターンは、単なる思い付きのアイデアではない。
パターンは「生成的(generative)」である点がとても重要。

【3】だが、そのパターンが本当に正しいのか、という正当性の問題は残る。
はじめににも書かれているように、パターンの正当性は「ケーススタディと常識をよりどころとしている。」
何故なら、以下の理由が3点挙げられる。

(引用開始)
それらのパターンの“良さ”とか“悪さ”は、実験によって確かめることは困難である。第1に、組織の良さの測定は、必然的に多次元で複雑である。第2に、パターンの有効性が検証できるよう制限の強い制御変数を用いて大規模な社会的な実験をするのは困難である。第3に、そのような実験は長期間の関与が必要で(何ヶ月あるいは何年も)、多くのソフトウエア組織が、壊れやすく進化し続ける市場から見て、進んで費やしようと思う期間を超えている。
(引用終了)

パターンは現場の経験知、つまり、何度も繰り返し現れる問題とその解決法を形式知としてまとめたものであるがゆえに、本当にその解決方法は全ての現場でも使えるのか、という疑問は常にある。
パターンの正当性は、いくつかのケーススタディという事例と常識に依存しているために、パターンが問題の全てを解決しているのか、効果があるのか、という点は慎重な考察を必要とする。
コプリエンは、数多くの人たちの経験的観察から検証されていると補足説明している。

(引用開始)
我々は、相互作用に関連して組織で繰り返し発生するパターンを調べ、それらのパターンとある“良さ”の観測の関係が繰り返されるパターンに注目し、そして相関関係を分析する。ここで説明されるすべてのパターンにおいて、パターンを説明する論理的根拠に経験的な観察が付け加えられている。このパターンランゲージが高生産性の組織が持つ本質的な特徴を全体的に掴んでいるという主張は、これらのパターンを読んだ、多くの小さくて生産性が高い組織のCEO達によって検証されている。
(引用終了)

【4】パターン言語の文献を読んでいると、日本のIT業界ではプロジェクト管理やDOAを中心としたモデリング技法、製造業を発端とした品質管理の技法について歴史があるにも関わらず、なぜパターンのような形式知としてまとめられなかったのか、いつも疑問に思っている。
多分、日本のIT業界では、それらのノウハウは門外不出として公開できなかったため、各SIでバラバラのノウハウとして蓄積されていて、一つの体系としてまとめられなかったのが理由だろうと思っている。

忘れ去られた日本のIT技術~プロジェクト管理: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

コプリエンの組織・開発工程のパターンランゲージを読んでいると、XPのプラクティスと関連する箇所が多い。
Scrum:超生産的ソフトウェア開発のための拡張パターン言語によれば、Scrumに出てくる概念やプラクティスの背後には、コプリエンの組織・開発工程のパターンランゲージが関係しているという。
アジャイルソフトウェア開発スクラム」でも、同様の記述がいくつか出てくる。

つまり、アジャイル開発の背後には、コプリエンのパターンランゲージが隠れていて、アジャイル開発がなぜ有効なのかという理由の一つには、コプリエンの組織・開発工程のパターンランゲージという優れたパターンがあり、すでに実証されているから、と言えるのではないだろうか。

チケット駆動開発も「ITSとバージョン管理の便利な使い方」から発生した現場の経験知の一つ。
だからこそ、パターン言語のような形式の方が、チケット駆動開発がなぜ有効なのか、という理由を明確にしてくれると思っている。
そして、チケット駆動開発のプラクティスをコプリエンの組織・開発工程のパターンランゲージで補強説明することで、プラクティスの特徴をうまく説明できるのではないか、と思っている。

| | コメント (0)

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

@LightningXさんが、Redmine×Gitで新しい運用方法を提唱されていたのでメモ。

【元ネタ】
Redmine×Gitのハーモニーは涙のチケット駆動開発!? (1/3) - @IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (2/3) - @IT

Redmine×Gitのハーモニーは涙のチケット駆動開発!? (3/3) - @IT

Gitのような分散バージョン管理の場合、No Ticket, No Commitはどのように拡張されるのか?

(引用開始)
「チケット駆動開発」(Ticket-Driven Development、TiDD) と呼ばれるチケットベースで作業を管理する手法では、このコミットとチケットの関連付けが作業を管理するうえでのキーポイントになるんだよ。例えば、ストーリーの実装やバグの修正というチケットがあった場合、その作業でどこが変更されたのか、管理できるよ。
(中略)
ブランチのチケットへの対応付けは、図のようにブランチ名に「#」とチケットIDを入れてブランチを作成するだけです。例えば、チケットID「16」のチケットへ対応付けるブランチは「story/#16」のような名前で作ります。「impl-reply-func-#16」などのブランチ名にしても大丈夫です。

$ git branch story/#16
$ git checkout story/#16

もしくは、

$ git checkout -b story/#16
(中略)
 図9と10を見ると、コミットメッセージの先頭に「refs #16」が付いていますが、これはRedmineのプラグインがコミットメッセージに自動的に関連キーワードを追加しているの。実際には、コミットメッセージには、「ブランチのコミットをチケットへの反映を実装」のようにチケット番号を含める必要はありません。
 これは、「story/#xx」というブランチ名を利用する例だけど、タスクに対応付けたい場合、「task/#xxx」、バグに対応付けたい場合「bug/#xxx」とすると、各ブランチが何の作業なのか分かって便利だよ。
(中略)
ポイントは、「git push」コマンドでプッシュが必要なところね。共有リポジトリにコミットを送信しないと、Redmine(ALMinium)側でコミットによりソースが変更されたことが分からないから、チケットと関連付けされるのは「プッシュした後」になるの。

$ git push -u origin story/#16
(初めてブランチをプッシュする場合)
$ git push
(2回目以降)
(中略)
「ブランチをマージしてからチケットを閉じる」と説明しましたが、「Redmine Git Branch Hook」(後述)というマージ時に自動的にチケットをクローズするプラグインがあります。例えば、先ほどコミットしていったstory/#16ブランチを次のようにしてmasterブランチへマージします。

$ git checkout master
(masterブランチへ移動)
$ git merge --no-ff story/#16
(masterブランチへstory/#16ブランチをmasterブランチへマージ)
$ git push
(引用終了)

上記の使い方を見ると、以下でまとめられる。

(1)チケット単位にブランチをoriginからフォークする
git branch story/#16

(2)フォークしたブランチ上の修正コミットは、Redmineのリポジトリブラウザへ自動でpost-commit-hookされる

(3)originへブランチからpushする
git push -u origin story/#16
または
git push

(4)ブランチの修正を一括マージして、チケットも同時にCloseする
git checkout master
git merge --no-ff story/#16
git push

僕が以前Subversionを使っていた時、Redmineの複数プロジェクト機能を使って、プロジェクトとブランチと同期させることによって、ブランチの変更履歴を管理しやすいようにしていた。
つまり、リリースブランチを作るたびにRedmineプロジェクトが作られて、次のリリースでプロジェクトもリリースブランチも廃止される運用を行なっていた。
しかし、この運用は、リリースするたびにプロジェクトが増えてしまい、逆に管理しづらくなる弱点があった。

Redmine1.4以降では、1プロジェクトで複数リポジトリを登録できるため、リリースブランチやトピックブランチ、フィーチャブランチなどは1プロジェクトにまとめた方がチケット管理しやすくなる。
上記のように、分散バージョン管理とITSを連携する場合、ブランチの生存期間をプロジェクトではなく、チケットの生存期間に合わせる方が運用しやすいだろう。

何故なら、GitやMercurialでは、複数のブランチが常に併存するのは当たり前であり、それらブランチの寿命は短いのが普通なので、ITSプロジェクトのように生存期間の長い機能よりもチケットの方が管理しやすくなるだろうと思う。
その利点は、トピックブランチのライフサイクルをチケットの生存期間と一致させることによって、ソース修正の変更履歴を記録しやすくできるからだ。

つまり、「チケット無しでフォークやプルリクエストは許さない」というチケット駆動の新しい運用方法と言えると思う。
「No Ticket, No Branch」という運用方法と呼ばれるかもしれない。

また、「この機能はGitHubで実装されている「プルリクエスト」と呼ばれる機能にインスパイアされたようです。開発者がブランチで開発を行い、ブランチの変更をレビューした人がマージする、という考え方の部分は、ほぼそのままですね。」という指摘も興味深い。
GitHubのプルリクエスト機能がとても素晴らしい理由の一つは、単なるマージ作業依頼だけでなく、パッチのコードレビューをオンライン上で実現できるようにしたからだと思う。
コミッタはプルリクエストを受け取る時点で、パッチの差分を必ずチェックする作業が自然に生まれるからだ。

GitやMercurialのフォークやプルリクエストは、単なるブランチ管理やマージ作業だけでなく、コードレビューという非同期ペアプログラミングを実現する重要な運用を生んでいることにも注意したい。

| | コメント (0)

2012/09/17

「チケット駆動開発」の感想を集めてみたpart4

チケット駆動開発」の感想を見つけたのでメモ。
感想ありがとうございます。

【元ネタ】
チケット駆動開発を読んだ

(引用開始)
付箋の数と良書度は比例する(脳内調べ)。

アジャイルとウォーターフォールという二元論的な考え方は、その概念が普及する段階では役に立ちましたが、もうその次代は終わりつつあると思います。様々な開発法があるなかで、どのようなプロセスで開発するか、具体的な実践技術が求められているでしょう。

僕のチケット駆動に対する期待は、創薬研究への応用なので、チケット駆動開発の背景にある考え方がぎっしり詰まった本書は、色々な発見や再発見があったり、今の仕事のアナロジーを見つけたりとかなり満足度の高い本だった。ただ、redmineをある程度使っているとか、アジャイルサムライ読んだとかそういいう基礎知識は必須なので、いきなり本書を読むよりは前作を読んだりしておいたほうがいいかなと思う。
処理手順
障害管理ツールの処理手順(p.24)を創薬探索系に重ねると、

障害発見者: アッセイ担当
BTS: BTS
担当者: 合成担当
という感じになるかな。そうすると障害とは何か?という話になるが、創薬系だと予想外の結果ということになるだろう。

予想外というのは仮説駆動開発の文脈だったら、なんのために合成するのか?という最初の目的が達成されたかどうかで判断するところだろうが、明確な目的を持って合成されることは少ないので、MMPに照らし合わせてcliffかどうかで判断してもいいかもしれない。結局cliffは予測外の事象だからね。

リポジトリマイニング
創薬系だとリポジトリにあたるものは既に存在するので、そこから今後の予測を行う技術は非常に興味がある。本書では詳しく解説されてないので、他の文献をあたろうと思った。

バージョン
本書を読んでredmineのバージョンの使い方を理解した。だが、創薬系だと多次元で並行的に進めていくので、ソフトウェア開発だと2系と3系を同時に開発するみたいな感じかなあ。ちょっと難しい。

バージョンの概念は、単なるタグだけでなく、合意というマネジメント要素も含んでいるのです。
p.295のバージョンの概念が欠落する理由も参考になった。
(引用終了)

ソフトウェア開発ではなく、製薬業界でチケット管理を使おうとされているそうです。
上記の疑問について、私の独断で回答してみます。

Q.創薬系の障害とは何か?
A.薬を購入したユーザやメーカーからの問合せないしクレームが相当するでしょう。
 クレームが来たらチケットに登録し、そのクレームを解決できる担当者を決定します。例えば、研究チーム、あるいは、オペレータがすぐに回答できるかも知れません。
 その後、その回答をユーザに返して、問題なければCloseされます。
 つまり、問合せの評価(障害の検証)はユーザが担当していることになります。

Q.創薬系のプロジェクトのバージョンとは何か?
A.プロジェクトのマイルストーンに相当します。
 学会で報告する、創薬研究の開発が完了する、などのチェックポイントが大きなマイルストーンになりますが、たぶん1ヶ月単位で意味ある成果物を出せるように、マイルストーンの目的を明確にすればいいでしょう。

Q.多次元で並行的に進めていく場合の管理方法は?
A.最終成果物の単位でプロジェクトに分割し、プロジェクト単位にバージョン(マイルストーン)を定期的に作って、チケット管理するといいでしょう。
 最終成果物とは、ソフトウェア開発なら、納品対象のシステムないしリリース対象のソフトウェアになります。
 
Redmine入門 - プロジェクト | プログラマーズ雑記帳では、Redmineプロジェクトの観点がとても分かりやすく説明されています。

(引用開始)
後で説明するバージョン管理システムとの連携もあり、バグはソースに対して管理した方がよいため、 なるべくソースの構成に基づいたプロジェクトにした方が管理しやすいです。
例えば、あるプログラムが Windows 版、 Linux 版または Standard 版、 Professional 版といったように別々のプログラムになっていたとしても、 ソースコードが一元管理されているのならば、同一プロジェクトするか もしくは 同一プロジェクト内でサブプロジェクトで分けるようにした方が管理しやすいと思います。
(引用終了)

上記から、「チケットはバージョン管理リポジトリに従う」というプラクティスを導出できるでしょう。
つまり、バージョン管理リポジトリは製品の構成とまさに対応していて、バグはソースに対して管理するために、バージョン管理リポジトリの変更管理がチケット管理に相当するからです。
製薬業ならば、アウトプットである薬の単位でプロジェクトを作り、その薬の開発に関する作業が発生すれば、該当する薬のプロジェクトでチケット管理することになるでしょう。

| | コメント (0)

アジャイル開発のルネサンス

最近のアジャイル開発の復活(ルネサンス)について、とても分かりやすい感じのつぶやきがあったのでメモ。

【元ネタ】
Twitter / k_tanaka0611: 特にテスト駆動開発については、ずっと以前から注目はしてた、2000年代の前半ごろ、アジャイル特にXP(エクストリームプログラミング)がもてはやされた。

Twitter / k_tanaka0611: 確か牛尾さんの、オブ脳本、倉貫さんのTDD本が出たのもそのころじゃなかろうか。

Twitter / k_tanaka0611: それ以降現場では、あまりプラクティスが実践されることは無く現在に至るっのが僕個人の現状だけど、最近、アジャイル開発は、第二のムーブメントがやってきた気がする。

Twitter / k_tanaka0611: アジャイルが活発になったと個人的に感じる理由として一つ大きくあげられるのが今まで求められなかったツールの技術が求められるようになってきてることだ、Redmineもその一つだけど、やっぱりソースコードのバージョン管理システムだろうなぁ

Twitter / k_tanaka0611: svnは、ここ10年以上開発現場では、スタンダードでその地位は揺ぎなかった、それが変わるなんて事があるのかとさえ感じられる程だった。しかしこの2年くらい、特にgitはgithubのムーブメントにのり開発者は意識せざるを得なくなってきている。

Twitter / k_tanaka0611: テスト駆動開発においても、今までのアサーションの羅列からBDDといわれるスタイルに変わりつつある、コードをみると明らかにモダンで見やすいので今後はこちらがスタンダードになるのは間違いないと感じてる

Twitter / k_tanaka0611: そして、今後2~3年後のシステム開発を変えるインパクトがあるのは、何と言ってもjenkinsだと思う。これを導入するしない、している現場でも上手く使える、使えないでおそらく3倍程の生産性が変わるんじゃなかろうか

Twitter / k_tanaka0611:システム開発の現場ってやたらと人を探して、いい人がい無いなどと嘆いている事が多い、しかしたとえ人が増えたとしてもそれで上手くまわった試しが無い。

Twitter / k_tanaka0611: ツールが全てでは無いけど、ツールを使う事で考え無くて良くなる事も多く、目的をツールを使う事に置き換えて、行動の一歩を縮められると思う

Twitter / k_tanaka0611: 最終的には、仕様どうり不具合の無いコードを期限内に仕上げられる事だけど、決して個人の技量だけじゃムリ。開発手法そのものも見直さな幸せになれない

第二期アジャイルムーブメント ~ アジャイル開発の商業的取り組み と Agile2.0 ないし 「2週目の世界」 について - kawaguti の日記 (id:wayaguchi)

牛尾さんの「オブジェクト脳のつくり方」本、倉貫さん・川端さん・こだまさんの「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発 (Be agile!)」本が2000年代前半に出版され、日本でもアジャイル開発に関する技術の事例は公開されていた。
でもずっとアジャイル開発は傍流だった。
最近になって、アジャイル開発が日本で再注目された感じがあるが、その流れについては、第二期アジャイルムーブメント ~ アジャイル開発の商業的取り組み と Agile2.0 ないし 「2週目の世界」 について - kawaguti の日記 (id:wayaguchi)がとても詳しい。

個人的には、ソフトウェア開発の環境がようやく時代に追いついたと思っている。
XPやScrum、RUP、CMMI、PMBOK、BABOK、テスト管理の技法は既に2000年までに既にその概念もプラクティスも提示されていたにも関わらず、開発現場ではなかなか運用できなかった。
その理由の一つは、設計やプロジェクト管理の技法がプログラミングの進化の速度に追いつけなかった点があると思う。

でも、今はタスク管理ならRedmineやTrac、バージョン管理ならGitやMercurial、ビルド管理ならJenkinsのように、優れたツールが開発環境だけでなくプロジェクト管理もかなりサポートしてくれる。
上記のTwitterの指摘通り、Jenkinsの使い方の模索は今後注目度が大きくなるだろう。

Twitter / mitoma_ryo: JenkinsのPluginとしてRedmineTicketMetricsPluginというものをちまちま作っている。アイデア元は http://forza.cocolog-nifty.com/blog/2012/04/jenkins-d895.html … #jenkinsja pic.twitter.com/HjGvGHqH

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

ツールにプロセスで労力がかかる作業を任せるだけでなく、ツールの新しい機能がプロセスの可能性を広げてくれる。
ツールを使うユーザが運用で更に機能拡張のアイデアを出して、そのアイデアをコミッタが受け入れて、更にツールが進化し、プロセスがサポートできる範囲を広げてくれる。
特にオープンソースのツールは、コミュニティという場がユーザとコミッタの間で有意義で議論をできる場を提供して、ツールの進化をサポートしてくれている。

Twitter / tkusukawa: Redmine2.1。今回も、かゆい所に手が届く気持ち良さを感じるバージョンアップ。利用者に本当に価値のあるシステムはこうやって築き上げられるのだという様をリアルタイムに目撃している気がする。 http://blog.redmine.jp/articles/redmine-2_1-changelog/ … #fb

ツールがプロセスを改善するのだ。
ソフトウェアがプロセスを通じて、世界を変えてしまうのだ。

| | コメント (0)

MVPを元にした製品開発

Inspired日本語版というWebページの記事がとても面白かったのでメモ。
いわゆるリーンスタートアップに出てくるMVPを元にした製品開発を題材にしているように思える。
目に留まった内容をラフなメモ書き。
詳細はWebページを見てください。
App Storeでも電子書籍で売られているようです。

【元ネタ】
書籍目次 ≪ Inspired日本語版

App Store - inspired-j

【1】はじめに ≪ Inspired日本語版

(引用開始)
もっとわかりやすく言うと、技術的にいい仕事をするだけではダメなのだ。それと同じくらい、あるいはそれ以上に大事なのは、価値があって (valuable)、使いやすくて (usable)、実現可能な (feasible) 製品を「見つけ出す」ことである。
失敗の原因を徹底的に突き詰めていくうちに、何を作るかを決めたのは、プロダクトマネージャーと呼ばれる人だということがわかった。プロダクトマネージャーは、通常はマーケティング部門に所属していて、私たちエンジニアが作り上げる製品のプロフィールを決める人であった。ところが、さらにわかったのは、プロダクトマネジメントは、HPにとってあまり得意な領域ではないということだった。そして、後になって気づいたのだけれど、ほとんどの会社はプロダクトマネジメントが得意ではなく、その状態は今も変わっていない。
(引用開始)
プロダクトマネージャーの仕事は、価値のある、使いやすい、実現可能な製品を「見つけ出す」ことである。
(中略)
プロダクトマネージャーの仕事は、価値があって、使いやすくて、実現可能という目的を満たす上で必要最小限の (余計なものが一切そぎ落とされて洗練された) 製品を特定することである。これによって、製品化までの時間と製品の複雑さを最小限にするのである。
(引用終了)

リーンスタートアップに出てくるMVPの定義とは、価値があって (valuable)、使いやすくて (usable)、実現可能な (feasible) 製品であり、必要最低限の機能を持つこと。
価値があるのは、顧客価値に相当。
使いやすさは、使用性(ユーザビリティ)という品質特性に相当。
実現可能性は、アーキテクチャがプログラムで実装可能で、システムとして実現可能(フィージビリティ)であること。

面白い点は、MVPは6個の品質特性(機能性、信頼性、性能、使用性、保守性、移植性)の中で、使用性を最も重視していること。
製品のアーキテクチャが実現可能(フィージビリティ)であることを保証する人は普通はアーキテクトだが、プロダクトマネージャもアーキテクトの役割を兼ねること。
つまり、プロダクトマネージャはかなりの高レベル人材であること。

(引用開始)
エンジニアリングは、重要で困難な仕事である。でも、もっと重要なのがユーザーエクスペリエンスデザインであり、それは、たいていの場合エンジニアリングよりも困難である。
エンジニアは、たいていユーザーエクスペリエンスデザインが不得意である。エンジニアは実装モデルで考えるが、ユーザーは概念モデルに基づいて考える。
機能性 (製品要求) とユーザーエクスペリエンスデザインは、本質的に連関している。
(引用終了)

使用性という品質を重視すること。それは機能性に密接に関係している。

【2】第1章 製品開発の鍵を握る担当者とその役割 ≪ Inspired日本語版

プロダクトマネージャーの役割
プロダクトマネージャーの主な任務は2つ。
製品の市場性を評価することと、開発すべき製品を定義すること。

(引用開始)
十分に市場性があって、自社でそのアイデアを実現できる可能性が高いと判断されれば、その次には、誰かが、そのアイデアの具体的な形、つまり、どういう製品にするのか(必要とされる特性と機能、ユーザーエクスペリエンス、発売の基準など)を「見つけ出す」必要がある。ここで、再びプロダクトマネージャーの出番となる。この任務は、プロダクトマネージャーの仕事の核心部分である。こうして形になっていく仕様は、製品要求仕様(PRD, Product Requirement Document)、あるいは、製品仕様、機能仕様などと呼ばれる。ここで、私は、紙ベースではなく、プロトタイプに基づく軽量なアプローチを勧める。しかし、肝心なのは、その仕様書が記述すべきことは、開発されるソフトがどういう機能を備えて何をするものかということであり、どのように動くかではないということだ。
(引用終了)

上記の製品こそが、リーンスタートアップに出てくるMVP(実用最低限の機能を持つ製品)に相当する。

【3】第2章 プロダクトマネジメント VS. プロダクトマーケティング ≪ Inspired日本語版

マーケティング主導の製品である
一つの役割に二人の担当者がいる
一人で二つの役割を兼務している

【4】第3章 プロダクトマネジメント VS. プロジェクトマネジメント ≪ Inspired日本語版

プロダクトマネージャーとプロジェクトマネージャーの違い


トレインモデル。
それは並行開発。
複数のコンポーネントを平行に開発したり、別の複数の製品を平行に開発したりとか。
派生開発、ソフトウェアプロダクトラインを連想させる。

【5】第4章 プロダクトマネジメント vs. デザイン ≪ Inspired日本語版

ユーザーエクスペリエンスデザイン、つまり使用性(ユーザビリティ)という品質特性の重視

第5章 プロダクトマネジメント vs. エンジニアリング ≪ Inspired日本語版


正しい製品を作るのか、それとも、製品を正しく作るのか
前者はアーキテクトないしプロダクトマネージャ。つまり、製品設計、アーキテクチャの問題。
後者はマネージャ。つまりマネジメントの問題。

エンジニアリングチームがコードを書き直したいだって!?

(引用開始)
こういうことが起きてしまう原因でよ目につくのは、プロダクトマネージャーが、作れそうな機能なら何でもめいっぱいくっつける、というようなことを何年にもわたってエンジニアリングチームにやらせてきたために、彼らをボロボロにしてしまうことだ。結果はといえば、インフラを考えないで酷使すれ、いずれ、ソフトウェアがもはや機能しなくなるときが必ずやって来る。
(中略)
エンジニアリングで何かのキャパシティを設定するときは、そのうち一定の割合を予備として空けておくのだ。eBay ではこれをヘッドルーム (頭上の空間) と呼んでいた。
(中略)
エンジニアリングチームとは、次のような感じで取り決めをしておこう。プロダクトマネージャーは、エンジニアリングチームのキャパシティ全体の20% を空けておぃて、これをエンジニアリングチームの判断で使える予備の枠として与える。エンジニアリングチームは、たとえば、コードを書き直したり、アーキテクチャをやり直したり、コードのダメなところをリファクタリングしたり、データベースのシステムを入れ換えたり、システムのパフォーマンスを改善したり、といった作業のためにこの枠を使うことができる。つまり、「開発を中断してコードを書き直さなければだめだ」と言い出す事態を避けるために必要だと思うことであれば、何でも、この枠を使って手を打っておくのだ。
(引用終了)

システムのリプレース案件が最も危険な理由: プログラマの思索にも書いたが、ジョエルも同じ事を言っていた。
プログラムの保守性や移植性が落ちた場合、アーキテクチャが時代に追いつけず古くなってしまった場合が上記の状況に相当するだろう。
製品の品質やアーキテクチャが古くなってその重みに耐え切れなくなる前に、リファクタリングするリソースをあらかじめ確保して、少しずつ改善できるような環境を作っておく。

【6】第7章 プロダクトマネージャーを管理する方法 ≪ Inspired日本語版

プロダクトマネジメントチームを組織する
Scrumでプロダクトオーナーの役割を持つ人達が多い場合、一つのチームを作るのと同じ。

プロダクトマネージャーをどうやって評価するか?
ネットプロモータースコア (NPS)
推奨者 (プロモーター)に評価してもらい、結果を収集する。
リーンスタートアップにおけるMVPの評価方法に重なる。
新しいビジネスには新しい評価方法が必要。

【7】第20章 必要最小限までそぎ落とされた製品 ≪ Inspired日本語版

機能を減らすか、それとも発売を遅らせるか?

(引用開始)
ここで、まったく別のやり方を提案しよう。
第一に、プロダクトマネージャーがまずやることは、デザイナーと協力して、その製品としての目的を達成するために必要最小限の機能を備えたハイフィデリティプロトタイプ (製品の正式版が正確にイメージできる試作品) を作ることである。
(中略)
第二に、デザインが始まる当初から、エンジニアリングチームからもだれか加わってもらって (普通はアーキテクトか主任エンジニア)、プロトタイプで表現される製品のアイデアをいっしょにレビューしてもらう必要がある。この人は、プロダクトマネージャーやエンジニアがそれぞれの製品アイデアに必要なコストを把握して、コストの比較をするのを手伝うのである。
(中略)
第三に、現実のターゲットユーザーとともにプロトタイプの検証を行うことが欠かせない。
(引用終了)

MVPの作り方。ハイフィデリティプロトタイプという考え方。

(引用開始)
こういうわけで、いったん必要最小限の機能の製品を定義して、ターゲットユーザーといっしょに検証を続けて、これでうまくいくという確証が得られたら、その後はもう機能のどれかを落とすことはできないし、また、それをやってもユーザーからはお墨付きをもらえるなどと思ってはいけない。もしこれができるとすれば、実は、そもそも初めから必要最小限の機能の製品にはなっていなかったということだ。
それでもまだ、難しい決断をしなければならない場面は出てくるだろう。よくあるのは、機能の中のあるものについて、予想よりも実装に時間がかかるという場合だ。でも、私がここで説明しているモデルでは、機能を減らすのではなく、スケジュールをずらすのがまっとうな対応である。とっくに機能は必要最小限までそぎ落としてしまっていることを思い出してほしい。このモデルのいいところは、他のよくある手法に比べて、見積りが正確だということである。
(引用終了)

MVPがなぜ良いのか?
機能は必要最低限まで落とされているので、見積りが正確になりやすいこと。
実際に作ってみたら、とても難しいことが分かっても、それ以上の機能を減らすことができない。
実際にMVPの開発が始まると、プロダクトマネージャすらも簡単に機能追加することはできない。

【8】第26章 アジャイル開発手法を使いこなす ≪ Inspired日本語版

プロダクトマネージャーは、プロダクトオーナーの役割を兼ねる。
製品計画は必要。
プロダクトマネージャーとデザイナーは、いつも1つか2つ先行したスプリントを計画しておく。

(引用開始)
プロダクトマネージャー兼プロダクトオーナーの中心的な役割として、価値があって使いやすいプロトタイプとユーザーストーリー (ユーザーの要求事項を文章の形で記述したもの) を用意することがある。これらは、製品開発チームが開発を進める出発点となるのだ。大げさな PRD (製品要求仕様) や機能仕様書ではなくて、プロトタイプとユーザーストーリーがいいのだ。
(引用終了)

プロダクトマネージャの仕事は、ばかでかい製品仕様書ではなく、プロトタイプ仕様とユーザストーリーを用意すること。

プロダクトマネージャー兼プロダクトオーナーとインタラクションデザイナーは、毎日の進捗報告会議 (スタンドアップ、あるいは、デイリースクラムとも言う) に欠かさず出席する。

初期のスプリント(いわゆるアーキテクチャスパイク、アーキテクチャ助走路)はプロトタイプの代わりにならない。

(引用開始)
スクラムのようなアジャイル開発手法を使えば、ソフトウェアチームを何十年間も悩ませ続けた主な問題のいくつかが解消される。でも、多くのプロダクトマネージャーやユーザーエクスペリエンスデザイナーが、そして多くとまでは言わないけれど品質保証マネージャーも、最初のうちはアジャイルに戸惑い、自分の役割はこの手法の中ではどうなるのか、と頭を抱えている。はっきりさせておくと、アジャイル開発手法では、こうした人たちの役割は間違いなく必要だとされているのだけれど、私は、アジャイル開発手法の由来のせいでこういう混乱が起きているのだと思う。だから、その由来を説明すると、アジャイルがどういう問題を解決しようとしているのか、そしてどういう課題が残っているのかが明確になるようだ。
(引用終了)

アジャイル開発はカスタムソフトウェア製品の世界から生まれた。
アジャイル開発が生まれる前はウォーターフォール型開発が主流であり、幾つかの問題があった。

(引用開始)
顧客は何が欲しいのかを自分で理解していると思い込んでいるので、プロダクトマネージャーがやるべきことはほとんど見当たらない。同じように、ユーザーエクスペリエンスデザイナーの役割も見当たらない。
そして、カスタムソフトのプロジェクトの大多数は、比較的規模が小さく、社内の業務支援を目的にしているため、ユーザーの数は限定されていて、システムの拡張性や性能といった問題はあまり重要ではない。
(中略)
その問題に対し、アジャイル開発は、客とエンジニアの間のコミュニケーションがよくなるし、小回りの利くプロトタイプを作って試すというのを何度も何度も繰り返すことによって、製品開発のリスクをぐんと減らすことができる。
フトウェアをテストするための最新の考え方を取り入れるのにも役に立つし、製品開発チームとしても、めったに読んでもらえないうえにすぐに使い物にならなくなってしまう書類を作るのに膨大な時間をつぎ込まなくてすむ。
(引用終了)

しかし、製品ソフトウェアにアジャイル開発を導入する場合、ユーザーエクスペリエンスデザインを開発プロセスに取り込むか、プロダクトマネージャーはどんな役割になるか、例えば大規模なインターネットサービスに対するアーキテクチャデザインをどのように開発プロセスに取り込むか、という点はいくつか修正する必要がある、と。

| | コメント (0)

2012/09/16

プロジェクト管理のアンチパターン集~アドレナリンジャンキー

アドレナリンジャンキー」を立ち読みしたら、あまりにも面白くて購入した。
この本は、デマルコが書いたプロジェクト管理のアンチパターン集と言って良い本だ。

【元ネタ】
プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」: わたしが知らないスゴ本は、きっとあなたが読んでいる

アル中ハイマーの独り言: "アドレナリンジャンキー" Tom DeMarco 他著

アドレナリンジャンキー: わく☆すたブログ

プロジェクトマネジメントのグル「トム・デマルコ」の集大成 - ビジネス書の杜

実際のソフトウェア開発のプロジェクトは、右往左往しがちなものだ。
現場の当人は一生懸命に働いているが、第三者から見れば、滑稽に見える時も少なくない。
アドレナリンジャンキー」でいくつか面白いと思ったアンチパターンをあげておく。

死んだ魚:
プロジェクトが始まった日から、そのプロジェクトは死んでいると誰もが気づいているのに、誰も言わない。
よくある例は、要件定義で何となくヤバそうな雰囲気を感じ取り、設計・開発で苦労しながら完了後、結合テストで一気に火を噴くパターンが多い。

レミングサイクル:
プロセスには調整しろと書いているのに、チームは調整しない標準プロセスを守り続ける。
CMMIやISO、最近なら個人情報保護や内部統制など、無駄な管理作業にかなりの労力を取られていないか?
欧米企業や中韓企業を見ていると、日本企業はビジネスのスピードを落とす作業に一生懸命に力を入れ過ぎている気がする。

ダッシュボード:
強いチームと弱いチームが使うが、並のチームは使わない。
ダッシュボードによる見える化の効果を知っているチームは少ない。

永遠の議論:
いつまでも不満を訴える権利を与えていては、議論は終わらない。
プロジェクト末期になるほど、こういうミーティングが増えて、打合せだけの時間がどんどん長くなる。

アトラス:
リーダーがあらゆることに長けている。
リーダーが仕事を抱えすぎて、リーダー自身がボトルネックになっている。
そういうチームはスケーラブルでなく、リーダーが倒れたらチームは機能不全になる。(トラックナンバー1)

ソビエト式:
完成した製品は顧客が要求した機能を全て揃えているが、嫌われてすぐに捨てられる。
リーンスタートアップに出てくるMVP(実用最低限の機能を持つ製品)とは真反対だ。

ポーカーの夕べ:
職務に関係のない活動のために、組織のあちこちから人が集まる。
休憩室や喫煙室が相当するだろうか?
東京在住の折、ゲーム会社で勉強会が開催されていた時、その場所では、等身大のアニメ・キャラクターが飾られ、その隣にはカップヌードルからお菓子、ジュースまでがカウンターバーに置かれていたのを思い出す。
社員が自然に談話できる場を故意に作っていたのだろう。

明日には日が昇る:
マネージャは、将来の進捗の平均は過去の進捗の平均を上回ると信じている。
マネージャは、見積りする時、開発者の成長度合いも計算に入れている。
同じプロジェクトに3ヶ月もいれば、技術も人間関係にも慣れて、アウトプットの量も開発速度も増えるだろう、と。
だが、幸運も不運も平均的に訪れるとすれば、いつも順調とは限らない。
XPには生産性に関して「昨日の天気」という考え方がある。
次のイテレーションの生産性は、直近のイテレーションの生産性と同程度だろう、と。

変更の季節:
プロジェクト期間中に何度か、スコープを変更するタイミングが訪れる。
そのタイミングは普通は、イテレーションの切れ目にある。

こういう本は気軽に読めるし、考えるほど奥も深い。

| | コメント (0)

2012/09/14

RedmineのER図

RedmineのER図を作る方法が公開されていたのでメモ。

【元ネタ】
redmineのER図を生成してみた | ぷろぐらま

Railsのテーブル名や主キーは、CoCで厳格なルールがあるおかげで可読性も高い。
だから、Redmineもこれだけの頻繁なVerUp、豊富な機能改善が可能だったのだろうと思う。

Railsの最大の特徴である「サロゲートキーの重視」については、渡辺さんが下記の記事を書かれている。

「強制されたサロゲートキー」の事例を眺める: 設計者の発言

複合キーをなくしサロゲートキーに統一する手法では、ER図に親子関係が発生せず、全ては外部キーによる参照関係になる。
多分、普通のRails開発では、テーブル間のリレーションシップはアプリケーション層で実装するだろう。
つまり、DBMSでリレーションを貼ることはしないので、テーブルは入れ物にすぎない。

DOAの立場の人がサロゲートキーに違和感がある理由は、親子関係という基本的なリレーションシップがなくななるため、データモデルの表現力が落ちてしまうからだ。

だが、Railsがサロゲートキー一辺倒にした理由の一つは、HTTPのURIをRESTで書けるようにしたいから。
URLがDBのCRUDに対応するように書ける。

SOAPからRESTへ: プログラマの思索

Railsの思想から言えば、サロゲートキーは単なるデータモデルだけでなく、HTTPアクセスのURLはCRUDであるべきというREST思想にも基づく観点があるからこそ、サロゲートキーだけのデータモデルでもWebシステムで特に有効なのだと思っている。

だから「サロゲートキーは必要なのか、不要なのか」という議論は不要で、個人的には、分析(概念)モデルと実装モデルの違いに過ぎないと思っている。
例えば、OOAでも概念モデルでは、注文と注文明細を区別せず、一つのオブジェクトで表現して、荒い粒度でモデルのあるべき姿を描き、実装モデルはソースに近いレベルの粒度故に、たくさんのオブジェクトが表現される。

つまり、DOAでも、分析者が見るレベルのモデルと、開発者が実際に使うレベルのモデルで区別してもいいはず。
そもそも、ユーザ(顧客)観点のモデルと開発者の観点のモデルは粒度が大きく異なるのは、外部設計・内部設計、基本設計・詳細設計というWF型開発の工程による区別からしても、自然な考え方だ。

でも、DOAの前提では、モデルは唯一つであり、分析者も開発者も同じER図を見るから、ロールによるモデルの区別は存在しない。
だから、そのような不毛な議論が発生するのだろうと思う。

とはいえ、Railsの普及によって、DOAの重要性は以前よりも増していると考えている。
何故ならば、きちんとテーブル設計さえできれば、Railsのマイグレーション機能によって一発でCRUD画面を作れてしまうからだ。
Redmineがこれだけ豊富なプラグインを持つ理由の一つは、Redmineのデータモデルがシンプルであるだけでなく、テーブル設計が非常に優れているため、機能拡張しやすいのだろうと推測している。

色々考える。

| | コメント (0)

2012/09/12

チケット駆動開発が進むべき道part5~Agile開発プロセスとして再構築する

チケット駆動開発本の感想を読んで、チケット駆動開発が進むべき道について考えたことをメモ。

【1】Twitter / SugiTK: Redmineの使い方なのかチケットの運用の仕方なのかというのも微妙な立ち位置になってしまってるかなと。例に挙げられていたERPの話と同様に、ツールをRedmineにすると決めたならそれに合わせて業務も変わるわけで、Redmineならこうしますというほうが。それは前著ですか…

Twitter / SugiTK: アンチパターン集は読みやすかったです。パターンテンプレートに沿っていたからでしょうか。既存のいい見本があると見やすくなるということはあるのかもしれませんね。

Twitter / SugiTK: 12章。「テーラリング」という単語はあまり一般的ではないのではなかろうかと。新卒のときの研修でPMBOKやQCのプロセスについてテーラリングするというのを部長から教わったのをなぜかよく覚えていますが、その後10年以上聞いたことがありません。

Twitter / SugiTK: 読後感としては「う?ん」と悩んでしまいました。本を書くのはやはり難しいんだなぁと。わたしは雑誌記事を10回程度しか経験がないですが、相当に大変でした。知っていることを全て表現できるわけでもなく、書いたことが全部伝わるわけでもない。難しいです。

【2】チケット駆動開発の感想 - ブクログ

宝探しが必要な本です。自分が深く関わったことがある部分に対しては、この本に書かれているノウハウがとスッっと入ってきてとても参考になったのですが、経験が浅い部分については何がポイントなのか、、、話が散逸していてよく分かりませんでした。
「プロジェクト管理の原理原則」、「チケット駆動開発により改善が進むポイント」、「実践のノウハウと実例(ツール)」と大きく3部に分けて整理し直すだけでものすごく良い本になるのではと思います。
手元に置いておいて、プロジェクトマネジメントで悩んだ時に、部分的に読み返すという使い方が良いかもしれません。

【3】Amazon.co.jp: チケット駆動開発
(引用開始)
導入部はよく書けていて期待が膨らんだが、完全に裏切られた。厳しいレビューとなりますがご容赦。

まるで思いつきを思いついた順に並べたような本だ。これではひとつの開発方法論という以前に、一冊の技術書として成立していないと思う。
全体がうまく構成されていないし、各論も要点が全く整理されておらず、何が言いたいのか不明な部分が多い。
技術的な誤りも多い。著者らの前著も突っ込み所満載といった印象だったが、この本はそれ以上にひどい。
同じことを何度も繰り返しつつ、ほかの文章を適当に引用してはいい加減な論評を繰り返し、脈絡なく「チケット駆動はこれを改善するでしょう」などと結ぶばかり。
自分が開発するシステムの仕様書がこんなふうに書かれていたら、私は激怒すると思う。

第一、BTSとSCMが連携する開発支援ツールはMicrosoftやPerforce、Rationalなどがずっと以前からリリースしているしこの本を読む限り、「チケット駆動」というのがBTS/ITSの新しい活用法を編み出したとは見えない。
これだけ厚い本なのに、「BTS/ITSを活用しましょう」という以上のメッセージは読み取れなかった。

著者らは、「チケット駆動」というわかりやすい言葉で、日本のソフトウェア業界にBTS/ITSの導入を啓蒙した。その大きな貢献は否定しない。
(そんなところから啓蒙しなくちゃいけない日本の業界もどうかとは思うが)
しかし、この本はあまりに技術書としての体裁を欠いている。ブログじゃないんだから。もう少し、まともな本に仕上げてほしかった。
これでは「チケット駆動」とは名前負けの看板倒れ、中身は何もないと言われても仕方がないだろう。
チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか。

次回は、要点だけをコンパクトにまとめた、現場でリファレンスとして使える本を期待したい。(日本発の開発方法論として、まだ期待してるんですよ。)
せめて、目次を見たらどこに何が書いてあるのかわかる程度には、内容を整理すべきだろう。
業界からの「チケット駆動」に対する期待と、著者らの業界に対する影響力の大きさを考慮して-1点。
(引用終了)

(引用開始)
障害管理、構成管理、アジャイル、SCMなどなど、幅広い内容が分散して書かれているため、チケット駆動開発の本質的なところ(この本が伝えたいこと)がよくわからない。

チケット駆動開発の基本のところで説明している内容を、ブレークダウンしていくつかのパターンに分類していってくれたら良かったのにと思います。
チケット駆動開発によってアジャイルが分かったとあったので、書籍もアジャイルにリファクタリングしながらつくられたのかと思ったのですが、現状だと寄せ集め感がすごくあるので、個々ではよいことが書いてある箇所はあっても、全体の読後感として、自分の現場でのアプローチに直結しない感じがしちゃう。勿体無い。
(引用終了)

【3】「チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか」という指摘に対しては、「チケット駆動開発」では、6.2節「チケット駆動開発はプラクティス?」の所で既に回答されています。

(引用開始)
チケット駆動開発をどう定義するか、それは難しい問題ですが、必ずしも解決しなくても構わない問題だと思います。できればそのままに広く情報交換して、それぞれのプロジェクトにふさわしい形でチケット駆動開発が実践できるようになればと思っています。
(引用終了)

でも、上記の回答では満足できず、チケット駆動開発の価値・原則・プラクティスを体系化して欲しいという要望に賛同する読者が多いという感想を持ちました。

また、「チケット駆動開発でアジャイルが分かった」と「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の導入部で著者が書いたにもかかわらず、「現状だと寄せ集め感がすごくある」という指摘がありました。

自分としては、前作でチケット駆動によるアジャイル開発技法はほとんど書いたと思っていて、今作では、チケット駆動が障害管理から生まれたが故にその性質が本来のTiDDであることを説明しました。
そして、アジャイル開発に限らず、色んな可能性があることを言いたくて、チケット駆動開発のバリエーションとテーラリングガイドについて色々書きました。
しかしながら、逆に「チケット駆動開発の本質的なところ」が読み取りにくくなったようです。

上記の感想を読んで、「チケット駆動開発でアジャイルが分かった」という著者の体験が体系化されてないために読みにくく、テーラリングガイドよりもチケット駆動開発をアジャイル開発の文脈で体系化して欲しいという要望があるように受け取りました。
確かにその部分はきちんと書けていない部分だと思っています。

また、「Redmineによるタスクマネジメント実践技法」を第5刷まで更新しながら思ったことは、かなり細かな部分まで著者の意図を読み取ろうとしている人が多いことです。
誤字脱字だけでなく、流れからしてこの用語やアクティビティ図は使い方がおかしい、という指摘を台湾の読者から受け取った時もありました。

上記のAmazon感想の仙川さんも、2冊共にすぐに購読して感想をアップしてくれています。
感想の評価は厳しいけれども、きちんと読んでみると、本の内容をかなり詳細な部分まで読んで理解して指摘しているのが分かりました。
(チケット駆動開発に期待して、本の評価を落とすのは変ですが(笑))

【4】「チケット駆動開発をアジャイル開発の文脈で体系化した」場合、どんな方針で考えるべきか?
今は以下の方針を考えている。

一つ目は、チケット駆動開発からツールの説明をなくすこと。
チケット駆動開発を開発プロセスとして体系化する場合、ツールは不要だし、逆に邪魔になる。
運用フローを抽象的に取り出して、フレームワークとして明確に定義してみること。

2つ目は、チケット駆動開発をアジャイル開発の文脈で、価値・原則・プラクティスでフレームワーク化できるか試みること。
価値とは「何が望ましく何がふさわしくないのかという根拠や基準」。つまり価値観。
チケット駆動開発の文脈では、チケット管理の判断基準に相当する。
チケットの取捨選択で、何を基準にして、チケットを登録し、完了しているのか?

原則とは、ドメイン固有の不変な指針。価値とプラクティスをつなぐもの。
プラクティスは、経験に基づいて定義された実践方針。パターン言語を参考にして、プラクティスを「どんな状況(Context)でどんな問題(Problem)に対してどんな解決策(Solution)が有効なのか」を明確にする。
フレームワークは、道具・役割・プロセスの3つの観点。チケット駆動開発を実行するための体制や手続きに相当する。

これらの観点でチケット駆動開発を体系化し、明確にする。

3つ目は、チケット駆動からどんなアジャイルな効果が出てくるのか、そしてアジャイルになる原因をフレームワークから導き出せるかを試みること。
今考えている方針の前提条件は、基本的には、WF型開発などアジャイル開発でない開発プロセスは対象外であり、ソフトウェア開発以外のタスク管理は除く。
つまり、アジャイル開発へ適用したチケット駆動開発について考える。

しかし、これだけ「チケット駆動開発」という概念が広く普及した周囲を見ると、チケット駆動開発の導入によってアジャイルな要素を取り入れたいという動機が多い。
だからこそ、従来型のWF型開発にチケット駆動を導入して、アジャイルな特徴という利点を部分適用したいという考え方を持つ人が多く、注目されているのだろう。

チケット駆動開発の適用範囲: プログラマの思索

チケット駆動開発を開発プロセスとして体系化した場合、何故アジャイルな効果が出てくるのか、その原因を探ってみたい。

4つ目は、XPやScrumなどの他のアジャイル開発と似ている部分と異なる部分を明確に切り分けて、チケット駆動開発を特徴づけること。
そもそも、XPもScrumもFDDも、チケット駆動ではない。
チケットという概念すらない。
あくまでも、チケットをタスクカードのように扱うことで、アジャイルな要素が出てくる特徴はあるが、アジャイルな要素はそれだけではない。
逆に、他のアジャイル開発プロセスにはなく、チケット駆動だけに特有の特徴もあるはず。
その部分を明確に切り分けてみたい。

これらの方針で、チケット駆動開発をアジャイル開発プロセスとして体系化した場合、どんな特徴が出てくるのか見てみたい。

【5】2008年にチケット駆動開発をアジャイル開発へ適用した事例を発表してずっと経つけれど、著者が想像するよりも速いペースで、世間ではチケット駆動開発の概念が進化しているように思う。

例えば、PivotalTrackerならば、よりアジャイルなチケット管理がやりやすい。
僕も実際に使ってみて、その良さは何となく分かった。
「No Tikcet, No Commit」がなくても、十分にアジャイルな特徴がある。

例えば、GitやMercurialとRedmineを連携した使い方は、著者の想像以上に発展している。
そもそも「No Tikcet, No Commit」の運用ルールは、Trac+Subversionの環境で生まれたからこそ、逆に、GitやMercurialでは、その運用ルールが古くなっている部分がある。
プライベートブランチまで「No Tikcet, No Commit」を適用するのは、開発速度を逆に落とす。

本当は、分散バージョン管理に関する使い方、考え方も「チケット駆動開発」本に書きたかったが、まだ他人に説明できるほど自分は理解できていないのであきらめた。
特に、分散バージョン管理とチケット管理の連携方法は、今後一番可能性がある分野だ。
そして、たくさんの人達が試行錯誤しながら、よりよい使い方を探している。
その使い方、考え方も綺麗に体系化してみたい。

色々考えてみる。

| | コメント (0)

2012/09/11

コミットの粒度

コミットの粒度に関して、とても参考になる記事があったのでリンクしておく。

【元ネタ】
git commit するまえに考えるべき10のこと | Act as Professional - hiroki.jp by HIROCASTER

「git commit するまえに考えるべき10のこと」がDVCS的じゃない件 - うさぎ組

GitやMercurialがCVSやSVNよりも優れている点は、ブランチ管理の容易さと豊富なマージコマンド。
特に、ローカルにブランチを作り、プライベートなブランチとして開発者は好き放題にコミットすればいい。
そして、masterに最終的にコミットする時、必要なパッチのみまとめて送ればいい。

コミット履歴を改変する必要があるのは、masterのコミット履歴を綺麗にする場合だろう。
ローカルのブランチは自分だけが好きなようにコミットしてもいいが、masterのコミット履歴は、その変更意図が分かるような歴史で残すようにしたい。
特に、ソース管理が一人だけの開発者ではなく、大規模システムで複数人の開発者の出入りが激しい場合、ソース管理のコミット履歴はとても重要な情報になる。

「No Ticket, No Commit」はあまりにも厳しいルールという批判を受ける時がある。
コミットする時に逐一チケット番号を書くのは面倒で、プログラミング速度が落ちる、と。

そもそも「No Ticket, No Commit」のルールは、障害管理における変更履歴を残す所から生まれた背景がある。
つまり、障害管理をきちんとしなければならないようなシステム開発であり、開発者がずっとシステムの面倒をみるプロジェクトではない。
ソースは一人だけの開発者の物ではなく、プロジェクトに関わる全員の物だ。
XPのソースの共同所有はそういう発想なのだろう。

だが、皆が関わるブランチ(master)は「No Ticket, No Commit」を守る方が運用保守ではとても効果的だが、ローカルのプライベートブランチまで必要かどうかは言ってはいない。
プライベートブランチは開発者一人だけの物であり、最後に必要なパッチを送る時に、チケット番号も一緒に送ればいいだけだ。

SVNのコミットログの書き方: プログラマの思索にも書いたけれども、特にプログラミング初心者はコミットログを意識して書くようにした方がいい。
そうすれば、コミットの粒度がとても明確になる。
コミットの粒度はよく迷うが、チケットの粒度の考え方と同じ。
コミットの粒度も小さい方がやりやすいが、意味ある大きさでコミットしなければ、逆にコミットが面倒になる。

以前、@yusuke_kokuboさんが、RedmineのメインコミッタであるJPLはコミットの粒度がよく考えられている、と言われていて、なるほどと思う時があった。

Twitter / yusuke_kokubo:RedmineのリポジトリをウォッチしてるとJPLのコミットの粒度の適切さに感心する。Redmineの使い方はredmine.orgに学ぶことが多い。(それにくらべてBacklogsプラグインは…ゴニョゴニョ)
返信 リツイート お気に入りに登録

また、No Ticket, No Commitの効果: プログラマの思索にも書いたけれども、昔のソースほど、無駄なコメントがソースにガラクタのように残っている。
チケット駆動開発でソース管理しているならば、ソースから最終的には全てのコメントは消えて、ソースは必要最低限の機能を実装するものになると思う。
つまり、プログラムの途中で仕様を説明したいならば、コミットログにチケットNoを貼り付けておき、チケットを参照するようにすればいい。
ソースに更新履歴や仕様を説明したコメントは不要だ。

すると、SCMコミットログはファイルのメタ情報: プログラマの思索にも書いたが、コミット履歴は最終的にはソースのメタ情報になる。
つまり、チケットやリポジトリのコミットログは、変更履歴の全文検索の対象であり、ソフトウェア開発の資産(ナレッジ)そのもの。

ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索にも書いたが、ApacheやEclipseのリポジトリのコミットログから、意味ある経験知を見出そうと研究するソフトウェア・リポジトリ・マイニングというソフトウェア工学の手法もある。
こういう研究が可能になったのも、バージョン管理ツールが普及し、オープンソースのツールが商用ツールに匹敵するほど量も質も良くなってきたことがあげられるだろう。

面白い時代だと思う。

| | コメント (0)

2012/09/09

チケット駆動開発を上手に運用するためのポイント

倉貫さんがチケット駆動開発を上手に運用するためのポイントを公開されていたのでメモ。
実際の経験に裏打ちされているだけあって、とても参考になる。

【元ネタ】
チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change!

高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change!

【1】役割分担

(引用開始)
Pivotal Trackerを使う役割はざっくり分けると2つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。
(引用終了)

倉貫さんの指摘では、顧客がプロダクトーナーの役割を持つので、経営戦略から仕様を決定できるストラテジスト、システムの実現可能性も検討できるアーキテクトの役割を持つ。
そのため、プロダクトオーナー自身が仕様(ストーリー)をチケットに登録し、承認する役割も担う。
この考え方で実際のプロジェクトに応用すると、顧客はかなり大きな権限を持つことになる。
ユーザ企業がSIに丸投げするような受託開発では、多分運用できない。

RedmineなどのITSでは、管理者・開発者・報告者のロールが普通だ。
管理者はITSそのものの管理者だったり、チケット管理の最終責任者の役割を持ち、普通はプロジェクトリーダーが相当するだろう。
開発者ロールは、開発チームのメンバーに相当する。
報告者ロールは、障害報告や機能改善の要望をフィードバックする役割を持つ。

つまり、既存のITSのロールでは、顧客に相当する役割は報告者ロールという受け身の役割しかない。
顧客自身が要件や仕様を決めて、それらをタスクに細分化する所までの権限を持たせるならば、管理者ロールも必要になるだろう。

そもそもITSは障害管理から発展してきた経緯ゆえに、チーム外にいる顧客(プロダクトオーナー)や会社の上司(プロジェクトオーナー)はITSに関わらないのが前提になっている。
チケット駆動開発で弱い部分があるとすれば、チーム外にいるプロダクトーナーやプロジェクトオーナーをどのようなロールに当てはめて、チケット管理をどのように運用したらよいか、をプロセス化してITSへ実装する必要があるだろうと思う。

(引用開始)
ソニックガーデンの場合だと、youRoomを使って常時コミュニケーションをとれるようにしていて、youRoom上でのディスカッションの結果、チケット化することが多いです。私たちはチケット化することを「Pivo化」と呼んでいます。
(引用終了)

チケットとは別の機能で、タスクという観点ではなく、ラフなアイデアを元に議論した結果をチケット化する運用も出てくる。
この時、チケットと過去の議論を連携できるようにしておけば、後からWebで検索できるから、理解しやすくなる利点がある。

redmine.orgの運用を見ると、フォーラムで議論した結果、新しい機能を追加して欲しいとか、こんなプラグインがあったらいいな、など、色んなアイデアがチケットへタスク化される運用になっている。
僕のチームでは、phpBBという掲示板システムで別に議論していたり、QAや気づきというチケットで議論するようにしたが、多分色んなやり方があるだろう。

Rxtstudyの感想: プログラマの思索

【2】チケットの粒度

(引用開始)
ソニックガーデンでの基本的なルールは、プロダクトオーナーにとって意味のある粒度にする、ということです。どんなチケットもプロダクトオーナーが最終的には「Accept」か「Reject」する訳なので、そこが判断できることがチケットの絶対条件になります。
なのでチケットを切る際のポイントは「Accept」の条件が何かを、プログラマと合意しておくということです。その上で、なるべくチケットの単位を小さくするようにします。
(引用終了)

チケットの粒度の問題は、チケットの完了条件に密接に関わる。
Scrumで言う「Doneの条件」に相当するだろう。
チケットをスムーズに完了できるようにするには、チケットのスコープは小さい方がやりやすい。
チケットに書かれた作業内容が小さいほど、完了できたのか、未完了なのか、の判断はつきやすいからだ。

上記の指摘で興味深いのは、「プロダクトオーナーにとって意味のある粒度にする」という点だ。
つまり、顧客視点の粒度にするため、開発者視点の作業内容や作業スコープにはならない。
「A001~プログラムを実装する」などのチケットではなく「注文ボタンを押下する時に~という警告メッセージを出す」というチケットのように、ユーザ視点の内容になるだろう。

但し、上記の記事では、チケットの粒度がどうしても大きい場合、開発者視点のチケットはTASKSで子チケット化する運用をしているようだ。
Redmineなら親チケット=ストーリーカードのタスク、子チケット=タスクカードのような視点になるだろう。

また、ユーザ視点ではないものの、アーキテクチャ上どうしても必要なチケットは、Choreというカテゴリで追加する運用をしているらしい。
実際、ビルド環境を作る、フレームワークのVerUpに対応する、テストのために移行データを準備する、などのようにユーザ観点の機能レベルではなく、開発をスムーズに行うために必要なタスクは多い。
その場合、チケットのカテゴリという属性で、ユーザ観点ではないタスクを登録する運用にしているらしい。

僕のチームでは、上記のような状況では「管理」「準備」などのトラッカー(チケットのワークフローの単位)を作って運用していたが、チケットのワークフローは普通のタスクと同じなので、まどろこしかった。
だから、倉貫さんのような運用の方がやりやすいように思う。

【3】チケットを仕様にしない

(引用開始)
ソニックガーデンでは仕様はソースコードだとしています。チケットを仕様にしていません。チケットはあくまでこれから作ろうとする作業について書かれているだけです。その瞬間は仕様かもしれませんが、ソースコードに落とし込んで、アクセプトされた瞬間に正しい仕様はソースコードになるというイメージです。
もし、仕様をソースコードとは別で管理したいというのであれば、それはチケットとは別の仕様書という形で別のドキュメントを用意すると良いでしょう。あくまでチケットは前に進めるためのもので、正しさや厳密さを求めるものではない、というスタンスでいます。
(引用終了)

チケットをストーリーカードとして扱う場合、チケットに仕様を書いてしまいがちだが、あくまでどんなタスクなのかに注力して書いて運用するほうが良いという指摘。
僕はチケットをXPのタスクカードのように扱う運用が一番スムーズと思っているが、ストーリーカードとして扱う場合も細かな仕様はチケットではなく別のドキュメントないしWikiにまとめて参照する方が良いのだろう。

(引用開始)
プログラマにとっては、書かれた通りに作ることよりも、なぜ必要なのかを知った上で実現方法を考えながら作る方がクリエイティブですし、実際に作られるものも、本質的に価値のあるものができあがります。チケットになる前のWhyが重要です。
(引用終了)

チケット駆動開発がスムーズに運用できるようになると、ソース修正の時に過去の変更履歴を開発者自ら調査してくれるようになる。
ITSは全文検索機能が強力だし、チケットとソースのリビジョンが連携する機能もあるから、変更履歴を追跡できる環境が揃っているからだ。
システム開発のほとんどの作業は仕様を詰めていく作業であり、仕様を確定するには、何故そんな仕様になったのか、という経緯を踏まえる必要があり、それが変更管理というプロセスになる。
チケット駆動開発は、変更管理を強化してくれるインフラなのだ。

(引用開始)
厳密性とは少し異なりますが、どれだけのチケットをすることで全体像のうち、どこまでが進んでいるのかを知るための機能として、Pivotal Trackerには「EPICS」というものがあります。これは、最近追加された機能で、これまではラベルで表現していたものを一覧で見えるようにしたものです。
EPICSには大きめの機能群として登録しておき、そこにチケットを紐づけていくことで、それぞれの機能群がどれだけ進んでいるか、消化されたチケットと消化されていないチケットでわかるようになっています。
(引用終了)

アジャイルな見積りと計画づくり」では、ストーリーの種類として、エピックやテーマが紹介されている。
エピックは、ストーリーより大きな粒度のストーリー(叙事詩、大長編)。
テーマは、リリース計画で見積りしやすくするために、複数のストーリーをまとめたもの。
上記の運用を推測すると、より大きなストーリー(機能)の単位で関連するストーリーのチケットをまとめておき、後から進捗が分かりやすくする運用なのだろう。
つまり、エピックとテーマの機能を兼ねたものと思える。

そして、Pivotal Trackerがエピックやテーマの機能をチケットの一属性として実現しているのが興味深い。
つまり、チケットの親子関係という複雑な機能ではなく、チケットの属性として集計できる仕組みにしている。
チケットの属性による集計の方が簡単だし、後から修正するのも楽だ。

【4】とにかく前に進める

(引用開始)
また、プログラマ側も完璧を目指すよりも前に進むことを重視します。チケットのWhyを理解して、その目的がほぼ達成できるのであれば、そのチケットの詳細にこだわって100%にするために時間をかけすぎなくて良いと判断します。80%くらいが着地点でしょう。
では残りの20%はどうするのか。これもまた別のチケットとして登録します。プログラマが自主的に分割して別のチケットにする訳です。分割したことをプロダクトオーナーと確認して、納得のいくレベルを目指して着地させる訳です。残りの20%のチケットはアイスボックスに入れておけばよくて、おそらく実装することはないでしょう。
Pivotal Trackerの特徴の一つは「アイスボックス」と呼ばれる一覧があることです。アイスボックスに何をいれるかというと、仕様が固まっていないものや、これから先やりたいと思っていることなど、つまり何でも入れていい訳です。逆に仕様が固まってもいないのにバックログに入れるのは良くないですね。プログラマが作業できないからです。
(引用終了)

上記の運用では、開発のスピードを重視するために、チケットの完了基準をやや緩めているようだ。
チケットの完了基準をきちんと守るのは、実際の運用では結構難しい。
【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索では、チケットの完了基準が曖昧なアンチパターンとして「停滞したチケット」を記載した。
例えば、進捗率が90%のまま停滞しており、いつまで経ってもチケットを完了できない状況(コンテキスト)に相当する。

その原因の殆どは、リファクタリングと新規機能の追加の作業が混じっているために当初の見積よりも工数がかかってしまったり、機能はほぼ動く所まで完了しているのに細かな仕様の不明点が残っているために完了できない場合が多い。
だから、チケットを分割したり、仕様の不明点は課題チケットとして別に切り出して、元のチケットはCloseさせるという運用を行ったりする。

上記の指摘では、残りの20%の不明点はアイスボックスにチケットとして入れ、必要になるまで放置する運用を勧めている。
この運用方法は、現実的な運用だと思う。
結局、チケット管理で何を価値とするか、という価値観に基づくから。
上記の運用方法では、現場のルールにこだわってガチガチに守るよりも、シンプルに運用して「価値あるソフトウェアをいち早く届けること」を重視している。

以上の考え方もチケット駆動開発のブラッシュアップに役立ててみる。

| | コメント (0)

2012/09/08

XPやScrum、PFにおける価値はどんな効用を持つのか?

XPの価値と原則の理解を読んで、XPやScrumに出てくる価値の意味が恥ずかしながらようやく分かった。
考えたことをメモ書き。

【元ネタ】
XPの価値と原則の理解

- eXtreme Programmingの魅力を探る

スクラム組んで開発しよう!

チーム一丸となって顧客要望に向かって進む ─ Scrum ─|ニューインテリジェンス|アジャイルジャパン公式サイト

- プロジェクトファシリテーションTOP

XPは「コミュニケーション」「シンプル」「フィードバック」「勇気」の4つの価値を持つ。(「XPエクストリーム・プログラミング入門」第2版では「尊重」も加わった)
Scrumでは「コミットメント」「専念(集中)」「オープン」「尊敬」「勇気」の5つの価値を持つ。
プロジェクトファシリテーションでは「対話」「行動」「気づき」「信頼関係」「笑顔」の5つの価値を持つ。

何故、価値がプロセスの最初にあり、重要なのか?
その理由は「XPエクストリーム・プログラミング入門 第2版」の第3章に書かれている。

(引用開始)
書籍から手早く園芸の基本技術を学習することはできるが、 だからといって園芸家になれるわけではない。 私の友人のポールは、園芸家である。 私は土を掘り、植物を植え、水をやり、雑草を取り除くが園芸家ではない。
ポールと私との違いは何だろうか。 まず、ポールは私よりも技術に詳しい。 どちらも知っている技術を行なう場合はポールの方が上手である。 何かを掘ったり植えるといった作業がなければ 園芸を行なっていることにならないので、技術は重要だ。 このレベルの知識と理解をプラクティスと呼ぶ。 プラクティスとは、何かを実際に行なうことである。 そして、日々行なうことである。
......ポールと同じ園芸プラクティスを理解していたとしても、 私は園芸家にはなれない。 ポールは、園芸で何がよくて何が悪いかについての感覚がとても発達している。 庭全体を眺めて、何が機能し何が機能していないか直観でわかるのだ。 私が枝を正確に刈り込む能力に誇りを持っているとしたら、 ポールは木全体をどのようにすべきかわかるのだ。 その理由は、ポールが私よりも優れた剪定師だからではなく、 ポールは庭での作業において全体を捉える力があるからだ。 ポールにとってシンプルで明確なことでも私はわざわざ勉強する必要がある。
このレベルの知識と理解を価値と呼ぶ。 価値は、ある状況で何が望ましく、何が望ましくないかの根拠である。
......価値がないと、プラクティスはそれ自体のために機械的に実施され、 目的や方向性が欠けてしまう。 したがって、価値を明示することは重要だ。 プログラマが欠陥を無視した場合は、技術ではなく価値に問題がある。 欠陥自体は技術の問題かも知れないが、 欠陥から教訓を得ようとしないのは プログラマが実際には学習と自己改善を重視していない表れである。
......価値とプラクティスの隔たりを埋めるのが原則である。 原則は領域固有の指針で、いつまでも変わることはない。 ポールの園芸家としての知識は、 原則レベルでも私を上回っている。 私がイチゴの隣にマリゴールドを植えることを知っていたとしても、 ポールは隣り合った植物が互いの欠点を補うという 共栄植物を植えることの原則を理解している。 マリゴールドは、イチゴを食べる一部の害虫が発生するのを自然に防ぐ。 イチゴとマリゴールドを一緒に植えることがプラクティスである。 共栄植物を植えることが原則である。
......これが1冊の本で私が伝えることのできる限界である。
ケント・ベック
XPエクストリーム・プログラミング入門 第2版」より
(引用終了)

価値とは、行動の善し悪しを決める判断基準、価値観である。
今、自分は本当にこの作業をすべきなのか?と迷うとき、XPを実践しているならXPの価値に照らし合わせて、やるかやらないか、別の方法を試すか、判断を下す。
ScrumもPFも同様だ。

古くから言われる「ドキュメントを書くことは必要か?」という質問は、XPの価値である「コミュニケーション」「シンプル」に照らし合わせて、現場の文脈よりもチームと自分が判断すれば良い。
「コミュニケーション」の価値を重視するならドキュメントを詳細に書くし、「シンプル」の価値を重視するなら、必要最低限のドキュメントで残し手間をかけ過ぎない。

価値は原則やプラクティスの源である。
価値なくして、プラクティスを実践しても意味が無い。
プラクティスを実践して作業を阻む障害にぶつかった時、自分が今までやってきた作業が正しいのか悪いのか、価値に照らし合わせなければ判断の下しようがない。
価値観に沿っているならば、たとえ障害にぶつかったとしても、価値観のおかげで自分の行動の正当性が保証され、勇気(XPの勇気、Scrumの勇気)が出てくるだろう。

自分は今まで「テーラリング」という言葉を何気なしに使ってきたけれど、「チケット駆動開発」本を出版してから、この言葉を使うのにすごく違和感を感じるようになった。
その違和感の理由を探すために、Togetterでまとめたみた。

チケット駆動開発のテーラリング - Togetter

Twitter / akipii: 平鍋さんが提唱されたPFはアジャイル開発の日本風なテーラリングなのか?多分違う。平鍋さんはアジャイルのエッセンスを深く理解されていて、そのエッセンスをチームビルディングのプラクティス集として抽出した。PFを編み出すためにフィットギャップ分析や都合のよい解釈をしたわけではないはず

Twitter / akipii: @sugimoto_kei はいアジャイル開発は標準プロセスのテーラリングでは断じてなく、プラクティスというパターンの組み合わせから発生すると思うのです。チケット駆動開発も同じ文脈で説明するようにしたいです。

その理由を探していて、テーラリングには価値という価値判断の基準が存在しないから、と気づいた。
プロセスを現場に合わせてテーラリングする場合、プロセスが重視する価値を無視して、現場の既存の運用を残してしまうために、中途半端な効果しか出ないからだ。

また「開発現場に合わせて、そのコンテキストでカスタマイズすればいい」という言葉もよく使っていたけれど、「コンテキスト」という言葉にすごく違和感を感じるようになった。
その理由は、どの開発現場も独自の状況があり、アジャイル開発であれ結局、一部の導入だけ試して満足してしまう事例が多いから。
つまり、現場のコンテキストを重視するがゆえに、アジャイル開発に対して都合の良い解釈をしてしまい、アジャイル開発が持つ価値(本来のあるべき姿)がうやむやになってしまいがちだから。

開発プロセスの導入は、現場の既存のコンテキストの背後にある、今までの現場の価値観を打ち崩す破壊力がある。
Scrumでは特に、Scrumの運用が順調に進んで継続的に開発を阻害する要因を改善していくに従って、「組織的な阻害要因(Organization Inpediment)」にぶち当たり、最終的には組織と緊張関係に陥る所まで行き着くという。
この辺りの解説は、細谷さんの記事「スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebook」がとても分かりやすい。

だからこそ、プロセスの導入は、従来の組織に緊張関係を与えない程度に部分的な効果にとどまるか、組織自身がそのプロセス(XP・Scrum・PF)の価値を取り入れて自己変身するかのいずれかしか選択肢がない。

「コンテキスト」「テーラリング」という言葉は、ソフトウェア開発のあるべき価値観を曖昧にしてしまう毒薬が含まれていると思う。

チケット駆動開発」のAmazon書評に「チケット駆動とは何か、何を価値とするのか、単純な原則を抽出して改めて体系づけ直すべきではないか。」という指摘があり、この指摘を今は真剣に考えている。
最近の僕が、パターン言語について調査して思索している理由の一つは、アジャイル開発の価値・原則・プラクティスを生み出した背景にはパターン言語があり、そのアイデアを使ってチケット駆動開発を体系化できないか、色々考えているから。
近いうちに公開してみるつもりです。

| | コメント (0)

2012/09/06

アジャイル手法が設計技法にも浸透しつつある

平鍋さんの記事「データモデリングなきアジャイル開発は危ういか?:An Agile Way:ITmedia オルタナティブ・ブログ」がとても分かりやすかったのでメモ。

【元ネタ】
データモデリングなきアジャイル開発は危ういか?:An Agile Way:ITmedia オルタナティブ・ブログ

Twitter / akipii: とても良い記事。昔ながらの設計技法が古くなっている事実を認識すべき RT @hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか?」 http://bit.ly/UsO1aA

Twitter / yusuke_arclamp: アーキテクチャ設計の生成パターンは良いのがないんだよね。結局、プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて。

Twitter / akipii: 愚直にストーリーカードをソースへ変換して改善する方法しか見いだせていない RT @yusuke_arclamp アーキテクチャ設計の生成パターンは良いのがないんだよね。結局プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて

Twitter / akipii:@sugimoto_kei @yusuke_arclampさんの意図は、アーキテクチャ設計には再利用可能なレベルのパターンはまだ存在しない。それ故にアジャイル開発のようなリスク回避のマネジメント手法でしか解決できないという意味だと思います。DOAも多分そのレベルではないのでしょう

Twitter / yusuke_arclamp: @sugimoto_kei @akipii リファクタリングは広範囲に影響を与える要素(利用者の多いDBやI/F)の変更には向かないというのが一般論です。横断的な要素の設計は事前にやるべきでしょうね。

Twitter / ItagakiShintaro: この辺、Unified Processで整理ついてんじゃ?アジャイリストはプロセス重視のUPは嫌いだから参考にしない? "@hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか?」 http://bit.ly/UsO1aA "

アジャイル開発でも、フィーチャ駆動開発(FDD)やドメイン駆動設計(DDD)のように概念モデルを事前に作ってから開発していく開発プロセスは以前から主張されている。
だから、DOAでも同様の傾向は言えると思う。

平鍋さんの記事で面白いのは以下の部分だ。

(引用開始)
最後の但し書きについて一言。
高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い。たとえば、インフラアーキテクチャの選定と構成は、クラウドが出てから本当に劇的に変わった。先日、AWSの玉川さんと話していて分かったのだが、いまや、机上の推定と計算でインフラの構成を決めているなんて時代遅れだ。クラウドでは、マシンやロードバランサー、コア数やCPUスペックまで、プログラムのように変更できる。すなわち、変更可能性が飛躍的に向上した。こうなると、「緻密に設計する」のではなく、「まずやってみる」、とか、「やって見て、足りなかったら変更する」という方が圧倒的に、コストが低い。
これは、少し年代が高い人は分かると思うが、昔はマシンの時間が高価で、コンパイルにとても時間がかかったから、机上デバッグしていたのに、今は一人ひとつのPCが当たり前になり、IDEが進化してその場でどんどんコンパイルできるようになった。こうなると、「机上デバッグ」なんてするよりも「まずはコンパイルしてみる」という方が圧倒的に生産性が高い。
そんなわけで、高リスク制約と思われているものでも、最近は後で変更が可能となってきたものが多い。それに、工夫すれば後で変更するオプションをできるだけ維持しながら開発できる。こう考えることで、できるだけ、ユーザに見える動くソフトウェアを、すばやく提供すること、すなわち、ケーキを縦に作ることが可能になってきた。
それに、クラウドをはじめ、試すコスト、はどんどん下がっている。ケーキをどれだけ縦に切れるか、その勾配はどんどん垂直に近くなっているのである。
(引用終了)

平鍋さんの指摘通り、Webシステムの基盤作りは、きちんと設計してからサーバーを構築する手法が普通だった。
だから、「設計書を作る→サーバーを構築する→構築テストを行う」というウォーターフォール型っぽい構築方法が主流だった。

何故ならば、CPUやHDD、メモリをどれくらいに確保して、サーバー台数をどれだけ確保すべきか、性能要件をきちんと設計しなければ、構築後に作り直すのはとても手間が掛かるし、コストもかかるからだ。
非機能要件は特にあらかじめ設計しなくてはならない、というのは、アーキテクチャ駆動の開発プロセスでは主流の考え方だ。

しかし、クラウドの技術が普及するに連れて、サーバーインフラもソフトウェアと同様に変更が容易になってきた。
CPUやHDD、ロードバランサーのような負荷分散もクラウドならば、簡単にスケールアップ可能だ。

すると、まずはサーバインフラを作って都度対応しながら、あるべきサーバインフラを作っていくという手法が取りやすくなる。
時代の変化が激しいからこそ、事前に作った計画に時間をかけすぎたり、事前に作った計画に固執するのが逆にリスクになっているのだ。

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索にも書いたけれど、概念モデルを洗練させていくと「ブレイクスルー」が訪れて、設計モデルが分析モデルに変身し、本来のあるべきドメインが見えてくるという主張もある。

とはいえ、都度対応しやすい分野(文脈)もあればそうでない場合もある。
基幹系システムのように10年間は最低使えるシステムを作る場合、10年先を見越したシステム作りをするためにアーキテクチャ主導の設計を取る場合もあるだろう。

コンテキスト次第とはいえ、アジャイル手法が設計技法にも浸透しつつあると言えるだろう。
色々考えてみる。

| | コメント (0)

2012/09/04

アジャイル開発を推し進めると組織を動かす政治力が必要になってくる

最近、いろんな記事を読みながら、アジャイル開発を推し進めると、アジャイルだけでは解決できない問題がどうしても残り、その問題を解決するには政治力が必要になってくるような気がしてきた。
ラフなメモ書き。

【1】アジャイルの「ライトウィング」と「レフトウィング」:An Agile Way:ITmedia オルタナティブ・ブログ

多分、チケット駆動開発は右寄りのツール寄り。
プログラマ出身で、プログラムにこだわりがある人は右寄りだろう。

逆に、プログラミングから離れて、マネジメント職に就き始めれば、自然に左寄りになる。
プロジェクトリーダーにもなれば、メンバーに的確な指示を出してチームを回す役割を周囲から期待されている。
100人月規模のプロジェクトになれば、プロジェクトマネージャとして、複数人のプロジェクトリーダーに的確な報告と指示を出しながら、プロジェクト全体をコントロールする役割を期待されている。

そうなれば、ツールの運用のような役割は、それだけの技術力を持つ専門的な人を社内でアサインするか、社内にいなければ外部から連れてくるというように外部リソースに預けたりする。
つまり、信頼関係を元に人を動かす能力だけでなく、手元に役割を果たせる人がいなければ、外部から的確な人物を調達する能力も必要とされてくる。
それはまさに組織を動かす能力があるか否かにつながる。

プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ: プログラマの思索にも書いたけれど、プロジェクトファシリテーションのようなチームビルディング技術は、SIの中堅リーダーに最も必要とされる技術の一つだろう。
つまり、中堅リーダーがチームを任された時、チームとしてアウトプットを出しながら、プロジェクトを無事に終了させるために、メンバーの力を発揮させる技術の一つとしてとても有用だからだ。

何故、プロジェクトファシリテーションのような人心操作術がSIの中堅リーダーに必要とされるのか?
何故ファシリテーションが流行しているのか?: プログラマの思索にも書いたけれど、専門性を持った技術者が集まったチームには、中堅リーダーがその役割を代替できない高い専門性を必要とした技術者を必要とするために、中堅リーダーが権力を誇示してもチーム運営することが難しいからだ。

結局、自分よりも専門的技術を持ったメンバーに期待する役割と本来の能力を発揮してもらうために、チームビルディングの技術を必要とするのだろうと思う。
特に、ソフトウェア開発では、パソコンの前に座って黙って仕事する時間が長いために、コミュニケーションを取る時間が他業界よりもとても少ない。
だからこそ、IT業界では他業界よりも、人中心、コミュニケーション重視が声高に言われるのだろうと思う。

【2】プロマネの悩みは誰が解決すべきか : タイム・コンサルタントの日誌から

プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか : タイム・コンサルタントの日誌から

現代のソフトウェア開発では、スコープ・コスト・納期が固定された請負案件が多く、厳しい制約の中でリソースをうまく切り盛りしながらプロジェクト運営する役割を期待されている。
だが、プロマネが自由に裁量できる範囲は年々狭まっているのが現状だろう。

上記の記事では、そんなプロマネの悩みを解決するには、リーダーシップの強化よりも、プロマネを取り巻く環境をコントロールできる人こそが解決できる。つまり、プロジェクトマネジメントのレベルではなく、プロジェクトマネジメントよりも上位の概念であるプログラムマネジメントのレベルでなければ、プロマネの悩みを解決することはできないだろう、と言っていると理解している。

プログラマにコミュニケーションが足りないと言われる時: プログラマの思索に書いたけれども、プロジェクトリーダーの手ではもはやプロジェクトが手に負えなくなる状況になった時、プロジェクトオーナー(上司)やプロダクトオーナー(顧客)に調整してもらうしかないが、その時は非常に高度な政治力を必要とする。
その意味は、自分よりも上位の権限を持つ人に、自分の要求を承認してもらって状況を改善してもらえるように働きかける必要があるからだ。

特にウォーターフォール型開発ならば、そういう政治力が持っているか否かでプロジェクトの成否が決まる時もある。

【3】スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebook

Ceron.jp - スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebook

Twitter / akipii: スクラムは、組織に対して変革や改善を継続的に続けるためのプレッシャーを与えることで「組織的な阻害要因」に直面し続ける、という文言を連想させる。 スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebook http://yasuo.hatenablog.com/entry/2012/07/21/102721 …

アジャイル開発の本質とスケールアップ」でスクラムを解説している章があり、そこには「スクラムは、組織に対して変革や改善を継続的に続けるためのプレッシャーを与えることで「組織的な阻害要因」に直面し続ける」という言葉があり、いつも気になっていた。

スクラム導入で開発を取り巻く矛盾はなくなるのか? - Yasuo's Notebookを読んでその意味は何となく理解できた。
スクラム導入で製品に、品質や納期の矛盾を取り込まないように開発するようになると、開発チームに存在していた矛盾(実際はエントロピーのイメージ)が開発チームの外側に移動し、最終的には組織と開発チームの間で緊張を引き起こすようになるという指摘。
多分、ソフトウェア開発の矛盾(エントロピー)はどこかで捨てなければならないけれど、それを製品に押し付けるか、開発チームの枠外に押しやるか、という選択があり、後者の方法を突き進めれば、組織に蓄えられた矛盾(エントロピー)を包容できなくなったら、組織と緊張関係に陥るのだろう。

そういう状況になれば、組織自身を変えなければ、せっかく開発チームが改善してきた成果が組織の圧力で消されてしまうだろう。
もし組織自身を変えるようにするならば、組織を変える政治力がチームリーダー(おそらくスクラムマスタ)に必要とされるだろう。

そうなれば、もはやプログラミング力や技術力、人中心でコミュニケーション中心といった綺麗事では問題解決できないレベルまで行き着くだろう。
そうすれば、最終的には、権力だろうが権威だろうが、信頼関係だろうが、いずれかに基づいて、他人を動かし、組織を動かす能力を持っていなければ、自分の周囲を変えることすらできないのではないか。

色々考えてみる。

【追記】
とても印象に残ったつぶやきがあったのでメモしておく。
違和感を感じながら仕事している人は多いのだなと思っている。

Twitter / tech_machii: 私は30代にこれで体を壊した.なのでもう二度とやりたくない.それに私は本来,アジャイルの右翼だ.それがいま,左翼ポジションで精神的苦痛を味わっている. アジャイル開発を推し進めると組織を動かす政治力が必要になってくる http://bit.ly/UpmiYi

| | コメント (0)

2012/09/03

Lean Startup基礎~MVPとピボット

MVPとピボットについてとても分かりやすいスライドがあったのでリンクしておく。

【元ネタ】
tech venture business ≫ Lean Startup基礎#3: MVPとは?

tech venture business ≫ Lean Startup基礎#4: ピボットとは?

MVP、革新会計、成長エンジン…書籍「リーン・スタートアップ」で紹介されている重要コンセプト | ihayato.newsには、MVP(実用最小限の製品:minimum viable product)に関する事例が幾つか掲載されている。
例えば、グルーポン、Dropbox、Food on the Table、Aardvaak。
この事例は、リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだすにも記載されている。
この記事を読んだ時はその意味が分かっていなかったけど、上記のスライドでようやくその意味が分かった。

MVPは、新規ビジネスを立ち上げる時に検証するための最低限の機能だけを実装した製品を指す。
MVPはプロトタイプではない。
なぜなら、MVPは機能が最低限であっても、紙芝居ではなく、データを入力すれば必ず動くからだ。

MVPは基本はベータ版でもない。
何故なら、MVPは機能が最低限であっても、完成品であり、デモ用に飾られる製品ではない。

ウォーターフォール型開発の要件定義プロセスで、顧客から要件を引き出したり、要件のすり合わせを行うためにプロトタイプを作る手法がある。
このプロトタイプは、動く製品ではなく、画面イメージだったり、デザイナーが作ったWebページを静的に画面遷移するだけの紙芝居だったりする。
プロトタイプがあるだけでも要件定義では役立つけれど、MVPはそのように使われるものではない。

そして、MVPはシステムやソフトウェアとも限らない。
グルーポン、Dropboxの例では、紙のクーポンだったり、完成品をイメージする動画だったりする。
つまり、新規ビジネスが有望かどうかを検証するための製品だったりする。

また、ピボットは、バスケットボールで出てくるピボットと同じ。
バスケットのピボットは、片足を軸として、何度でも方向転換できる。
同様に、リーンスタートアップのピボットも、MVPをユーザに見せたフィードバックを元に、その影響力を計測し、更に製品を進化させるために戦略を変えていくことを指す。

MVPやピボットという概念に注目する理由は、従来のアジャイル開発を補強する概念だからだ。
MVPを定めて、そこから製品に少しずつ必要な機能を追加していく戦略を取ることもできる。
その戦略はまさに小規模リリースそのものだ。

また、ピボットはイテレーション計画で実際は頻繁に行なっているだろう。
チケット駆動開発なら、イテレーション単位にチケットの取捨選択をするたびに、何らかのピボットを行なっているのではないだろうか?

アジャイルとリーンの関係性についても色々考えてみる。

| | コメント (0)

2012/09/02

パターン言語を学習パターンに応用した事例

「XPやScrumはパターン言語である」という意見を聞いて、パターン言語について色々調べてみた。
その際に、パターン言語を学習パターンに応用した事例があったのでリンクしておく。
以下、ラフなメモ書き。

【参考】

暗黙知の共有に効く?パターンランゲージの可能性 | It's Real Intelligence! 7

パターンランゲージ - @IT情報マネジメント用語事典

生成的開発プロセス・パターンランゲージ

Twipata ツイッターパターンズ - パターンランゲージとは

ソフトウェアに必要なパターン・ランゲージとは (arclamp.jp アークランプ)

SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語

重要なテクノロジーは10名以下のチームで作られた ~ Innovation Sprint 2011(後編) - Publickey

- 組織パターンとプロセスパターン

パターン言語の特徴としては、「漸進的な設計」「マスタープランの不要」「ユーザの積極的関与」があると思う。
事前に立てた計画があったとしても、現状に合わせて少しずつ改変しながら、少しずつ作っていく。
その時に、設計者だけでなくユーザも巻き込んで、本来のあるべき姿(モデル)を共同で作業しながら作りこんでいく。

その発想をソフトウェアだけでなく、学習やプレゼンテーションにも応用した事例がある。
可愛らしい絵が、パターンに込められた難しい概念を理解できそうなイメージにしてくれている。

プレゼンテーション・パターン (Presentation Patterns)

学習パターン (Learning Patterns)

パターン、Wiki、XPは良書: プログラマの思索にも書いたけれど、僕はパターンという考え方が好き。
パターンは、たくさんの現場で編み出された経験知が、どんな状況(コンテキスト)でどんな解決方法(ソリューション)で解決できたのか、を明確にしてくれるからだ。

他にパターンの特徴としては、現場の事例に基づくために、メタな概念による定義とはあまりマッチしないように思う。
BOKのような知識体系はそれはそれで勉強になるが、パターンとは質的に異なるように思う。

今後考えてみたいのは下記の2つ。

XPやScrumはどのようなパターン言語の体系で作られているのか?
チケット駆動開発をパターン言語で記述した場合、どんな新しい知見が生まれるのか?

色々考えてみる。

| | コメント (0)

メインラインの定義

構成管理パターンの一つであるメインラインモデルを再考してみた。

【元ネタ】
構成管理 実践入門 第3章 Subversionベストプラクティス コードライン編その1 メインライン

(引用開始)
■メインラインを1つに保ちましょう
Subversionでは、trunkをメインラインとして使用することを推奨しています。 開発はメインラインに対して行うことを心がけてください。ほかのブランチへメインラインの置き換えを行った場合も、そのブランチにメインラインの原則を適応して、メインラインが複雑化しないようにしましょう。

■メインラインは正しくビルドできる状態に保ちましょう
すべての開発者は、通常メインラインに対して作業を進めていきます。コミット時に事前テストを行ったり、インテグレーションビルドを行うなど、メインラインから取得する作業環境は常に正しくビルドが行えるように保ち続けましょう。

■メインラインからブランチを作成しよう
ブランチは極力作成を行わないほうが好ましいですが、作成を行いたい場合、ブランチからブランチを作成するようなことは避け、メインラインからブランチを作成するように心がけることで、複雑化を抑えることができます。

■ブランチの変更は素早く元のメインラインに反映させましょう
ブランチに対する変更作業にかかる期間が長ければ長いほど、マージを行うことが困難になります。ブ ランチを作成して分岐を行った場合、その変更内容を素早くメインラインに戻すことを心がけましょう。
(引用終了)

メインラインは、ブランチの派生元であり、更新されたブランチが終了する時にマージする先のコードラインになる。
つまり、ブランチに寿命がある場合、ブランチは基本は派生元のメインラインにマージされて消える運用になるのがメインラインモデル。

メインラインは普通はtrunkやmasterだが、ブランチがずっと生き続ける場合、そのブランチがメインラインになる場合もある。
つまり、メインラインの本来の定義では唯一つではない。
そのような例としては、複数の似たような製品を開発せざるを得ない製品ファミリー開発(SPL)が多いだろう。

但し、「Redmineによるタスクマネジメント実践技法」「チケット駆動開発」本では、僕は故意にメインラインの定義を「最新機能を持つ常時リリース可能なコードライン(ブランチ)」へ変更している。
メインラインの本来の定義では、上記の定義のように、そもそもいつも常時リリース可能になる性質はない。
だが、XPのプラクティスであるテスト駆動開発や継続的インテグレーションを実施していれば、メインラインは自然に常時リリース可能なコードラインになっている。

そもそも、現代のソース管理において、メインラインの役割に相当するブランチには、コンパイルエラーが通っていないソースをコミットすることはありえないだろう。
何故ならば、コンパイルできないソースをコミットしたら、メインラインの品質が落ちてしまうだけでなく、メインラインからプライベートなブランチ(トピックブランチ)上で作業する開発者に悪影響を及ぼすからだ。

同様に、現代のソース管理において、メインラインの役割に相当するブランチには、単体テストが通っていないソースをコミットすることはありえない。
現代のソフトウェア開発ではテスト駆動開発は当たり前であり、そもそもTDDをやっていないプロジェクトでは、実際に結合テスト工程のようにかなり時間が経った後に初めて動作確認してバグを発見してしまうから、既に破綻していると言ってもいいだろう。

同様に、現代のソース管理において、継続的インテグレーションを実施しないことはありえないだろう。
そもそもメインラインでビルドが通らない状況のまま放置していれば、そもそも動かないソースを他の開発者に提供してしまうため、悪影響を及ぼすからだ。

つまり、メインラインは単に、すべてのブランチの派生元であり、派生したブランチがマージされるブランチだけでない。
メインラインは、最新機能を持つ常時リリース可能なコードラインでなければ、安定してアジャイルに開発できないからだ。

何故、メインラインが必要なのか?
開発者にとって、どのソースが最新で、どれを修正すればよいか、メインラインがなければすぐに混乱してしまうから。
リリースのたびにブランチを作り、作ったブランチから更にブランチを作る「昇格モデル」は、開発者にとってとても開発しづらい。
開発環境を整えるのはそんなに簡単ではないのに、昇格モデルの場合は開発環境がどんどん移り変わっていくのでとても大変だから。

そして、メインラインから派生して更新されたブランチがマージされる時、GitやMercurialではいろんなマージの種類がある。
merge, push, pullコマンドが一番単純だろうが、rebaseのようにブランチ上で更新されたコミット履歴をメインラインに反映したり、hgのtransplantやGitのgit-cherry-pickのように、ある特定のリビジョンのパッチだけを取り込む方法もある。

git-cherry-pickを掘り下げる - idesaku blog

Git使いがMercurial使いに転職するとき設定しておくべきMercurial拡張 - TIM Labs

Gitで特定のコミットを指定する108の方法 - TIM Labs

特定目的のバグ修正や機能追加を行うトピックブランチは、多種多様なマージコマンドを必要とする。
その理由は、メインラインと同期したり、必要な最新機能だけ取り込む機会が多いため、特定のパッチだけを取り込む手法が必要だからだろう。

Redmineによるチケット駆動開発とメインラインモデルはとても相性が良い。
更に、変更理由をチケットに書いておき、リビジョンと紐づけておけば、トレーサビリティも実現できる。

チケット管理とバージョン管理の連携機能は、構成管理パターンを更に実現しやすくしてくれる可能性がある。
色々調べてみる。

| | コメント (0)

2012/09/01

ようこそリーンスタートアップ 「ムーブメント」へ by @hiranabeさん翻訳

「ようこそリーンスタートアップ 「ムーブメント」へ」というスライドを見て、リーンスタートアップの理解が進んだのでリンクしておく。
ラフなメモ書き。

【元ネタ】

MVP、革新会計、成長エンジン…書籍「リーン・スタートアップ」で紹介されている重要コンセプト | ihayato.news

成功するリーンスタートアップ実践のポイント「顧客課題仮説の記述」 | "Lean Startup Japan"

[早版] 東京「クックパッドがリーンスタートアップから学んだアジャイルな開発」 ? Agile Japan 2012レポート(9) | ManasLink - EM ONLINE

「Lean Startup Bootcamp」に参加してきました!~前編~ | クラスメソッド開発ブログ

高速で無駄のないソフトウェア開発を実現するための7つのポイント - Social Change!

リーン・スタートアップの開発サイクルは、仮説作成→MVP試作→BMLプロセス→Pivot(方向転換)。

まず、どんな製品を作るとどのマーケットに売るか、という仮説を作り、検証する。
仮説が確定したら、MVP=Minimal Viable Product、つまり、実用最小限の製品という試作品を作る。
MVPはプロトタイピングに似ているが、必要最低限の機能だけとし、ユーザインターフェイスを重視して作る。
MVP試作は従来のプロトタイプ作成とは意味合いがかなり違う。

そして、MVPが確定したら、MVPを元に製品を開発し、実際にマーケットに出して、ユーザからフィードバックを受けて評価する。
BMP=Build, Measure, Learnの略。
つまり、構築(Build)し、測定(Measure)した結果を学習(Learn)して、次の機能改善に活かす。

[早版] 東京「クックパッドがリーンスタートアップから学んだアジャイルな開発」 ? Agile Japan 2012レポート(9) | ManasLink - EM ONLINEでは、クックパッドがMVPのアイデアを用いてどのようなWebサービスを作ったのか、という事例が書かれている。

クックパッドの事例では、測定評価の対象が女性社員だったり、スーパーにチラシを配ったユーザだったり、かなり身近な人達が対象になっているのが興味深い。
その方がフィードバックが早いだけでなく、実際に購入したユーザが明確になるので、ペルソナ分析もやりやすくなる利点があるのだろう。
つまり、どのターゲットに絞って製品を販売するのか、という観点がより明確になる利点もあるのだろう。

そして、「試験的に使ってくれるユーザーにお金を払ってもらうことが、正直なフィードバックを得るためのコツなのだそうです」という話は、マーケティングの基本を思い出す。
つまり、製品のアーリーアダプターには、いきなり低価格の製品を使ってもらうのではなく、高い価格でも製品を購入してくれるかを探るために、モニターになってもらってフィードバックをもらうようにするのがコツなのだろう。

また、「MVPにはメールが相性がいいらしい」という話も面白い。
ユーザとのチャネルは、メール以外にも紙媒体の広告、営業電話、チラシなどがあるが、メールは直接ユーザに届くだけでなく、開封しなければユーザにとっても邪魔にならない。
メールという古いプロトコル(チャネル)は研究する余地があるのだろう。

ピボットとは、戦略(製品計画)の方向転換のこと。
最初に作った仮説に基づいて製品を作ったとしても、ユーザのフィードバックを受けながら、少しずつあるいは大胆に方向転換する。
むしろ、方向転換するタイミングを逸する方がリスクがあるようだ。
この辺りは、アジャイル開発のイテレーション計画に似ている。
例えば、アジャイル開発では、作業計画は定期的に最新化して、現状の作業に合わせながら、チームが進むべき道を示す。

リーン・スタートアップをアジャイル開発の観点で見れば、MVPという考え方がとても特徴的で、アジャイルの考え方を発展させたように思う。
盛り沢山の機能は却って不要であり、むしろ最低限のシンプルな機能の方がユーザにとっては逆に使いやすいという発想。
特に、XPの計画ゲームではイテレーションのたびに、不要な機能は思い切って削るべきという指摘があり、とても驚いた経験がある。
アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索にも書いたように、最近では、機能性という品質の考え方が根本的に変わっている。

リーン・スタートアップはまだまだ理解が浅いので他にも調べてみる。

| | コメント (0)

« 2012年8月 | トップページ | 2012年10月 »