アジャイル開発において、技術と品質の重要性は不可欠だ（後編）。Agile Japan 2013
年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。 （本記事は「アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013」の続きです） 品質を作り込むプロセス コンピュータサイエンティストとして有名なEdsger Dijkstraは、信頼性の高いソフトウェアが必要であれば、最初からバグを避ける方法を探さなければならないことに気づくだろう。と言っています。 つまり、バグを作り込まない、品質を作り込むプロセスにすることで、大事な時間をデバッグに使われないようにするのです。 テストドリブン
アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013
年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。 アジャイル開発とは、単にすばやく柔軟に開発する手法なのではなく、そこに品質を作り込んでいくことが欠かせないのだ、というメッセージでした。非常に多くの内容が詰め込まれた講演でしたが、その概要を記事として紹介しましょう。 “Demand Technical Excellence”アジャイルにおける技術と品質の重要性 James Grenning氏。 その前に、私がアジャイル開発に関わった経緯について触れておきましょう。 1999年当時、私はRobert Martin（著名な
受託開発にアジャイルは適用できるか？
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
【資料公開】アジャイルな開発からアジャイルな組織へ
みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく（したがってスクラムやXPを導入しているからといって自分たちのアジャイル度合いが高いとは限らない）、目的に応じてそれにあった方法、自分たちがゴールを達成するのに最適だと思う方法を脳みそ振り絞って考
Web開発チームをタスクボードだけで見える化する 5つのコツ - Lancers開発ブログ
はじめまして。今月からランサーズにJOINしましたkeiと申します。 長らく更新が滞っていた本ブログですが、これから定期的に情報発信していこうと思ってますので、どうぞよろしくお願いします！ ランサーズでは、エンジニアの作業を見える化するために、タスクボードを導入しています。 今回は、社内で運用してみて効果的だった5つのコツをご紹介します。 タスクボードとは ボードを作業予定、作業中、作業完了(ランサーズではToDo,Doing,Done)の3つのレーンに分け、タスクをその状態に応じて適切なレーンに置くことで、タスクの見える化とステータス管理を行うツールです。 ランサーズでは、ボードとしてホワイトボードを、タスクは付箋に書いたものを貼って運用しています。 運用ルール ランサーズでは、以下の流れでタスクボードを運用しています。基本的な流れは、よくあるタスクボードの運用方法と同じです。 発生し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
