無料ブログはココログ

[#TiDD] プロジェクトを成功させるチケット管理

QuaSTom高品質ソフトウェア技術交流会 2017年度第2回例会で講演させていただきました。

Redmineの勉強会ではないので初心者の方が多いかと思いきや、9割の方がチケットシステムを使われていて、そのうちTracが24%、Mantisが8%、残りがRedmineを使われていました。

幹事の松谷さんに用意していただいたグループディスカッションも、みなさんのお悩みや経験で盛り上がりました。やはり、メンバーにきちんと理解してもらえないとうまくいかないようです。

同じような議論は、90年代後半以降のプロセス改善ブームの頃にもありました。みなさんの意見をうかがっていると、やはり「ツールの導入はプロセス改善である」という思いが強くなりました。

ディスカッションへのコメントで「ゴールはプロジェクトの成功」とお話ししたことや、講演のおまけでお話しした「サーバントリーダーシップ」もリーダーシップの議論をされているとのことで喜んでいただけました。

久しぶりに大いに刺激を受けることができました。ありがとうございました。

おまけ

講演の仲であまり詳しく説明しなかったチケット駆動開発のレフトウィングとライトウィングのお話は、以下の発表が元になっています。

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

(今回はお話ししませんでしたが、改善にはフィードバックやタイミングも重要だと思っています)

この発表の際にも使わせていただいた乗松さんの資料(PDF)の23ページ「SPIモードの遷移」は認証の罠を標準化の罠に読み替えるとツール導入にも同じような問題が起きると思いますので、参考にしてください。

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


Redmineが得意なプロジェクト

Redmineの機能を考えると、どのようなプロジェクトに向いているかがわかります。

プロダクトライン

Redmineのチケットは全てのプロジェクトで通番になっています。他のプロジェクトのチケットを容易に参照できますので、プロダクトラインの開発時の様に過去のプロジェクトの参照が必要な場合に有利です。
参考:『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

System of Systems あるいは トップダウンに分解できる

Redmineのプロジェクトとチケットは、それぞれの親子関係を持つ事ができます。 System of Systems と呼ばれるような、複数のプロジェクトから構成されるシステムも小さな単位に分割して管理できます。
参考:[#TiDD] チケットによる情報の関連付け(チートシート)

多様なコミュニケーションが必要な大規模システム

Redmineには他のITSにもあるWikiのほか、フォーラムやニュースなどの情報共有の仕組みがあります。また、ガントチャートによる可視化やREST APIなどシステム連携機能もあります。大規模システムにも対応できる多様な機能が標準で用意されています。(大規模な開発が多いので参考にある様に「説明会を開くべし」と言う意見が多いのでしょうね)
参考:[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

作者のJPL(Redmine.jpブログ)は、このような開発をしているのかも知れませんね。

ちなみに上記に当てはまらない、一度限りのプロジェクト、単独システムあるいは構成が変わり易いシステム、チケットで十分あるいは小規模な場合は、Redmineにこだわらなくて良いプロジェクトと言えるでしょう。

なお、Redmineの特徴を説明しましたが、ITSの導入には知見者あるいは導入意欲を持った人の存在が必要になります。また、過去の資産をどうするかということも、ITSを選択する際の重要なポイントの一つでしょう。

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


『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

Redmine実践ガイドの5章の終わりに「Tracユーザーから見たRedmine」というコラムを書きました。先日のRxTstudyに参加して、Redmineのチケット番号の一意性の優位点について書き忘れている事に気付きました。

具体的には、あきぴーさんの発表のスライドの「PJ分割ルールの効果」のところで、

「そんなの、1プロジェクトにバージョン管理ツールの1リポジトリがあたりまえじゃん!」(なぜか浜っ子風)と、思った時に気付きました。

Tracは1プロジェクトに1リポジトリが基本です。複数プロジェクトでリポジトリを共有する際は、リポジトリからTracへの参照にプトジェクトを示すプレフィックスが必要になります。

でも、Redmineではそんなのお構いなしで、一つのリポジトリを、親子であろうと無かろうと、複数のプロジェクトから参照できます。

このような違いが出るのは、Tracのチケット番号がプロジェクト毎に0から始まるのに対して、Redmineのチケット番号は全てのプロジェクトで通し番号になっているからです。常にチケット番号が一意に決まるので、リポジトリからの参照にプロジェクトのプレフィックスが不要になります。

機能的には同じですしツールを使っているなら大きな違いはありません。でも、Tracの場合はあらかじめプレフィックッスを付けて運用を始めないといけないので、同じプロジェクトでずっと運用する事になりがちです。

一方、Redmineの場合はとりあえず始めておくことができます。そして、予算等の管理単位や派生開発等で構成メンバーが異なるなど、1つのプロジェクトでやりにくくなった場合に別のプロジェクトや子プロジェクトに分ける事ができます。

Redmineはチケット番号が通し番号なので、見ていないチケットがあるかどうかがわかりにくいという面もありますが、プロジェクトが長期にわたったり、大きくなると有利な面があるのですね。

追記:

このような理解ができて、ようやく赤羽根さんが努力されている価値がわかりました。Redmineを複数立てない事がRedmineの活用につながると思います。

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


[#Node-RED] Node-REDでTwitterのDMからRedmineのチケットを作成する

前回Node-REDからRedmineのREST API を呼んでチケット一覧を取得しましたが、今回はそれを少しずつ変更しながらちょっと実用的なものを作ります。

httpヘッダーをJSONでセット

前回は文字列としてヘッダーをセットしましたが、複数のヘッダーが必要ですのでJSONに変更します。チェンジノードのデータを「JSON {}」して以下の様にセットします。

{"X-Redmine-API-Key":アクセスキー}

一旦、デプロイしてインジェクトボタン(timestampと表示されているノードの左側の四角いボタン)を押して、右側のデバッグノードの確認します。

20160417_124531

上図のようにエラーが表示された場合は、表示されているノードの名前「APIキー」で確認できますが、エラーメッセージの上にマウスカーソルを移動させると対象のノードが赤の点線で囲まれるので簡単に確認できます。

httpヘッダーをJSONでセット

チケットを作成するにはPOSTで、 Content-Typeの設定が必要です。チェンジノードの設定を以下に変更して、確認します。

{"X-Redmine-API-Key":アクセスキー, "Content-Type":"application/json"}

プロジェクト作成&ID取得

Redmineで、プロジェクト -> 新しいプロジェクトと実行して、更新を受けるプロジェクトを作ります。さらに、プロジェクトを選んでから設定 -> メンバーの右側でユーザとロールを選んで追加しておきます。

プロジェクトIDはNode-RED呼び出しノードのURLをssues.jsonからprojects.jsonに変更して、インジェクトするとプロジェクトIDがわかります。

{ "projects": [ { "id": 3, "name": "自動投稿", "identifier": "social", "description": "ソーシャル投稿用のプロジェクトです", "status": 1, "created_on": "2016-04-17T04:01:39Z", "updated_on": "2016-04-17T04:01:39Z" }, { "id": 2, "name": "親プロジェクト", "identifier": ・・・

同様にステータスIDはissue_statuses.json、トラッカーIDはtrackers.json、優先度は/enumerations/issue_priorities.jsonで得られます。

POSTしてみる

Redmineのドキュメントを参考にチケットを作ってみます。入力をSubjectに入れるので、チェンジノードをあきらめて、ファンクションノードに以下のコードを設定します。

msg.headers =
{"X-Redmine-API-Key": アクセスキー, "Content-Type":"application/json"};
msg.payload =
{
  "issue": {
    "project_id": 3,
    "tracker_id": 4,
    "subject": msg.payload,
    "priority_id": 2
  }
};
return msg;

入力がtimestampでは寂しいので「漢字のサブジェクト」という文字列をインジェクトノードにセットします。設定画面のpayloadで「aZ」を選択して設定します。

デプロイしてdebugタブに以下のような表示がされれば成功です。

{ "issue": { "id": 17, "project": { "id": 3, "name": "自動投稿" }, "tracker": { "id": 4, "name": "タスク" }, "status": { "id": 1, "name": "新規" }, "priority": { "id": 2, "name": "通常" }, "author": { "id": 1, "name": "阪井 誠" }, "subject": "漢字のサブジェクト", "start_date": "2016-04-17", "done_ratio": 0, "spent_hours": 0, "created_on": "2016-04-17T05:57:57Z", "updated_on": "2016-04-17T05:57:57Z" } }

twitter対応

チケット作成が確認できたので、いよいよtwitterに対応しましょう。Node-REDの左側の少し下の方にtwitterノードがありますのでこれをクリックします。すると右側のinfoタブに説明が表示されます。すると、送信者はtopic、内容はtweetにセットされることがわかります。

そこで、テストデータとしてインジェクトノードのtopicに送信者、payloadに漢字の概要を設定して、チェンジノードでmsg.payloadをmsg.tweetにセットします。

Redmineを確認すると、題名が「送信者」、説明が「漢字の説明」となったチケットができているはずです。

twitterノードの追加

入力としてtwitterノードを追加します。「Add new twettier-credentials...」の状態で右のペンのアイコンをクリックするとtwitterの連携用の認証に進むことができます。searchはダイレクトメッセージを選択します。

デプロイして自分にダイレクトメッセージすると、説明にプロフィール等が載っていてそのままではチケットの説明に使えません。msg.tweet.textが求めている送信文でした。最終的にファンクションノードは以下の様なコードになります。インジェクトも同じ様に変更します。

msg.headers =
{"X-Redmine-API-Key":アクセスキー, "Content-Type":"application/json"};
msg.payload =
{
  "issue": {
    "project_id": 3,
    "tracker_id": 4,
    "subject": msg.topic,
    "description": msg.tweet.text,
    "priority_id": 2
  }
};
return msg;

ようやくチケットができました。

20160417_154511

ふりかえり

Node-REDを使って段階的に開発してみました。インタフェースがJSONで統一されているので、インジェクトノードで下流を確認しておいて、あとから実際の通信をすることができます。

時差意の処理はファンクションノードで頑張れば大抵のことはできるのですが、細かく分けて実装するとdebugタブのエラー表示をうまく使えます。

また、infoタブで仕様の確認ができるので、インタフェースを確認しながら作り上げることができます。もし、勘違いがあればdebugノードを追加して簡単に確認できます。

20160417_171132

作成したフロー中のデバッグノードには、右側の四角の部分が白いものがあります。これはデバッグに使ったもので、そのままでは煩わしいので表示を停止したものです。再デプロイしなくても四角の部分を押すだけで変更できます。

まとめ

IoT環境として知られているNode-REDは、通信プログラムが作り易い環境です。

ソフトウェア開発に通信がからむと結合時に実物との擦り合わせが必要です。twitterノードのポーリングは15分に1回ですので、今回の様に段階的に開発しないと開発にとても時間がかかるでしょう。

Node-REDユーザに公開されているノードには、この他にもソーシャネット向けのノードがたくさんあり、無料サービスのFREDでもたくさんサポートされています。

今回はイベントドリブンな方法のみを紹介しましたが、インジェクトノードはcronの様な定期実行も可能です。色々なシステムを作ることが可能でしょう。

ぜひ、一度Node-REDに触れてみてください。
(注:今回利用したtwitterノードはデータ取得を100%保証していないので、実際に使う場合は別の方法でもチェックしてください)

おまけ:Redmineの視点で

今回は前田さんの発表を参考に、メールの代わりにTwitterを入力源として使ってみました。もちろん、文字コードの考慮が必要ですが、RedmineのメールをチェックしてTwitterで通知することも簡単にできます(こちらはデータ抜けがないでしょう)。

さらに応用すれば、社内用とプロジェクト用のRedmine間で更新をリンクさせることも可能になるでしょう。チケット作成時にチケット番号が返ってきますので、それを何かに覚えておけば容易に実現できるでしょう(Node-REDはDBなどのストレージも色々使えます)。

次回は、もう少し大きなシステムを作る際に考えないといけない保守性について書いてみたいと思っています。

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

[#Node-RED] RedmineのREST API を呼ぶ

前回は「Hello World!」のWebサーバを構築しましたが、今回はクライアントとしてNode-REDからRedmineのREST APIを呼んでみます。なおNode-REDとRedmineはローカル環境で動作させました。

20160414_233706

フローの説明

グレイ(青?)のインジェクトノードの左の四角いボタンを推すとタイムスタンプがmsg.payloadに入れられます(中身は使わずタイミングを与えています)。

  1. チェンジノードでmsg.headers(httpヘッダー情報)に「X-Redmine-API-Key=アクセスキー」をセットします。
  2. httpリクエストノードでhttp://Redmineサーバアドレス/redmine/issues.jsonを呼び出(GET)します。
  3. JSONが一つの文字列でmsg.payloadにセットされるのでファンクションノードでオブジェクトに変換します。
  4. デバッグノードでデバッグタブに出力します。

JavaSscriptはたった2行

なお、JavaScriptのコードはファンクションノードに書いた以下の2行だけです。

msg.payload = JSON.parse(msg.payload);
return msg;

Redmineの設定

REST API を有効にする:
管理 -> 設定 -> 認証で、「RESTによるWebサービスを有効にする」をチェック

アクセスキーの取得:
個人設定-> APIアクセスキー(右側に表示されます) の「表示」を押すとAPIアクセスキーが表示されます。必要に応じてリセットしてください。

認証が必要:
管理 -> 設定 -> 認証で「認証が必要」のチェックをしている場合は、ベーシック認証のユーザとパスワードを設定します。この場合はアクセスキーは不要な様です(Redmine 2.5.2で確認しました)。

注意点

デバッグ情報を全て表示したい場合は、REST APIのパラメータでlimitやoffsetを指定してください。途中で表示が切れる場合はNode-REDのsetteings.jsでdebugMaxLengthを変更してください。

おわりに

Node-REDなら、ちょっとした処理をとても簡単に実現できます。今回はインジェクトノードのボタンを押すことで実行しましたが、http、Twitter、メール、Websocket、tcp、udp、MQTT、シリアル、ファイル更新、などを入出力とする事ができます。

このように入力や出力を簡単に取り替えられるのは、ノード間のインターフェースがJSONで標準化されていることのほか、インジェクトノードやデバッグノードが良くできているので、作り易いからだと思います。

次回はその辺りを意識しながら説明してみようと思います([#Node-RED] Node-REDでTwitterのDMからRedmineのチケットを作成する)。

おまけのコード

ローカル環境やFREDでインポートできます(2016/4/18 追記:無料で利用できるのは72時間までになりました)。動かすには、サーバーアドレスとアクセスキーを変更する必要があります。ちなみにローカルIPアドレスですので、攻撃はできません。

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

[#redmineT] 裾野が広がるRedmine「チケット駆動開発導入のヒント - 自律と規律 -」

redmine.tokyo 第9回勉強会で発表させていただきました。

今回の勉強会は入門的な内容だったこともあり、80名を超える方に参加していただけました。そのうち初めての方の比率が高く、懇親会には約1/3の方が参加されました。

以前、Redmineはキャズムを超える - redmine.tokyoに参加して -と書きましたが、本当に裾野が広がってきた様に思います。

これまではRedmineの利用方法にはAsIsとToBeの2つのの進め方があると説明してきましたが、講演をしていると導入時点で失敗している相談を受ける事が多くありました。そこで、プロセス改善やPDCAサイクルと管理者・開発者の利益の視点から導入方法のヒントを説明しました。

うなずいてくださる方も多かったのですが、Tweetでの反応で予想外のものもありました。「ピンチはチャンス」というタイトルでプロジェクトが大変でどうしようもない時に導入すると良いと説明したのですが、「無理だ」という反応がありました。

プロセス改善は効果が見込めるから実施するもので、効果がないなら導入してはいけません。みんなが頑張る方が効率的に乗り切れるなら、そうすべきです。

ピンチのときにチケット駆動開発をして効果があるのは、何をすべきか見えていないので気付いた事を共有するとか、混乱の原因がコミュニケーションや情報共有にある場合です。そのような問題をチーム全体で共有して、負担よりもメリットが大きい場合のみ導入すべきです。

そのような注意書きがなかったので、嫌な経験をした方には納得できなかったのでしょう(もし、私の過去の発表がきっかけになっていたらごめんなさい)。

なお、スライド中で参照している乗松さんのスライドのPDFはここ(Jaspic)です。

追加でお話しした日本Redmineユーザグループ発起人会のスライドのPDFはここに置きました。

これまでも東京はredmine.tokyoと大阪にはRxTstudyというコミュニティがありましたが、日本全体のユーザの場をつくりたいと思っています。Facebookのグループや、地方での普及協力、開発者への支援など夢は広がりますが、先ずは有志で集まりませんか?というお話をしました。

ご興味のある方はPDFをご覧の上、Twitter (@sakaba37) などでご連絡ください。

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


[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

RxTStudy #13で「Redmine再入門 〜達人に学ぶRedmineの徹底指南〜」と題して、お話をしてきました。

今回は Redmine再入門ということでしたので、チケット駆動開発でどのような点に注意すれば良いかをお話ししました。

説明会は開くべきか

パネルディスカッションでは、モデレータのあきぴーさんの質問に対する議論の形で進められました。中でも気になったのは、Redmineの導入時に説明会が必要かどうかです。

説明会が必要だとする方が多かったのですが、何のためにRedmineを導入するかによると思います。たぶん、大きなプロジェクトや組織の中にRedmineを導入するような想定なのでしょう。

この場合、Redmineに期待するのは、障害管理などの管理作業をRedmineに移行して効率化をはかると言う目的なのでしょうね。情報共有がリアルタイムになり、プロジェクトがうまくいく算段なのでしょう。

説明会の功罪

説明会を開くと知識の底上げと共通化ができます。Redmineの使い方やルールを知る事で、一定の知識を持つ事ができるほか、運用ルールを徹底する事ができます。

説明会を開くと、「こういう時はどうすれば良いですか?」と積極的な質問が出るでしょう。良い事です。

このような大人数の説明会では、質問は出ても改善案はなかなか出ないでしょう。もし出ても「こうして下さい」と共通ルールに従う事をお願いすることになるでしょう。仕方ありません。管理のための導入なのですから、、

Redmineをチーム作りに使う

Redmineには、もう一つの使い方があります。「チーム作り」です。チームで気付きを共有し、作業を共有し、同じゴールを共有して行動します。いわゆる自律的組織です。

多くの人は教えられると考えるのをやめます。その方が楽だからです。ならば、基本的なルールをWikiに書いておいて、問題のある時だけ指導してはどうでしょう。

Wikiに書かれている事を理解して、考えないと行動できませんん。なぜそのようにしているかを考えて、より良い提案が出てくるかも知れません。

管理のあり方

Redmineを管理に使うととても便利ですが、自律的なチームの可能性を押さえてしまいますし、工事進行基準では様々な問題があります([#TiDD] チケットのエクセル連携は工事進行基準と相性が悪い)。

より外乱に強いプロジェクトを実現するには、管理者は組織パターンの「門番」として外界とのインタフェースをとると良いと思います。コミュニケーションの視点でチケット駆動開発を考える事が自律的なチーム作りには重要だと思います([#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて)。

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


OSSを応援してソフトウェアの自由を得よう - 話題のRedmineの魅力を知ろう その2 - #benkyoenkai

第42回IT勉強宴会 話題のRedmineの魅力を知ろうの続き、前田さんの講演の感想です(その1)。

前田さんの発表は3本立てで、まずRedmineをプロジェクトに適用しようRedmineによるwebサポート窓口の実装と運用からの抜粋したお話がありました。そのあとのRedmineへのContributeとビジネス展開は色々と考えさせられました。

FLOSSふりかえり

フリーソフトウェア(FLOSS: wikipedia)が生まれたのは、元々は相互扶助でした。「良かったら使って!」と無料で公開されたると、利用者は感謝の言葉や感想、バグ報告や修正パッチ等を返していました。レスポンスを得ることで開発者は元気をもらい、開発を続けました。

ソフトウェアやユーザの規模が大きくなるにしたがい、開発者と利用者の距離は離れ、協力する人の比率は少なくなっていきました。やがて、無料である以外は商用ソフトとあまり変わらない、シェアウェアやフリーミアムのようなビジネスモデルが出てきました。利用者からすると無料であれば良かったのかもしれません。

その後、セキュリティ面の優位性やベンダーロックインをさける目的などから、市販アプリの対抗馬として、市販アプリと同じ評価軸で考える人が増えていきました。事業の継続性や有償のサポートの有無など、フリーソフトウェアが生まれた頃には考えられない見方です。

すると今度は、有名なフリーウェアを単に支援するだけでなく、自社のビジネスに都合の良い方向にコントロールしようとする企業が現れ、著名なFLOSSプロジェクトが買収されました。

FLOSSの"L"は利用するプログラムのコードの改良や公開の自由を指しますが、このような買収によって、コードの修正の自由を特に望まないような一般の利用者の使い続ける自由も危険にさらされました。

結果的には、コードが公開されている事で、あるべき姿を望む人たちによって分裂(フォーク)し、下心を持ったチームは衰退し、利用者の使い続ける自由が守られました。

ファーエンドテクノロジー社の支援

前田さんの会社の支援は、Redmineの開発コミュニティに協力するものです。もちろん企業ですから「情けは人のためならず、巡り巡って我がのため」ではあるのですが、直接的な利益は求められていません。どちらかというと、メリッットを享受したからお返しするような印象を受けました。

変なスポンサーがつかなくても、開発がチームで行われ、相互扶助のわかる利用者のいるFLOSSは続くと思います。資金でなくても、パッチ、コメント、感謝があれば、開発コミュニティは継続するでしょう。

おわりに

ソフトウェアの寿命は長いと言われますが、市販ソフトやスポンサーのついているオープンソースだからといって永遠に続くものではないことは周知の事実でしょう。開発している人たちが継続しようと思える相互扶助的な環境を維持できる事が、ソフトウェアの寿命を延ばし、結果的に利用者の自由を守ると思います。

あまり貢献できていませんが、少しでも協力したいと思います。

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


Redmineからワークフローを考える - 人間の可能性を生かすには -

先日のRedmineの紹介を終えてから、そのワークフローの思想を考えてみました。

一般的なワークフロー

Wikipediaによれば、

ワークフロー(英: workflow)は、リソース(資源)を体系的に組織化した反復可能な業務活動のパターンである。

とされていて、障害票や経費伝票などのハンコ欄やの確認日欄などもワークフローを処理する仕組みの一例と言えると思います。

ワークフローを表す場合によく使われるのは、状態遷移図のようにある条件によって状態が変わるモデルです。ワークフローのモデルは作業の分析や自動化にも用いられますが、例えば「リーダの確認によって完了状態になる」のように、作業の進め方のルールをホワイトリスト的に示したものでもあります。

たとえばTracでは、TICKET_MODIFY権限を持つユーザがacceptすると担当をユーザにして、状態をacceptedにする場合は、以下のように書く様です(Tracプロジェクトのサンプルより引用)。

accept = new,accepted -> accepted
accept.permissions = TICKET_MODIFY
accept.operations = set_owner_to_self

このような記述でルールを追加していきます。

Redmineのワークフロー

これに対してRedmineのワークフローは状態遷移表の様に、ロールとチケットの種別毎にステータス間の遷移を許すかどうかをマトリクスで設定します。

 

2_1_4

 

Redmineはブラウザからワークフローを設定できて便利です。しかしTracのようにルールを追加していく場合は、全体が見渡せないので、かえって不便です。

これは実装の都合のようにも思えますが、実は設計思想が違うのではないかと思いました。つまり、ほとんどの遷移は許すものの「リーダ以外が完了状態にする事は許さない」のように、いわばブラックリスト的な設定を容易にしているのではないかと思います。

人間の可能性を生かすには

さて、前述のWikipediaには、このような事も書かれています。

21世紀初頭のインターネットバブルの崩壊により、高度なワークフローの概念化に対する不信感が生まれた。今日、様々な人々が、合理的で柔軟で国際化(作業場所の分散)に対応可能で人間の可能性を十分に生かす新たな作業モデルの開発という問題に立ち返っている。その中でも、オープンソースコミュニティで育ってきた、一見して無政府主義的なシステムに対する真剣な考察は重要である。

Redmineのワークフローはそのドメインのモデルとして、基本は自由でありながら人間がミスを犯しそうな場合には制約を与える方法をとったのではないかと思います。

人間の可能性を生かすには、サーバントリーダーシップ(アジャイル開発への壁は価値観の壁)のように、ルールによる管理から最大限の能力を発揮できるような支援への発想の転換が必要なのだと思います。Redmineのワークフローには、そのような抽象度の高いドメインモデルが隠れているのかも知れません。

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


Redmineチョット入門 - 話題のRedmineの魅力を知ろう- #benkyoenkai

第42回IT勉強宴会 話題のRedmineの魅力を知ろうで発表しました。

これまで雑誌やムックにRedmineの紹介記事は書いていましたが、人前で30分もRedmineの紹介をするのは今回が初めてでした。 入門なので障害管理の定義から入る事も考えましたが、 Redmineがなぜはやっているかというテーマ、かつ、前田さんの前座なので問題から入ったのですが、前田さんとかぶったり、物足りなかったりで、難しかったです。

チケット駆動開発はRedmineだけのものではありませんが、やはり多機能なRedmineの魅力はチケット駆動開発で活きるのだと思いました。

以前Redmineは帳票ワークフローシステム?に書いたRedmineの特徴の一つであるワークフローの設定について、発表では開発の都合でUIが設計されている様に説明しました。しかし、説明をしたり懇親会の話を聞いていて、少し違う(ドメイン分析の結果)かもしれないと思いました。詳しくは別記事にまとめました。

なお、Redmine.jpの前田さんの発表についてはその2をご覧下さい。

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


より以前の記事一覧