ソフトウェア開発に携わるすべての人に捧げる、アジャイルにソフトウェアを開発する為に読むべき15冊 | Act as Professional
私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
「アジャイルプラクティス」はスゴ本
marsさんが、「システム開発に関わる人はみんな読めー」と強力にオススメするにつられて読む。これはスゴ本。marsさん、良い本を教えていただき、ありがとうございます。 ■ どんな本? 本書は、開発現場で培われた「成果を出す習慣」を、45のプラクティスとして紹介している。開発速度を大幅に上げたり、高速納期を目指すような、「アジャイル開発プロセス」という決まったやり方は、存在しない。アジャイルな開発とは、現場でのさまざまな活動をアジャイルにしていく――つまり、変化に適応することを継続させていく―― 「習慣」だということに気づく。協調性+フィードバックによるプラクティスは、あまりにもあたりまえすぎて見過ごされがちかと。その反面、意識して実践するならばこれほど心強い金棒はないだろう。 ■ 忘れがちな基本中の基本「成果をあげるのが仕事」 面白いのは、「悪魔の囁き」と「天使の導き」との間で揺れ動く「感
Agile in 30mins - 30分でだいたいわかるアジャイル開発
Are you ready? ～これからアジャイル開発をスタートアップするために プラクティスの実践と実感～
情報処理推進機構：ソフトウェアエンジニアリング：非ウォーターフォール型開発に関する調査結果公開
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyやRailsやアジャイル開発などの昨今の話題を日本のIT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構：ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
