みなさんこんにちは。@ryuzeeです。 アジャイルな開発で利用できるツールはたくさんありますが、その導入の仕方について賛同できる記事があったので意訳にてご紹介します。 なおターゲットのチームはco-locateしたチームです。 元記事はMarc Löffler氏の5 Steps to Introduce an Agile Toolになります。 世の中にはかなりたくさんのアジャイル開発用のツールが出回っている。マイク・コーン氏のWebサイトにそれらのツールの長〜いリストがあるので見てみると良いだろう。しかし、こういうツールを自分のチームや会社に導入するには、どういう方法を取れば良いのだろうか？以下にまとめてみた。 1. 最初はツールなしで始めるツールを持ったバカはやっぱりバカだｗ。とても洗練されているアジャイル用のツールを導入する前に、まずScrumやXPやKanbanやその他のメソッドが
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムの優先順位を決めるにはいくつかの方法があります。 Backlog Prioritization Techniquesにて、いくつかのやり方が説明されていましたので抜粋・意訳にてご紹介します。 どれを使うかは、そのプロダクトが自社製品かどうか、その製品の新規性の有無、開発の体制などなど、コンテキストに依存するところがあるので、どれが一番良いというのはありません。 ただ、分かりやすいという点では、狩野モデルは良いと思っています。 MoSCoW法M 絶対必要S できれば実装すべきC 他への影響がなければ実装できるとよいW 今回は実装しないが将来に実装するかもそれ
チケット駆動開発でのリスケについての質問を見つけたのでメモ。 下記はあくまでも僕の一意見。 ラフなメモ書き。 【元ネタ】 チケット駆動開発でのリスケジュール方針について | OKWave 【1】チケット駆動開発をAgileに運用しているなら、チケットのDoneの条件はリリースする事。 すなわち「バージョンをCloseする＝リリースした」「バージョンをCloseできない＝リリースしていない」になる。 もし、遅れたチケットを無視してリリースしたなら、チケットは延期されたことを意味している。 つまり、遅れたチケットは次のバージョンへアサインされることと同義だ。 チケット駆動開発において、リスケのタイミングといつだろうか？ Agileに開発しているなら、朝会だ。 Scrumならデイリースクラム、XPならスタンドアップミーティングに相当する。 PLは課題解決マシーン。実作業はメンバーにお任せ。 課題
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
「プロジェクト失敗率とリスク」の続き。 id:suikyojinさんからトラックバックをいただいた。 大規模Agileの失敗率は驚異的に低い? そもそも、大規模プロジェクトの失敗率って、ものすごく高くて、70%とか80%とかいった数字を見たことがある。基準が同じとはかぎらないので、断定できないが……。 そうなのです。「失敗」の定義は意外と難しい。随分前に訳した「失敗とは何か」では CHAOSレポートによれば、成功するプロジェクトの割合はたったの34%だそうな。 Standish GroupのCHAOS reportは、長年に渡ってドブに捨てられてきた何十億ドルにもなるIT関係プロジェクトの話を延々と述べている。34％の成功率っていうのは実は改善された数値で、2001年の調査では28％だったんだな。 とのこと。失敗率66%。ただし、この記事でMartin Fowler氏は 納期が遅れたとか予
第4回特別コラム 「なぜそんなにも（アジャイル開発者にとって）Wikiは重要なのか」 角谷信太郎 2008-04-22
今日は6時間半ほど、人生初のペアプロを体験しました。 これはすごい、まじで凄い！ Before After形式で簡単に僕の感じた印象の違いを挙げると Before なんか楽しそう 二人で1台のマシン使うのはちょと微妙 監視されてるようなもんで気が休まらなそう じっくり一人で考え込めないんじゃないかな 細かいところにこだわれなくなりそう と言うか正直作業してる所みられるの恥ずかしい ついでに言うとキーボード打ってない時間で暇で死にそう After なんか楽しいなんてレベルじゃなく、恐ろしい勢いでソースができあがって快感 一人の時に何気なくやっちゃう時間の無駄遣いが皆無 自分じゃ気付いてないソース中の間違いに速攻で突っ込みが入る IDEの使い方とか変数名の付け方とか、様々な箇所で二人の知識の良いところ取りが出来る 一人で悩んでるより二人でギャンギャン言い争ってた方が結論が出るのが早い 一人だっ
Web2.0とは何かを定義するのは難しいが，大きな流れとしてテクノロジからビジネスへと多くのエンジニアが視点を移していることは間違いないだろう。言語，設計，コンパイラ，ライブラリ，といった要素技術から，SOA（Service Oriented Architecture）の視点，例えばGoogle APIをどのように使ってサービスをミックスし，新しいビジネス価値を提供できるか，というサービスの視点がより時代に合ったものになっていると思う。エンジニアがビジネス・モデルに関心を示し，ビジネスの言葉で技術を語るようになってきているのだ。さらに，アジャイル開発の考え方が浸透し，「ビジネス価値（Business Value）」を開発の最優先とする考え方が広まっているという背景もある。 この連載では，このような時代におけるソフトウエア製品開発にはどういった視点が必要か，また，その開発はどのような手法によ
^<< 2007.09/1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>$
XPairtise - A Distributed Pair Programming Plug-in For Eclipse Introduction The Eclipse plug-in XPairtise provides a platform for distributed pair programming. The plug-in offers shared editing, project synchronization, shared program and test execution, user management, built-in chat communication and a shared whiteboard. Pair programming is a key practice in eXtreme Programming (XP) whereby two
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
