無料ブログはココログ

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

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を選択する際の重要なポイントの一つでしょう。

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


[#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!

Ultimate Agile Stories (UAS)は全5册からなるアジャイル同人誌です。

この本は、アジャイルのコミュニティの人達の熱い思いを綴った記事をまとめたものです。頒布による利益は、東北の震災の年から5年間寄付されてきました(まだ在庫があるので、寄付したぐらいの赤字だそうです)。

私もアジャイル関係のコミュニティに出入りしていましたし、日本XPユーザー会関西支部(XPJUG関西)でチケット駆動開発の分科会があったことなどから、全ての本に寄稿させていただきました。

これまで、次の本が出る度に1年前の寄稿を公開してきました。しかし昨年、とうとう最終号になってしまいましたので、これまでの寄稿をまとめて公開します。

UASには、アジャイル放談という飲みながらそれぞれの思いを熱く語り合った記事があります。そろそろ若い人に任せた方が良いのではないか、などと思いながら、なぜか全てに参加させていただきました。

この他にも有名な方々の記事がたくさん載っていますので、機会を見つけてぜひ購入してください(トップのリンク参照)。



UAS5の寄稿

<UAS5の紹介>
[#UAS] アジャイル開発とフィードバックそしてリスク - Ultimate Agile Stories Iteration 5 -



UAS4の寄稿



UAS3の寄稿

<UAS3の紹介>
[#Agile] 自己組織化あるいは自律的組織 #UAS3



UAS2の寄稿

<UAS2関連記事>
[#TiDD]ウォータースクラムフォールよりも五月雨WFの方が変化に強い!(かも)



UAS1の寄稿

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


そりゃそやろ! - 「アジャイルがダメだと思う7つの理由」について議論して -

「アジャイルがダメだと思う7つの理由」について議論する会を大阪でに参加しました。3年前の元ネタと最近の様子に関する鈴木雄介さんの講演のあと、グループ毎に議論しました。

元ネタについてはすでに書いています(アジャイルがダメだと思う7つの理由を前向きに考えてみる)が、今回はこれまでの経験を踏まえて議論をしてきました。

講演内容

まず、「アジャイルがダメだと思う7つの理由」についてのお話がありました。そして、当時はアーキテクチャとアジャイルのコミュニティが対立していたことからアーキテクトである鈴木さんがアジャイルをあまり良く思っていない事、最近はアジャイル風の繰り返し開発をされている事、をお話しされました。

私も、アジャイル開発の「考え方」と「やり方」を学べ[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -で同じような開発方法を書いてます。

ウォーターフォール開発をベースにアジャイル開発を参考にすると言う話は昔から書いてますが、最近はウォーターフォールがベースに開発する多くの人が工夫しているのでしょうね。

変化ヲ抱擁スルために固定化している

講演の後は7つの理由のグループに分かれて2回の議論しました。というか、賛成と反対の意見に分かれてディベートをしました。1回目は「 変化ヲ抱擁スルために固定化している」です。

元記事では暗黙知の事を書かれていますが、アジャイル宣言の背後にある原則

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

を取り上げて、プロセスを固定化として、最適化できないとの議論を展開しました。関連するシステムがあり、期限が限られているので、定期的なリリースにあわせる事はできません。

反対意見では、スプリント中にリリースするタスクを作って実施しているとのお話がありました。実務的にはそうでしょうけど、それは原則に従っているのか、1週間ごとのリリースや1日に何度もリリースして、アジャイルというのと同じではないかと言いました。

この他にも2ヶ月ほどの短期開発では、タイムボックスごとのふりかえりなどもあまり効果的でなく、期間内で最適化する方がうまくいくのではというお話をしました。

どこまで原則を守らないとアジャイルと言えないかとの議論はありましたが、それ以外の反論はありませんでした。

なお、そういったシステム間の連携があったり、短期間のプロジェクトが一部の例外と呼べる組織なら、アジャイル開発を標準とすることもアリだと思います。

アジリティはアジャイルだけのものではない

2回目の議論ではグループの全員が「そりゃそうだ」と賛同しましたので、議論というよりは意見交換になりました。

アジャイル開発はアダプティブ(適応型)であるのが基本で、アジャイル(機敏)というのは風呂敷が大きすぎるのではないかと言いました。機敏を実現するには高速開発等の環境やツールなどもあるからです。

ただ、アジャイル開発があったからリーンスタートアップが生まれたんだよね。という意見には賛同しました。そういう意味では、「 アジリティはアジャイルだけのものではないが、アジリティの本家だ」ということだと思います。

おわりに

この記事を書き出してからゆっくり考えました。

私自身はアジャイルに反対している訳でなく、向いている所で実施すべきものだと思っています。

そもそもアジャイルソフトウェア開発宣言は、当時のソフトウェア開発の解決すべき問題点を示しており、誰もが考慮すべき事であると思っています。

しかし、厳密な定義を元せずアジャイル開発の議論をすると、きちんとした技術論にならず、いつもながら不毛になりがちだと思いました。

アジャイル開発であるかどうかは開発者の関心事ではなく、顧客に価値を提供するより良いソフトウェアの実現が関心事です。アジャイル開発に対する議論はもう終わりにして、どのような現場の問題をどのように改善したかを議論したい思いました。

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


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