「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証
本スライドは、SQiP 2014（ソフトウェア品質シンポジウム）に採録された経験論文の口頭発表用スライドです。 https://www.juse.jp/sqip/symposium/archive/2014/day2/ 経験論文のダウンロードはこちらです。 https://www.juse.jp/sqip/symposium/archive/2014/day2/files/ronbun_A3-4.pdf 又は http://www.slideshare.net/kakahane/s-qi-p2014kuniharuakahanea34 【経験論文】 「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証 赤羽根 州晴 氏 （株）島津ビジネスシステムズ 【概要】 企業が使用する業務用ソフトウェアシステムの多くは、複数のIT統制、監査、認証に対応しなければならない。経営管理
[#TiDD] 個人のタスク管理からチケット駆動開発の特徴を考える ＃RxTstudy - ソフトウェアさかば
小川さんとの共著「Redmineよるタスクマネジメント実践技法」には、個人タスクの管理方法として2つの話を載せています。 松下幸之助氏の仕事術：多忙な松下幸之助氏は1日の仕事を書きだしてから仕事を始めることで、収まりそうにないタスクを実践できていた(という伝聞)。 個人のタスク管理はメールを使え！：Redmineを個人のタスク管理に使ったが、楽しくなくてすぐにやめた話。 これらは、チケット駆動開発の特徴を示していると思います。まず、松下幸之助氏の話は、 仕事の可視化によって全貌が把握できる ゴールを明示することで、計画的に達成できる ということを示しています。これはチケット駆動開発と共通する特長です。 もう一方のメールには、以下のような特長があります。 メールに作業書くことで、作業の漏れを防止できる(未来の自分への作業指示) 未読、優先順位、フォルダ分けなどの属性を管理に用いることができる
![[#TiDD] 個人のタスク管理からチケット駆動開発の特徴を考える ＃RxTstudy - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
[#TiDD] プロセスモデリングにおけるチケット駆動開発の可能性 - ソフトウェアさかば
プロセスモデリングの目的は、プロセスを他の人に示し、伝達し、教育することです。また、モデルを元に問題点を明らかにして改善することができます。また、シミュレーションによる予測も可能になります。チケット駆動開発におけるBTSのチケットは、タスクの計画であり、履歴です。この情報は非常に価値のあるものです。 近年、注目されている研究分野にリポジトリマイニングというものがあります。リポジトリとはソフトウェアの開発基盤のデータのことです。具体的には構成管理ツール、障害管理ツール(BTS)、メールサーバなどのデータを分析する研究です。ソースコードのメトリクスを元に障害の含まれていそうな(フォルトプローン)モジュールを探す。構成管理ツールのコミット履歴から、別の障害と関連(ロジカルカップリング)するモジュールを探す。あるいは障害履歴からプロジェクトの今後の予測を行う。など、多くの研究が行われています。 1
３年間Redmineでチケット駆動開発をしてきて思うこと：Cathedral Break in Action：オルタナティブ・ブログ
いまのプロジェクトを初めてもう３年ほどになりますが、この課題管理をずっとチケット管理システムであるRedmineでやってきました（Trac本を執筆したというのにRedmineを使った理由はいろいろありますが、マルチプロジェクトが必要だったのが大きいですかね）。とくにノウハウと言うほどのものはありませんが、年度末なので使ってきて思ったことを色々書いてみます。かなりまとまりがないのでご注意ください。 まず、プロジェクトの特徴から。 基本的に少人数のプロジェクトです。多いときでも４人。作っているのは、Windows向けのパッケージ製品（言語はC#）で、開発を初めて一年半ほどで正式リリースをしました。正式リリース後の保守＋追加開発フェイズはほとんどメンバーはぼく1人でした。リリース計画はメジャーリリースの一回のみははっきり決まっていましたが、その後のマイナーリリースについては、お客様からの要望があ
[#TiDD] チケット駆動開発もAgileもより本質の議論に #aj12 - ソフトウェアさかば
まず、あきぴーさんの「チケット駆動開発の課題と展望」、次に中村さん「Redmineと守破離」で、最後に私が発表しました。 あきぴーさんがチケット駆動開発を展開する際の課題を話され、中村さんがRedmine導入の守破離を話されました。そして私が、最近はチケット駆動開発が難しいとか、うまくいかないというお話を聞くようになったので、成功のためにはビジョンが必要だというお話をしました。 3人で共通のポイントは「形骸化を恐れる」ということです。チケット駆動開発は広く普及しだしています。今回150名ほどの参加者のうち、半分近くの方がすでに実践されているようでした。 今回の発表内容も、ちょうどCMMが本格的に普及しだした頃に似ています。それまでの一般論から、組織に対する実践の議論に向かいました。どのように普及させるか、「守破離」などと言う言葉もそのころに出ていました。いかに現場に浸透させるか、以下に根付
Tracのワークフロー - プログラマの思索
Tracを使い始めて、Redmineと異なる視点を感じる所があったのでメモ。 【1】RedmineやTracを障害だけでなく要望も含めてタスク管理する発想は、Issue Trackingと呼ばれる。 元々、チケット駆動開発(Ticket Driven Development)は、バグ管理システム(Bug Tracking System)を汎用化した課題管理システム(Issue Tracking System)から発生した開発プロセス。 すると、障害管理で使われるステータスだけでは管理しにくい場面が出てくる。 例えば、ITILではシステム運用保守で、問題管理、インシデント管理、変更管理、リリース管理の4つの視点を提供する。 BTSのバグ管理は、問題管理と同じ。 問題管理のワークフロー(チケットの状態遷移図)は下記が普通だろう。 新規→担当→解決→検証中→検証完了→終了(リリース完了) このパ
[Think IT] 第3回：チケットドリブン開発でバグ削減！ (1/3)
【バグ管理の作法】Trac徹底活用！ 第3回：チケットドリブン開発でバグ削減！ 著者：masuidrive 公開日：2007/12/20（木） チケットが中心の開発手法 「第2回：なぜTracの導入に失敗するのか？」では、Tracの中心機能となるチケットについて説明し、導入のポイントをまとめた。今回はチケットを開発の中心位置に持ってくる「チケットドリブン開発」について解説していこう。 チケットドリブン開発とは チケットドリブン開発（チケット駆動開発：Ticket Driven Development）とは、チケットを書いてから開発を行うという手法だ。読者の皆さんもご存じのようにテストドリブン開発（Test Driven Development）をもじったものである。このチケットドリブン開発は「まちゅダイアリー（http://www.machu.jp/diary/）」のまちゅ氏がITpro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20090301/p01/