overlasting.net
overlasting.net 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
ここギコ！: 自分で産んだ全体最適化ソリューションに自分でトドメさした...合掌
Posted by nene2001 at 14:23 / Tag(Edit): 国盗り PSGI Apache / 0 Comments: Post / View / 0 TrackBack / Google Maps 元記事が見つけられないのだけど、昔ライブドアの誰だったかの記事を読んだことがあります。 記憶でその記事に書かれていたことを書くと、ライブドアでは全サービス共通の会員認証とか、そういう部分をライブラリ的に提供してアプリに組み込むのではなく、Apacheモジュールを作ってアプリより上層で処理しているそうです（ライブドアでそういう事実がないなら、すんません、どっか別の会社と間違えたのだと思います。でも、記憶では100%ライブドアなんだけど）。 理由は、アプリの開発は技術者個々人のもっとも使いよい言語（Perl、Ruby、etc...）で作ることを尊重しているの
テンプレートから学ぶ 受注する開発者のためのテスト仕様書
1. はじめに ソフトウェア開発プロジェクトにおいてテストは極めてストレスに満ちています。「テストとは作った成果物に誤りがあるかどうかを見つける作業だ」という本質的に不愉快な活動であることに加えて、プロジェクトの終わりにさしかかって時間も逼迫しているのに仕様変更を受けて再テストなどという、体力的にも精神的にもきつい作業であるからです。 本稿では、さまざまなストレスを受ける立場の開発者が少しでも楽に「きちんとテストしました」と言うために、テスト仕様書のテンプレートを紹介します。このテンプレートは発注者に報告するための文書だけでなく、さまざまなテスト技法の紹介も含まれていて、いつどういうテストをすればよいのかという手引きにもなっています。 さて、はじめに、ソフトウェア開発プロジェクトと品質・生産性・納期の関係を見てみましょう（図1）。 お客様（発注者）はプロジェクトを起案する際、何を作るかを「
テストを書くときはコストベネフィットを考えろ - ひがやすを blog
InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案 でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。 重要なポイントはここだと思います。 Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。 つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コス
第9回■上流工程で文字集合仕様と文字エンコーディングを決定する
これらの対策のうち，ここでは「文字集合の変換を伴う変換をしない」など，アプリケーション全体の文字コードの取り扱いについて上流工程で留意すべき内容について説明しよう。「入力値のチェック」については次回以降，「入力値の検証」の項で詳しく説明する。「アプリケーションでの正しいマルチバイト文字の処理」については，個別の処理内容の項で説明する。 文字コードの取り扱いについて，上流工程で留意すべき点としては，次の三つが挙げられる。 要求仕様として文字集合を定義する端末がサポートする文字集合を確認する実装に用いる文字エンコーディングを決定する まずアプリケーション仕様として，処理対象となる文字集合を規定する必要がある。日英語以外の韓国語や中国語，アラビア語などの対応が必要な場合はUnicodeを選択するしかない。さらに日本語だけの場合でも，例えばJIS X 0201＋JIS X 0208はJIS第2水準
開発と運用の分離
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、システム統括部の駒田です。 昨今、内部統制やJ-SOXといった言葉を良く耳にしますが、 ヤフーもご他聞に漏れず、粛々と対応を進めて参りました。 今回は、その対応の一環として行った、 「開発と運用の分離」に関してのエントリーをさせていただきます。 例えばですが... 開発成果物であるソースコードをテスト終了後に改ざんし、 不正に利益を得る様なエンジニアが存在していた場合、 それはヤフーにとって、一般のお客様に対する裏切りであり、 信用の失墜となってしまいます。 このような事態を回避するため、 当開発部では開発者と運用者とを明確に分離し、 開発者はリリースモジュールに触れる事が出来ない。 運用者はソースコードに触れる事が出
怒濤の二月、６つの新製品と３つのアップデート
マイクロソフトを辞めてからもう９年も過ぎるが、辞めた一番の理由は「会社が大きくなりすぎて思いっきりコードが書けなくなった」こと。私がいた時代ですでに１０００人のエンジニアを抱えたWindowsチームの生産効率は、「エンジニア一人あたり一日1.5行」という悲惨なもの。 プロジェクトが肥大化して人が増えて来ると、それに反比例して生産効率が下がって来るのはどうしても避けられないが、この規模になると常にすし詰め状態の満員電車の中でマラソンをしているしているような気分で、前に進んでいるのかどうかすら分からなくなってくる。 特にWindowsクラスの大きなプロジェクトになると、その複雑さのために開発期間が３年とか５年とかの長期なものになってしまい、途中で何がなんだかわからなくなってしまうケースもしばしばだ（Windows Vistaが良い例）。 逆に今は、増井君がサーバー側・私がiPhone側、という
ウノウラボ Unoh Labs: テスト計画書のテンプレート
こんにちは！やまもと＠テスト番長です。 巷ではインフルエンザが流行っているようですが、皆さんお元気にお過ごしでしょうか。 さて、プロジェクトが立ち上がったとき、（特に受託案件の場合） テストのドキュメントはどうしようか？という話が出ると思います。 適当にやる訳にも行かないけれどIEEE829をベースにしたものだと重かったり、割と迷う部分です。 英語ですがテスト計画のテンプレートを配布しているサイトがあったので、ご紹介してみます。 Pragmatic Software http://www.pragmaticsw.com/ Software Development Templates http://www.PragmaticSW.com/Templates.asp テスト計画書 Test Design - http://www.pragmaticsw.com/Template_Te
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
正しいバージョン管理でさらにイケてる.NET開発（1/3） - ＠IT
■1. はじめに 前回の記事では、オープンソースでのバージョン管理の一例として、Subversion／TortoiseSVN／AnkhSVNの紹介と簡単な利用方法について説明した*1。 *1 前回の記事が執筆～公開されている間に、Subversionの最新バージョン1.5.0が公開されている。これからSubversionを試す方は、下記の最新バージョン（2008年7月23日時点）で試してみるとよいだろう。 ・Subversion 1.5.0 ・TortoiseSVN 1.5.0 ・AnkhSVN 2.0.4757 バージョン管理を利用せずに開発することに懲りた中村君、玉田君は、その後社内でSubversionを導入することを推し進め、社内の開発標準フレームワークの開発・運用を任されるまでに成長していた。 中村君「ほんとSubversionって便利だよな。いま思うとバージョン管理なしでどうや
標準工期より30％以上短いとデスマーチの危険、JUAS指摘 ― ＠IT
日本情報システム・ユーザー協会（JUAS）は6月26日、システム開発の現状についてユーザー企業に尋ねる「ソフトウェアメトリックス調査2008」の結果を発表した。93社の341プロジェクトについてアンケート調査を行って、「標準の開発工期は投入人月の立方根の2.4倍である」などの指標を示した。JUASの専務理事 細川泰秀氏は「この世界は計数管理を持ち込まないとうまくいかない」と話し、開発の現場でこれらの指標が使われることに期待を示した。 調査結果は昨年度の調査（注1）と似通っている。調査したプロジェクトから導き出した全体工数と全体工期の関係も同じで、「標準の開発工期は投入人月の立方根の2.4倍」とした。つまり、1000人月のプロジェクトの場合では、24カ月の工期を設定するのが標準的ということになる。新規データを加えながら、昨年度調査と同じ結果が出ていることから、この係数の信頼が高まったともいえ
eXtreme Gadget (エクストリーム ガジェット) ポケットに入るアジャイルな究極の小道具: オブラブ2008夏「XPブートキャンプ」で学んだこと
イベント・セミナー集客プラットフォーム 「こくちーずプロ」を使えば、驚くほど簡単で安全なイベント告知・集客ができます。誰でも使えるシンプルさ、とことんまでイベント集客の手助けができる拡張性、大規模なイベントの大量な申し込みも安心して受付ができる高機能を併せ持っています。 一般的なイベントだけでなく講演会や、定期的に開催する地域セミナー、クローズドな社内勉強会、大規模な学会など様々なイベント形態にあわせた募集が可能です。 サービスのトップへ セミナー会場検索サービス 「こくちーずスペース」は、イベント・セミナーの開催に適したセミナー会場（貸し会議室・ホール）を所有する全国2,700箇所以上の公共施設を掲載！リーズナブル・格安で安心して利用できる貸し会議室やレンタルスペースを中心にイベントの規模や設備など目的にあった施設を簡単に検索できます。 今まで見つけにくかった公共施設の詳細な情報をまとめ
UIオートメーションによる自動UIテストの実践 ― ＠IT
特集：UIオートメーションによる自動UIテストの実践 WindowsアプリのUIテストを自動化しよう クロノス 亀野 弘嗣 2008/06/03 読者の方々は、UI（ユーザー・インターフェイス）にかかわるテスト（以下UIテスト）を自動化できているだろうか？ UIテストを自動化しようとしても、UIテストのコードは記述しにくく、記述方法に一貫性がない、などの理由から、自動化をあきらめる場合が多いのではないだろうか。 .NETの開発においても単体テストの自動化は一般的に行われるようになってきているものの、UIテストの自動化はそういった理由で実現が難しく、あまり行われていないのが現状だ。 そこで本稿では、標準的で一貫性のある記述ができるMicrosoft UIオートメーション（以下UIオートメーション。詳細後述）と、テスト・ツールであるNUnitを使用して、UIテストを自動化する方法を紹介する（N
「バッファ込み」の工数がスケジュール遅延の原因
開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。 こんにちは。アクセンチュア・テクノロジー・ソリューションズ（ATS）の新楽です。 最初に立てたスケジュールどおりにプロジェクトが進行せず、だんだんと遅れていく……。そんな経験はありませんか？ 今回は、すでに稼働しているシステムへの機能（サブシステム）追加開発プロジェクトでの経験を基に、プロジェクトのスケジュール管理の難しさについてお話しします。 初めてのプロジェクト憲章 このプロジェクトの規模は約100人／月で、与えられた期間は約6カ月。正直、スケジュールはタイトでした。もっとも新規開発ではなく、すでに稼働しているシステムの追加開発ですので、アーキテクチャもアプリケーションも本番環境で稼働していました。まったくの新規開発プロジェクトと比較すると、スケ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
納期に縛られて小さくまとまってしまう自分: ある nakagami の日記
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
使っていないロジック: ある nakagami の日記
サイボウズ株式会社
