ReVIEW + Jenkinsでドキュメントを常時ビルドする
ReVIEWはマークアップ言語でソースを記述することで、html形式やPDF形式の綺麗な体裁の文書を作れるオープンソースのツールです。入手はhttp://github.com/kmuto/review から可能です。例えば = 章 == 節 === 項 * 箇条書き * 箇条書き のような書き方をするとhtmlであれば、それぞれh1〜h3に変換されたり、ulに変換されたりします。PDFの場合は予め規定された体裁に変換されます。 今回は、Windows Azure上の仮想マシン(Ubuntu12LTS)上で、このドキュメントを常時ビルドする方法を紹介します。 ReVIEWのインストールReVIEWは動作にrubyが必要です。また最新版はgithubにて提供されていますので、gitを導入しておきます。 sudo su apt-get install ruby apt-get install g
“開発のよくある問題”を解決するCMMIの3大メリット－ ＠IT情報マネジメント
効率的に開発作業を行うために、どのような業界標準を使っていても、さらなる改善に組織を導いてくれるCMMI。今回はその3大メリットを紹介する。 （→記事要約<Page 2>へ） 前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功を目指したものである」と解説しました。 また、以下の図1はIT業界で使用されている開発の主な標準モデルと、そのカバー範囲をおおまかに示したものですが、このように、アジャイルとCMMIなど「一連の業界標準はお互いに排他的ではなく、重なる部分が多い」ことも紹介しました。すなわち、今現在スクラムを使って開発作業を行っている場合でも、作業を改善するためにCMMIを有効に使うことができるのです。 図1 IT業界で使用されている主要な業界標準
中規模大規模プロジェクトにアジャイル開発を適用するにはどうすればいい？ IPAが14件の事例を基に報告
中規模、大規模のアジャイル開発において成功に寄与する主な要因は、リーダーシップを発揮するキーマン、教育と経験、段階的な導入、などの内容を含む報告書を、独立行政法人情報処理推進機構（IPA）が公開しました。 報告書のタイトルは「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査 調査概要報告書」で、プロジェクトの実メンバー数が30名から100名程度を中規模、100名以上を大規模と位置づけ、中規模の事例6件、大規模の事例4件、そして中規模大規模のプロジェクトで部分的にアジャイル開発を適用した事例4件を基に書かれました。 プロジェクトの内容はゲームソフト、ソーシャルゲーム、SNS、医療健康関連、ECサイト、基幹システムなどで、自社開発、受託開発ともに含まれています。 公開された概要からポイントを引用します。 非ウォーターフォール型の方が「いきいきしている」 基にした14件の事例。
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
アジャイル開発＆TFS導入
バックログとタスクをインポート・エクスポート Team Foundation Server と Excel・Project との連携
要件におけるユーザーストーリーの利点 - winplusの日記
これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
第3回 選択される開発内容 | gihyo.jp
はじめに 本連載では、「透明性」というキーワードで、アジャイル開発について説明してゆきます。前回は、開発者が顧客に対して透明性を提供することの重要性について解説しました。その一つの大きな手段として、継続的かつ頻繁なリリースを取り上げています。しかし、部分的に出来上がった画面を見せられて、顧客は何ができあがっていて、何が不足しているのかをどのように判断すれば良いのでしょうか?それを判断する為には、事前に今回のリリースで何を開発し、何を開発しないのかについて、顧客自らが選択し、意思決定しておく必要があります。第三回目の今回は、このような顧客による開発内容の選択の意味について、整理してみたいと思います。 ストーリーについて 一般的なウォーターフォール型のソフトウェア開発では、まず要求仕様を整理し、そこから機能を洗い出します。要求仕様は、顧客の言葉で表現された、利用する側からみたソフトウェアの振
要求開発とアジャイル開発(1)
現在のシステム開発プロジェクトの状況を見ると，いわゆる生産管理，経理といった従来からある業務のシステム化といったプロジェクトに加えて，Webシステムに代表される，従来無かったような新業務に対するプロジェクトが増加しています。 そうした業務のシステム構築は要件を固めにくく，予想もしにくい状況にあります。また，ビジネスの変化に伴ってシステム自体も非常に変化が激しいという特徴を持つことが多いようです。 そのような現状において変化に強い「アジャイル開発」は非常に魅力的です。本稿では，顧客サイドからの視点で「アジャイル開発」を総括し，「アジャイル開発」を行うときの，「要求開発」の可能性を検討してみたいと思います。 アジャイル開発とは XP（eXtreme Programming）に代表される繰り返し型の開発方法論をさします。特徴としては現場サイド（プログラマ）から出てきた開発方法論であり，変化に柔軟
無差別に技術をついばむ鳥アジャイル開発は、本当に大規模システムの開発に向いていないか？
「アジャイル開発は大規模システムの開発に向かない。大規模システム開発はウォーターフォール開発モデルの方が向いている」という言葉をよく聞きます。私も当初その意見に同意でした。しかしながら、最近はちょっと違うのではないかと考えました。 違和感の元は理由です。大規模システムの開発に向かない理由として、計画と設計が不十分である事が挙げられています。これは十分に納得できる理由です。計画と設計が不十分ならば、プロジェクトが失敗するのは当然です。しかし、この問題をアジャイル特有の問題として正しいと仮定すると、アジャイル開発は計画と設計をおざなりにしている事になります。しかしながら、アジャイル開発はプロトタイプ開発モデルではありません。似ていますが、思想が根本的に異なります。計画と設計をおざなりにして、場当たり的に実装する開発モデルではありません。 その事は、アジャイル･アライアンスの原則とアジャイルソフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実用主義者が勝ったのか？Water-Scrum-Fallが一般的に
User storymapping in 10 minutes
リーン/アジャイルな要求獲得のためにユースケースは価値がある（オプションだけど）
TFSによるアジャイル開発の実践
アジャイルのまずい考え方