アメリカの大学で受けたソフトウェア工学の授業が実践的ですごかった話 - stefafafan の fa は3つです
私はアメリカの大学で「インタラクティブメディアとゲーム開発」を専攻しましたが、その時受けたSoftware Engineeringという授業が色んな意味で素晴らしかったのでその授業がどう素晴らしかったのかを紹介していきます。 リアリティーがすごい まずこの授業、生徒数が80人ほどいます。ここから教授がみんなを約15人ずつの5つの会社に分けていきます。そうです、我々生徒は実は会社員なのです。 そして初日に出された課題は「自分たちの会社のミッションステートメントを考えてくること」です。 それだけでなく、プロジェクトマネージャー・プロセスエンジニア・リリースエンジニア・ドキュメンテーションマネージャー・クオリティーマネージャーの役割を会社のどの社員が取るのかを決めてこないといけないというのです。私たちは言われるがままにミッションステートメントを用意し、次の授業に備えました。 プロセスがすごい S
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
4社の合同技術勉強会で発表してきました - (ﾟ∀ﾟ)o彡 sasata299's blog
2014年02月20日15:51 勉強会 4社の合同技術勉強会で発表してきました 昨日、【 ヒカ☆ラボ 】 ITベンチャーを支えるテクノロジー 今、話題の4社が合同技術勉強会を開催！！ 〜ChatWork、ブラケット、Lang-8、ランサーズ〜 で発表する機会をいただいたので、Lang-8について発表してきました。 他の会社の開発環境など、いろんな話が聞けてとても参考になりました〜。利用している外部サービスはどこもだいたい同じですねぇ。 資料はこちら。 最近、直接話すことが大事だな〜と感じていたり、Team Geakを読んでいたりするので（いまさらですがすごく面白い！）その辺の影響を強く受けている感じですw Team Geek ―Googleのギークたちはいかにしてチームを作るのか [単行本（ソフトカバー）]Brian W. Fitzpatrickオライリージャパン2013-07-20
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（開発スキーム編）～ソフトウェア品質シンポジウム 2013
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（開発スキーム編）～ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。 本記事は「組織編」「開発スキーム編」「マインド編」の3部構成です。いまお読みのページは「開発スキーム編」です。 品質優先、納期優先、コスト優先など5つのスキームを用意 次は開発スキームについての話です。 プロジェクトを推進するときにはQCDについて、バランスとプライオリティで判断するの
システム開発プロジェクトはなぜ“カオス化”するのか
システム開発の多くは“カオス化”します。ぼくも年を取ったもので、システム開発でいろいろな死屍累々（ししるいるい）の修羅場を見てきた気がします。数年もかかったプロジェクトがいきなり中止になっても、もう驚かないようになりました。例えばこんなダメプロジェクト、皆さんも身に覚えはないでしょうか。 マジで10人に1人しか稼働してない 「働きアリの法則」によると、多くの労働環境では、20％のアリが働いて、80％はまじめに働きません。しかし、ひどいソフトウェア開発の現場ではもっとひどくて、だいたい10人に1人のプログラマーがバーサーカーのように働いて、それでなんとか持っているという状況も多いです。残りの人は、仕事をしてなかったり余計にバグをまき散らすだけだったりします。 RPGのパーティーに例えると、こんな感じですね。 「Lv99-せんし Lv1-あそびにん Lv1-あそびにん Lv1-あそびにん Lv
開発をより良くしたい人が読んでおくべき10冊
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんな本を読んだら良いですか」と聞かれたりします。 何のために本を読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどの本が役にたつかは分からないですが、以下にあげた本は個人的に強くオススメできる本です。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、本を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」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氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し
かくたにのWiki - 『アジャイルプラクティス』サポートページ
誤字脱字・疑問点があれば、 shintaro at kakutani dot com までメールにてご連絡ください。 第2刷で修正されたバグ p.27 「ソフトウェアという職業は、〜〜」 → 「ソフトウェア開発者という職業は、〜〜」 p.112 [訳注]（プラス記号をトル）+Sandcastle -> Sandcastle 第3刷で修正されたバグ P.32 これは作業だけに限った話はない → これは作業だけに限った話ではない P.37 持ち込んでしまない → 持ち込んでしまわない P.69 重要な要件に対するの認識が P.126 何らかの値も返すことも → 何らかの値を返すことも P.136 しかしそれだけはない → しかしそれだけではない p.138 そう頻繁にあることでもないはずだだ。 P.142 問題の原因は、このどちらのグループに含まれているはずだ。問題を発見できなければ、分割した
書評 - システム開発 火事場プロジェクトの法則 : 404 Blog Not Found
2007年12月04日14:30 カテゴリ書評/画評/品評Art 書評 - システム開発 火事場プロジェクトの法則 技術評論社傅氏より献本御礼。「ブログ限界論」ではお世話になりました。 火事場プロジェクトの法則 山崎敏 デスマーチに関わる者必読の一冊。 これからデスマーチに加わろうというものも、その辛さを知る者も、その中で痛みさえ麻痺してしまったものも、そして誰よりも職場の同僚や部下を意図しようがしまいがデスマーチに送り出してしまうマネージャーも。 本書「システム開発 火事場プロジェクトの法則」の副題は、「どうすればデスマーチをなくせるか?」。二部構成の本著では、まずデスマーチを防ぐための手法が紹介される。出版一年後の今なら「ライフガードハック」とでも言おうか。そして二部では、これまでの著者のデスマーチ体験が語られる。 本書は、いわば戦争体験者による戦争の防ぎ方なのだ。 目次 - 書籍案内
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア品質の神話に関する実証的研究
Joel on Software
【Game Developers Conference 2009現地レポート】6年かかった「Fable」の続編がわずか3年で完成した理由－GAME Watch