An interview with Uncle Bob onAn interview with Uncle Bob on "Clean Agile" with the two Japanese translators Masanori Kado and Shintaro Kakutani. Hosted by Kenji Hiranabe. ※日本語字幕ONで視聴できます。
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
グーグルはあれほど多くのソフトウェアのテストをどのように行っているのか？
グーグルは検索エンジンだけではなく、メールソフトのGmail、オフィス系ソフトのGoogle Apps、WebブラウザのChromeやOSのAndroidなど、さまざまな種類と規模のソフトウェアを開発しています。 それらはどのようにテストされ品質管理されているのでしょうか？ グーグルのブログGoogle Testing Blogに、Test Engineering DirectorのJames A Whittaker氏による「How Google Tests Software」がポストされ、その概要を伝えています。 3つのチームからなるEngineering Productivity Whittaker氏はまず、グーグルにはテストの専門部隊はいないのだ、という組織構造の説明から始めます。 There isn't an actual testing organization at Googl
開発者にやさしい環境
ikeike443と申します。このブログの言いだしっぺです。 シャノンに転職してきてちょうど1年になります。前職は業務パッケージソフトの会社に所属していました。 転職してきた経緯などについては、下記のインタビュー記事で話したので、よかったら読んでください。 SaaSの可能性を信じて、新たな道を踏み出したエンジニアの「視点」 で、今回はとりあえず、シャノンに入社してこれは”いいね”と思ったポイントをつらつらと挙げてみます！ アジャイル開発やってるよ 開発方法論としてはアジャイル開発手法の一つ、Scrumを採用しています。 約一ヶ月をひとつのスプリントとみなして、毎月頭にスプリントの計画と見積りをして開発／テストに入ります。 毎朝のミーティングでバーンダウンチャートを確認し、文字通りみんなでスクラムを組んで開発しています。 バーンダウンチャートの作成、プロダクトバックログの管理には、ヌーラボさ
2010-09-16 - m_pixyの読書日記
XP祭り2010で、TOC-CCPMのセッションに参加して、レポーターになったので当日のセッションの簡単なまとめと感想を。当日のスライドは以下のところに公開されてます。 http://www.slideshare.net/changeworlds/lets-start-tocccpm-today まず、個々のタスクが80%の確率で終わるようにしてスケジュールを引いているのにプロジェクトが遅れる理由として以下の3つがあげられていました。 パーキンソンの法則 学生症候群 遅れの伝播 パーキンソンの法則とは、与えられたスケジュールを使いきってしまうというもので、これが起こる理由の一つとして、「いったん早く終わったと報告してしまうと、次からの仕事の期限が厳しくなってしまう」という恐れがあるからだと言われていました。学生症候群は余裕時間があればあるほど仕事の着手を遅らせてしまうことで、いわゆる「夏休
The Nokia Test - masayang's diary
The Nokia Testを手抜き邦訳。 携帯電話機メーカーのNokiaではScrumを使っているよ。Nokiaでは、開発チームがちゃんとScrumを使っているのか、それとも「カウボーイAgile」と呼ばれる代物を使っているのか、はたまた「Agilefall*1」を使っているのか確認する方法「Nokia Test」を開発したんだ。 Nokia Testは二行程あるよ。 まずは、反復型開発をしているかどうかを確認しよう。 各反復周期は4週間以内に設定されているか？ 各反復周期の最終段階で、実装したフィーチャをテストし、動作確認しているか？ 各反復周期の始めに仕様確定をしているか？ カンファレンスに参加している「自称」Scrumチームの人達に上記質問をしてみると、意外と「いいえ」と答えてくる。カンファレンスで同席した人の中の誰も「はい」と答えないことすらあるね。 次に、Scrumしているかど
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
Hh
汽車に乗ったら窓から外をよく見よ。田や畑に何が植えられているか、育ちがよいか悪いか、村の家が大きいか小さいか、瓦屋根か茅葺きか、そういうところをよく見よ。駅へ着いたら人の乗りおりに注意せよ。そしてどういう服装をしているかに気をつけよ。また駅の荷置場にどういう荷が置かれているかをよく見よ。そういうことでその土地が富んでいるか貧しいか、よく働くところかどうでないところかよくわかる。 村でも町でも新しく訪ねていったところは必らず高いところへ登って見よ。そして方角を知り、目立つものを見よ。峠の上で村を見おろすようなことがあったら、お宮の森やお寺や目につくものをまず見、家のあり方や田畑のあり方を見、周囲の山々を見ておけ。そして山の上で目をひいたものがあったら、そこへは必らず行って見ることだ。高い所でよく見ておいたら道にまようことはほとんでない。 金があったら、その土地の名物や料理はたべておくのがよい
情報処理推進機構：ソフトウェアエンジニアリング：非ウォーターフォール型開発に関する調査結果公開
SECは、短サイクルで設計からシステム稼動までを"機敏"に繰り返し、ニーズへ迅速へ対応するといわれる非ウォーターフォール型開発について、事例を含む適用分野や規模などの調査を行いました。あわせて、有識者に参画していただいて研究会を実施し、現状・動向の把握と課題の整理を行いました。その資料を公開します。 ・非ウォーターフォール型開発に関する調査 調査報告書 ・非ウォーターフォール型開発に関する調査 研究会報告書 ・非ウォーターフォール型開発に関する調査 エグゼクティブサマリー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Subway Map to Agile Practices | Agile Alliance
野中先生＠アジャイルジャパン