当サイトは ... ソフトウェア開発に関する技術について実践、研究、発表するグループ、「オブラブ」のページです。 XP及びモデリング、PFについてのコミュニティや、ドキュメント、フリーソフトウェアで構成されています。
『プログラマ35歳定年説』を覆した実例に迫る 働き方が多様化した現代において、『 プログラマ35歳定年説 』は過去の話と一蹴することはできる。しかし依然として、通説が健在しているケースもあるだろう。 そもそも『35歳定年説』には、「体力が落ちて、激務についていけなくなる」「記憶力が落ちて、新技術の習得についていけなくなる」などの理由を推す声が多い。しかし言語自体の利便性向上やフレームワークの進化など、過去と比べコードを書く量は減らすことができるようになった。体力勝負ではなく、知力と経験で通説を吹き飛ばせるという声もある。 一部では過去の話であり、また一部では根強く残る、都市伝説のようなものか。 今回、海外で開発者として働き続ける人物に話を伺ってみた。マイクロソフト コーポレーション(以下「 米マイクロソフト 」)で、 Windows Azure Web Sites の開発に携わっている河野
未明の2時間半。一心不乱にコードに集中 ──中島聡流プログラミングの流儀 #OpenGL 2014.01.29 Category:【連載】ギークたちの『仕事の流儀』 Tag:OpenGL ,中島聡 米国マイクロソフト社でWindows95/98、Internet Explorer3.0/4.0 のソフトウェア・アーキテクトを務めたことで知られる、UIEvolution創設者の中島聡氏。 開発者としての日米にまたがる豊富な経験をふまえ、IT業界やそこで働くプログラマたちへ向けて、ブログなどで切れ味のよい提言を続けている。現在も毎朝4時起床してコードを書く現役エンジニアである中島氏に、プログラミングの流儀を聞いた。 by 馬場美由紀 (CodeIQ中の人) 未明に起きて仕事。昼寝は「18分間」と決めている ──現在はアメリカを拠点に活動されていますが、最近の中島さんの関心事は何ですか? いま「
AGILE STRATEGIST | 通りすがりのエバンジェリスト NAGASAWA, Tomoharu 長沢智治のソーシャルサイトへようこそ。ゆっくりしていってね。
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想(転職
_ Agile2011の傾向と対策 Agile2011に行く人向けにAgile2011のセッションのおすすめをまとめてみました。 Agile2011では5日間のあいだに200以上のセッションが行われます。私はそのすべてのセッション概要に目を通して、特に興味をもったセッションをピックアップしてみました。参考になれば幸いです。 ちなみに、私はAgile2011には行きません。これを読んでAgile2011に参加した人は、ぜひ帰国後に報告会をやっていただけると嬉しいです。場所は提供します :) Monday AM The Origins of Agile: Robert Martin Uncle Bob がアジャイル開発に至る壮大な歴史を語ってくれる。Agile2011 のオープニングにふさわしいセッション。 An Introduction to Non-Violent Communicatio
_ 世界を目指せ、ふつーのエンジニアたちよ! -Agile2008にて日本人エンジニアが講演- yattomさんがInfoQにAgile2008日本勢紹介の記事を書いてくれました。 http://www.infoq.com/jp/news/2008/07/agile2008_japan 私も再来週の火曜日に講演することになっています。 _ Agile2011の傾向と対策 Agile2011に行く人向けにAgile2011のセッションのおすすめをまとめてみました。 Agile2011では5日間のあいだに200以上のセッションが行われます。私はそのすべてのセッション概要に目を通して、特に興味をもったセッションをピックアップしてみました。参考になれば幸いです。 ちなみに、私はAgile2011には行きません。これを読んでAgile2011に参加した人は、ぜひ帰国後に報告会をやっていただけると嬉し
「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか? 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け
SEIがCMMIとアジャイルの統合に関するレポートを発表 いいね | 作者: Manoel Pimentel Manoel Pimentel フォローする 0 人のフォロワー , 翻訳者 沼田 暁子 沼田 暁子 フォローする 0 人のフォロワー 投稿日 2008年11月23日. 推定読書時間: 2 分 | 共有 | 後で読む マイリーディングリスト 先日はソフトウェア開発の国際的なシナリオが熱かった。ソフトウェア工学研究所(リンク)(Software Engineering Institute:SEI)は最近、「CMMIかアジャイルか:両者を採用してみては!」と題されたレポート(リンク) を発表した。その中では、CMMIのアイデアやプラクティスとアジャイルのアイデアやプラクティスとの一体化を、ソフトウェア開発プロジェクトで可能な何かとして扱っている。 このドキュメントはDavid Ande
大学紹介(運営の体制と現状) <建学の精神/理念/ポリシー> 建学の精神 教育の理念と方針 大学・大学院の目的 将来構想 アドミッション・ポリシー カリキュラム・ポリシー ディプロマ・ポリシー 学長からのメッセージ 役職者一覧 名誉教授一覧 大学の組織図 教員組織等 <学生数/卒業・修了者数> 学生数(在籍学生数、教員一人当たりの学生数、除籍・退学者数等) 卒業・修了者数(学位授与数) <学則/学位規定/卒業・修了要件> 大阪工業大学学則 大阪工業大学大学院学則 教育課程および履修方法、単位の授与、卒業および学位の授与(学部) 課程修了の要件、学位の授与(大学院) <その他> 設置届出書/設置計画履行状況報告書 高等教育の修学支援制度 沿革 大学歌 校旗 スクールカラー・コミュニケーションマーク・タグライン等 情報の公表 社会貢献活動 動画集(YouTubeへリンク) 評価について 大学機
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法:スクラム提唱者が教える、チームの不幸を減らす方法(1/2 ページ) スクラム提唱者のジェフ・サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。 2011年はアジャイル実践者にとって歴史的な年となった デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。 1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修(Certified Scrum Product Owner 研修、以下CSPO研修)が開催されました。翌日
前回「『現状のソフトウェア開発は間違っていないか?』(プロセス編)」では、ウォーターフォール開発の問題点と改善方法を示した。さて、前回お話ししたようにウォーターフォール開発は本来、いくらプロセス改善をしたとしてもイノベーティブな開発がしにくい。ならば、反復開発(*1)やアジャイル開発に変えてしまおう、といいたいところ。しかし、導入するのであれば、それぞれのプロセスの特徴と弱点をしっかりと知っておくことが必要である。 ウォーターフォール開発からの乗り換えを考えている方々だけではなく、いまアジャイル開発や反復開発を実践している方たちにもぜひ一読してほしい。 (*1)反復開発とは例えばRUP(Rational Unified Process)やUP(Unified Process)のこと。 反復開発とアジャイル開発の違い 反復開発とアジャイル開発は、繰り返し型開発という意味では同じように思われる
牛尾さんがCodeZineに、アジャイル開発の運用のハードルが何故高いのか、優れた記事を立て続けに書かれているのでリンクしておく。 牛尾さんのように、実際のAgileな開発だけでなくシステム化提案や要件定義のAgile化など、下流工程から上流工程まで全てで経験し尽くしている人だからこそ、分かっているような内容ばかりでとても興味深い。 【元ネタ】 ウォーターフォールの次に行け!~日本のソフトウェア開発を今一度洗濯いたし申し候(1/2):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) なぜアジャイルは本のとおりに実践しても失敗するのか?(1/4):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) なぜアジャイルは本のとおりに実践しても失敗するのか?(4/4):企業のIT・経営・ビジネスをつなぐ情報サイト Enterpri
以下の文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳である。 Creative Commons ― 表示-非営利 3.0 Unportedの条件下で、ここに掲載する。 次のアジャイルソフトウェアプロジェクトに使える10の契約 2009/4/29 by peterstev ソフトウェアサービスの顧客であれサプライヤであれ、ソフトウェア開発プロジェクトの最初の頃というのは、口約束だけでいろんな仕事をやらなくちゃいけない。 契約書というのは、言ってしまえば、競技のルールがだらだらと書かれてあるものに過ぎない。 ルールが正しければ、顧客にとってもサプライヤにとっても、成功する確率が高まる。 ルールが間違っていれば、お互いに協力することも難しいし、進捗だって妨げてしまう。 それでは、アジャイルプ
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the it
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く