タグ

agileに関するpalm3rのブックマーク (21)

  • ペアリング対コードレビュー: 開発者文化の比較

    前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって

  • 海外でなぜアジャイル開発が普及しているのか? IPAが分析と提言

    海外ではなぜアジャイル型開発が普及しているのか、IPA(独立行政法人情報処理推進機構)が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 (非ウォーターフォール型開発の海外における普及要因編)」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル

    海外でなぜアジャイル開発が普及しているのか? IPAが分析と提言
  • いまアツいアジャイルプロジェクト管理ツール9選+Pivotal Tracker入門

    いま再びキてる「アジャイル」開発 世界で広がりつつあるアジャイル 2001年の「アジャイルソフトウェア開発宣言」から10年が経過しました。アジャイルマニフェスト登場当時の熱狂的な雰囲気は一時期停滞気味でしたが、最近再びアジャイル開発が広がりを見せています。 その理由の中心は、ITの進歩や世界のボーダレス化とともに、ビジネスの変化のスピードが早くなり、競争が激化したため、一刻も早く顧客に新しい価値(ソフトウェア)を届ける必要性が増したため、アジャイルに開発する必要が出てきたためでしょう。 欧米はもちろん、日でもアジャイルに対する注目は増していて、先日開催されたDevelopers Summit 2012のデブサミ2012アワードでも、角谷信太郎氏の講演『アジャイルマニフェスト ディケイド』が1位を取り、来場者数も過去最高を記録するなど高い注目を浴びています。 群雄割拠 アジャイルプロジェク

    いまアツいアジャイルプロジェクト管理ツール9選+Pivotal Tracker入門
  • 中規模大規模プロジェクトにアジャイル開発を適用するにはどうすればいい? IPAが14件の事例を基に報告

    中規模、大規模のアジャイル開発において成功に寄与する主な要因は、リーダーシップを発揮するキーマン、教育と経験、段階的な導入、などの内容を含む報告書を、独立行政法人情報処理推進機構(IPA)が公開しました。 報告書のタイトルは「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査 調査概要報告書」で、プロジェクトの実メンバー数が30名から100名程度を中規模、100名以上を大規模と位置づけ、中規模の事例6件、大規模の事例4件、そして中規模大規模のプロジェクトで部分的にアジャイル開発を適用した事例4件を基に書かれました。 プロジェクトの内容はゲームソフト、ソーシャルゲームSNS、医療健康関連、ECサイト、基幹システムなどで、自社開発、受託開発ともに含まれています。 公開された概要からポイントを引用します。 非ウォーターフォール型の方が「いきいきしている」 基にした14件の事例。

    中規模大規模プロジェクトにアジャイル開発を適用するにはどうすればいい? IPAが14件の事例を基に報告
  • アジャイル開発 基本のキ - ヲトナ.backtrace

    今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル

    アジャイル開発 基本のキ - ヲトナ.backtrace
  • 「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から

    アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」(What Is Next In the Agile World)と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し

    「アジャイルの現状と未来、次に来るもの。~リーン開発への展望~」Agile Japan 2010基調講演から
  • 日本のアジャイルは海外と比べると周回遅れか、アジャイル開発が国内で普及するには? IPAの報告書から

    海外ではアジャイル型開発の採用は開発企業のステータスとしての側面があり、現在のアジャイルの次にくるものの議論が始まっている。我が国の状況は周回遅れとも表現されることが少なからずあった。 日エンジニアが生き生きと働くためにどうすればよいのか? その一環として独立行政法人情報処理推進機構(IPA)が発表した「非ウォーターフォール型開発に関する調査」では、まとめとしてこのような説明が掲載されています。 アジャイル開発普及のための3つのポイント こうした状況を脱し、国内でアジャイル開発を普及するためにどうすればいいのでしょうか? 発表されたIPAの報告書では次の3つの指摘がありました。 (1) ビジネス等のコンテキストに応じた開発方法の選択 開発するソフトウェアの特性やプロジェクトに与えられる制約などを踏まえ、妥当な開発手法を定めた結果として、ウォーターフォール型開発色が強い場合もあれば、その

    日本のアジャイルは海外と比べると周回遅れか、アジャイル開発が国内で普及するには? IPAの報告書から
  • 情報処理推進機構:ソフトウェアエンジニアリング:非ウォーターフォール型開発に関する調査結果公開

    SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー

  • 問題を抱えてしまったソフトウェア工学を、もう一度やりなおそうという活動

    「Software Engineering Method and Theory」(ソフトウェア工学の方法論と理論)の頭文字を取った「SEMAT」というWebサイトを中心に、問題を多く抱えてしまっている現在のソフトウェア工学をもういちど作り直そう、という活動が始まっています。 この活動については、アジャイル開発手法の第一人者でもある平鍋健児氏のブログ「An Agile Way」で2月28日にポストされたエントリ「SEMAT.org にて「ソフトウェア工学再建」運動が開始」で紹介されています。 そしてその平鍋さんが、この活動に関する「ビジョンステートメント」を日語訳にして公開されました。 ソフトウェアの工業化には工学の進化も重要ではないか ソフトウェアの開発というのは、エンジニアが顧客のために1つ1つ精魂込めて作るようなことが多い、職人的な色彩が強いのが現状ではないかと思います。これがいま、

    問題を抱えてしまったソフトウェア工学を、もう一度やりなおそうという活動
  • アジャイル開発の潮目が変わった

    ここ一年、アジャイル開発の取材がぐっと増えた。アジャイル開発が日に上陸して10年、記者が追うようになって8年。今ようやく、地に足がついた形で盛り上がってきたと実感している。 そう思う理由の一つは、取材先が多様になってきたことだ。最近は、一般企業や自治体で働くCIO(最高情報責任者)やシステム部長、大手ベンダーの幹部、経済産業省の外郭団体である情報処理推進機構(IPA)などがアジャイル開発を“熱く”語り始めた。 開発プロジェクトにも広がりが出た。数年がかりでの基幹系システム刷新、SOA(サービス指向アーキテクチャ)にのっとったシステム開発、クラウド上でのSaaS型サービスの開発、ケータイ向けのソーシャルゲームの開発などでもアジャイルが利用されている。 記者がアジャイル開発を追い始めたころ、取材先はたいてい小規模のベンダーか技術に長けたリーダーだった。開発対象も情報系システムばかりで、しかも

    アジャイル開発の潮目が変わった
  • アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

    全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey 「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。 滝 「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

    アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
  • 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey

    での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数%程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日SIerに務めています。日では、設計書をエクセルを使って画面や処理などの書類を作成しています。海

    「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey
  • アジャイル開発のためのプロジェクト管理·Agilo MOONGIFT

    アジャイル開発にとって重要なのは、スクラムを組み、一気通貫で開発してしまう勢いだ。手間のかかるタスクの登録やステータスの更新その他諸々の面倒ごとをやっていたら時間はあっと言う間に過ぎ去ってしまう。 タイムライン 例えばTracは素晴らしいプロジェクト管理だが、少々画面が素っ気ない。そこでもっと便利に使えるAgiloを紹介しよう。 今回紹介するオープンソース・ソフトウェアはAgilo、アジャイル開発を進めるためのプロジェクト管理だ。 Agiloはアジャイル開発を基としたプロジェクト管理だ。VMWareのアピアランスも提供されているので、すぐに試すことができる。また、Tracのプラグインとしても提供されている。Wiki、タイムライン、ロードマップ、チケット、検索といった一般向けの機能に加え、チーム管理、グラフといった管理機能がある。 グラフ 何よりインタフェースがボタンを中心になっている。こ

    アジャイル開発のためのプロジェクト管理·Agilo MOONGIFT
  • - eXtreme Programmingの魅力を探る

    (株) 永和システムマネジメント 平鍋 健児   Kenji HIRANABE 作成日:第4版 2001,8/10 第3版 2001,1/16 第2版 2000,10/21 初版 2000,10/10 エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)である. 正式にはエクストリームプログラミング(eXtreme Programming), 略してエックスピー(XP)と呼ばれる.この記事でも,以下 XP と呼ぶことにする. Kent Beck は,'99年に "Extream Programming Explained - Embrace Change" という書籍を著した.これは "EC " とも呼ばれ,XP のバイブルともなる. この記事では,この "EC" を基礎に XP のエッセ

  • アジャイル開発と反復開発の落とし穴

    前回「『現状のソフトウェア開発は間違っていないか?』(プロセス編)」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発(*1)やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 (*1)反復開発とは例えばRUP(Rational Unified Process)やUP(Unified Process)のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる

    アジャイル開発と反復開発の落とし穴
  • 「現状のソフトウェア開発は間違っていないか?」(プロセス編)

    失敗例その1 「要件定義が終わらない」 ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに1カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。 失敗例その2 「設計工程の無駄」 オープン系の開発でウォーターフォール開発を行っている。設計工程は、基設計、詳細設計に分かれている。基設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるた

    「現状のソフトウェア開発は間違っていないか?」(プロセス編)
  • プラグマティックが止まらない ――「現実駆動開発」のススメ

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    プラグマティックが止まらない ――「現実駆動開発」のススメ
  • バグ見つけた→それってどんなテスト?もしくは、なんでMVCなんて使うの? - D-6 [相変わらず根無し]

    バグ見つけた→それってどんなテスト?もしくは、なんでMVCなんて使うの? 最近ソフトウェアエンジニアリングに置ける開発手法に関して考えている。 ぶっちゃけ言ってしまうと「やっぱりTDDっぽいのがいいな」というところに落ち着きつつあるのだが、厳密にTDDをしたほうがよい、と思ってるわけではない。TDDとかExtremeプログラミング、Agileプログラミングにしても理想はいいんだけど、原理主義っぽい使い方は現実にそぐわないと思ってるからだ。 前置きはこれくらいにしておいて・・・重要だと思うのは以下の点: 開発サイクルに自動テストツールを組み込むエンジニアによるバグ/不具合発見時には「動かない」は許可しない。必ず再現コードを提出してもらうテストを自動テストツールを組み込む(=次回リリース前にはかならずテストを実行できる状態にする)テストが通るまで修正を続けるという開発サイクルを取るべきだ、とい

  • 2008-02-26 - ひがやすを blog - アジャイルなフレームワーク開発

    継続的リリースは、さらなるアジャイルさを与えてくれるか? 早く頻繁なリリースにはメリットもデメリットもあります。 メリットは ユーザが素早いフィードバックを得られる。 開発者が素早いフィードバックを得られる。 開発のサイクルが早くなり、より市場にあった機能が提供できる。 デメリットは リリース回数が増えるとそれだけ開発者(リリース作業を行なう人)の負荷が大きくなる。 リリース回数が多いと不安に思う人がいる。 私は、もちろん、早く頻繁なリリースは必要だと思う派です。 私の根には常にXPの教えがあります。 開発者のモチベーションが最も重要。 先のことは無理に予想せずに見えている範囲で作業を進める。(YAGNI) 状況に応じて臨機応変に対応する。 素早くユーザにフィードバックする。 テストをすることでコードからフィードバックを得る。 この辺が、私が、いつも心がけていることです。実際のプラクティ

    2008-02-26 - ひがやすを blog - アジャイルなフレームワーク開発
  • livedoor Developers Blog:チケット駆動開発の研究と実践 - livedoor Blog(ブログ)

    こんにちは、そろそろ花粉のシーズンが近づいてきて戦々恐々としている金子です。 今年も花粉対策グッズの CM に注目しているのですが、花粉鼻でブロックがいいんじゃないか?と思っています。 花粉症のくしゃみ鼻水は、人が辛いのはもちろんですが周囲にとっても気分の良いものではありませんよね。エチケットとしても花粉対策は怠らないようにしたいものです。 チケットついでに今回はチケット駆動開発の話をします。想定読者は Trac をリポジトリブラウザとして利用しているがチケットは使ったことがない人です。Trac、 Issue Tracking System という用語に馴染みのない方は、それぞれ関連リンクを用意しましたのでそちらをご覧ください。 以下、僕の経験に基づき「チケット駆動開発とは何か」「何が目的か」「どう実践したか」「結果が出たか」についてレポートします。だいたいここ二週間くらい、チームではな