アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いってほんと？
はじめに 今朝、こんな記事を読みました。 ソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗率が268％も高いという調査結果が発表されたという内容でしたが、にわかには信じがたい内容だったので研究結果の考察をしてみました。 違和感の正体 まず記事に目を通し、この記事の主張は下記だと読み取りました。 高品質のソフトウェアを予定通りに納品するためにImpact Engineeringの哲学を学ぶべきだ こちらを読んで私は、3点の違和感を感じました。 本当にソフトウェアの開発手法としてアジャイルを採用したプロジェクトはアジャイル以外の手法を採用したプロジェクトに比べて失敗確率が高いのか？ 予定通りに納品するという成功の定義はアジャイルにも当てはめて良いのか？ そもそもアジャイルは価値観だが、Impact Engineeringは全く
テスト技法「同値分割」を信頼していいのかわからなくなった - 若くない何かの悩み
これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力
1年半で283回のアップデートを実施 大規模P2Pネットワーク「Winny」のバージョンアップ史
映画『Winny』の公開に伴い、記憶から消えかけている20年前の諸々の思い出話をする「Winnyとは何だったのか v2.0b7.1」。ここでAki@めもおきば氏が登壇。続いて、Winnyのバージョンアップ内容について話します。 Winnyの最初のリリースとバージョンアップ ここまでWinnyの全体像の仕組みをお話ししました。後半は、Winnyというソフトウェア開発がどういうふうに進められていたかを、バージョンアップの内容からおさらいをしていこうと思います。 Winnyの開発期間は2002年5月から2003年11月の1年半だけだったのですが、その間に283回もバージョンアップしてるんですね。そういったところを、ダイジェストというかたちでササッといこうと思います。 2002年4月1日に、いわゆる最初の書き込みと開発宣言があります。いわゆる47氏と呼ばれてますが、最初の書き込みでFreenetの
コードレビューコメントは純粋な質問でも詰問してるように聞こえたり嫌味を言ってるように聞こえたりするのでテキストコミュニケーションは難しい
Junichi Ito (伊藤淳一) @jnchito 「なぜここで1を加算してるんでしょうか？」 とか、 「シャドーイングってご存じですか？」 みたいなコードレビューコメントって、純粋な質問であっても受け取り方によっては詰問してるように聞こえたり、嫌味を言ってるように聞こえたりするので、テキストコミュニケーションって難しい。 2021-08-04 09:56:39 Junichi Ito (伊藤淳一) @jnchito コードレビューにおいて疑問文が詰問に聞こえちゃうパターンなので「純粋に質問」を冒頭に付けてみた。 「なんでtrueにしたんですか？」が「普通はやらないでしょ！💢」に聞こえてしまう日本語の難しさよ……。 pic.twitter.com/3hDi6sV6FP twitter.com/jnchito/status… 2023-02-13 11:14:48
【考察】テストコードのきれいな書き方 - Qiita
作ったものが想定した動作をしているか。 それを確認するために、テスト（試験）を行います。 検証したいことがちゃんと実現できて確認が取れているのであれば、その品質自体は割と気にされないことが多い印象です。 保守・運用・追加開発 をしていくプロジェクトが多くあると思います。 その作業の中で、改善を取り入れていくこともあると思いますが、その中でも一番後回しにされるのが、テストコードの改善のように思います。 推測ですが、「コストによるメリット・リターンが少なすぎる」ことが理由かな…と（開発者目線ではリターンが大きいのですが、運用者目線ですとリターンが少なく見えてしまう）。 であれば、最初からある程度綺麗なものがどういうものかを考え、作成しておけば良いのではないか・・！ ということで、考察していきたいと思います。 前提 考察をするにあたり、言語化した時の表現や意味のズレが発生しやすい部分もあると思い
自動テストはなぜあまり書かれてこなかったのか 和田卓人×倉見洋輔×古川陽介がひもとく、フロントエンドテストの歴史
セッションテーマはフロントエンド開発テストの「必要性」と「歴史」 古川陽介氏（以下、古川）：さて、次のパネルディスカッションは、「フロントエンド開発テスト最前線」というタイトルで発表していこうかなと思います。 ご登壇いただくのは、タワーズ・クエスト株式会社取締役社長の和田卓人さんです。和田卓人さんはリクルートの技術開発の技術顧問をやっています。 また、株式会社リクルート兼株式会社ニジボックスの倉見洋輔さんもお呼びして、今回は話をしていこうかなと思います。倉見さんに関して言うと、どちらも私の直属のメンバーというかたちで、一緒に働いています。 今、プロダクト開発において、やはりテストというのが開発の生産性などを決める上でもかなり重要な要素になっているかなと思っています。この必要性や歴史を3人で話していけるといいなと思っています。 テスト駆動開発の第一人者・和田卓人氏 古川：じゃあ、もう始めてい
「バグをたくさん見つける人の頭の中」を言語化してみた - Qiita
バグ発見にはセンスがあるらしい？ 「よくそのバグ見つけたね！」 と言われる人が周囲にいませんか？ 実は私も言われます ただ、「なんで見つけられるの？と言われても...」と思うくらい無自覚だったりします そんな自分を知るためにも今回は、バグを見つけるセンスの言語化に取り組んでみようと思います 注意書き 大前提、体系化も裏付けもできておりません 本来の品質保証やテスティングは、センスでバグを見つける活動ではないとも考えています よくバグを見つける人の頭はこうなっているのかもな、という一例としてお読みください また、この記事では用語の解説は行いません 気になる言葉があればぜひ調べてみてください！ では、「バグをたくさん見つける人の頭の中」を解体していきましょう！ 分類1: 視点を広げる ✅ 無数のユーザーになりきってみる ユーザー面: 中高生だったら？ビジネスマンだったら？高齢者だったら？日本語
公取委、システムエンジニアの取引実態調査スタート 「買いたたきなど下請け法上の問題がある」
公正取引委員会は1月17日、フリーランス・企業所属システムエンジニアを対象とした実態調査を始めた。Webアンケートで、ソフトウェア制作業務や受託システム開発の取引状況を探る。回答期間は2月13日まで。 サーバ、ネットワーク、データベース、セキュリティなど各種エンジニアや、ITコンサルタント、データサイエンティスト、Webデザイナーなどが対象。「就業状況と収入」「雇用主・取引先との関係性」「取引先が下請法を順守しているか」などを調べる項目を全41問用意した。 公正取引委員会は実態調査の背景について「ソフトウェア制作業や受託システム開発業の市場規模が拡大し続ける一方、多重下請構造による買いたたきや仕様変更への無償対応など下請法上の問題がある」と説明。調査結果は広く周知し、IT業界の取引の適正化を図るとしている。 関連記事 楽天に独禁法違反の疑い 送料無料化しない加盟店に不利益ちらつかせ 公取委
LibreOfficeだけにある10の素晴らしい機能 - LibreOffice日本語チームBlog
こちらの年表をご覧になるとわかるように、LibreOfficeはOpenOffice.org（通称 OpenOffice）の後継プロジェクトです – クリックすると拡大します: 私たちは半年ごとに新しいメジャーバージョンをリリースしています – それではコミュニティと認定開発者が追加した数々の素晴らしい機能を見ていきましょう！ 1. 相互運用性の改善 – .docx形式のエクスポート ワープロであるLibreOffice Writerは、Microsoft Officeで使われている .docx形式で文書をエクスポートできます。そのほかにも様々な相互運用性の改善が加えられています。（訳注：もちろん.docx形式だけでなく.xlsxや.pptxのエクスポートも可能ですし、再現性もOpenOffice.orgより段違いに向上しています。） 2. ノートブックバーUIを搭載 LibreOffic
Redmineが日本人好みのツールであるという仮説 - プログラマの思索
第10回東京Redmine勉強会のグループディスカッションでも話題になったのが、Redmineの運用が大規模化していく上での課題だ。 @Will_meaningさんとのやり取りがとても参考になったのでメモ。 以下は私的感想。 【参考】 Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ Redmineを運用している規模について - Google グループ 第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」 #redmineT - Togetterまとめ 【1】@Will_meaningさんが持つ問題意識は「なぜ海外ではJIRAが多く普及していて、日本ではRedmineが多く浸透しているのか」。 彼の意見を読むと、「SVN中心の開発プロセスはRedmine、Git中心の開発プロセスはJiraやGitHub
The Seasar Foundation Project Site
利用者向け情報 ニュース & Wiki プロダクト一覧 メーリングリスト Eclipseプラグイン Mavenリポジトリ ライセンス 各種リソース イベントサイト ファウンデーションサイト 開発者向け情報 SeasarWiki ソースコードリポジトリ 課題追跡 継続的ビルド 開発者ログイン サーバチームサイト Java プロジェクト S2Container.Java Seasar2 (S2Container) Presentation.Java Cubby Mayaa mobylet S2BlazeDS S2Flex S2JSF S2OpenAMF S2Portlet S2Struts SAStruts Teeda Ymir Persistence.Java DBFlute Doma Kuina S2Dao S2Hibernate S2JDBC S2OpenJPA S2TopLink Co
【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか？
ソースコード読解力は個人差が大きい コードレビューなどで、他の人のソースコードを読んだり理解したりする速度が気になることはありませんか？ また、読む速度や理解する速度がとても速い人がいると感じたり、自分が周りの人よりも速いと思ったりすることがあるのではないでしょうか。私たちの研究グループで実施した観察でもソースコードを読む速度は個人差が大きいことを確認しており、同じソースコードを理解するための時間に6倍の差がある事例を確認しています。 では、自分自身のソースコードを読む速度や理解する速度が、平均と比べて速いのか遅いのかを知るためにはどうしたらよいでしょうか？ 最も簡単な方法は、社内などの身の周りの人とコードレビュー時間を比べてみることでしょう。他にも、参加者全員でソースコードを読むような社外勉強会に参加する方法もありそうです。 文献からは大まかな速度を知ることができる 書籍、標準、論文の情
プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう
デスマーチのコスト - 神様なんて信じない僕らのために
デスマーチのコストのツケを支払っているのは一体誰だろう？ ということで経験談から。 前の会社の問題点列挙。 どう見積もっても１年かかるものが８ヶ月程度で受注される。 プログラマを４人用意すると言いながらその額で受注しつつ、なぜか開始から４ヶ月近く１人しかいない。 最初に纏められるはずの顧客要求は不確かなまま進む。 開発をしながら会議をするなかで徐々に顧客要求が移り変わっていく。 仕様書がないので当初から大幅な仕様の変更に耐えうる設計と実装をせざるを得ない。 プロジェクト後半で火消しにとプログラマが投下されるが例によって役に立たない。 忙しい筈のところになぜか人材が他のプロジェクトに駆り出される。 遅延は客に隠され続けるが、ある場所で突然「間に合わない」という話をせざるを得ない。 納期は必ず延び結果として１年（当初の見積もり）ほどかかる。 品質は最低限動作を満たしているものの当然よくない。
不倒城: SI業界からネットゲーム業界に移った知人に色々話を聞いてきた。
ちょっと技術的な話になる。 私の知人に、かつてはアルファベット三文字の某有名SI会社に在籍していて、今はどういう訳か某ネットゲームの会社に勤めている変り種がいる。 彼はネットワークとDBの専門家である。ゲーム業界には元来DB周りに詳しい人があまり多くなかったらしく、しかしネットゲームの開発にはDBやネットワークのアーキテクチャに関する知識が必須で、要は引き抜かれたらしいのだが、当人それ程ゲーム好きでもないのに面白いルートに行くなーと思っていた。 機会があったら金融業界とネットゲーム業界のシステム周りの違いについて聞いてみたいなーと思ってたんだが、この前久々に会ったら色んな話が聞けた。特定されない程度においおい書いてみよう。ぼかして書く為、ところどころいー加減だが勘弁して頂きたい。 今日はサーバとかデータのやり取りとか、技術的な話。 まず、前提。オンラインシステムの肝の一つに、「誰がデータを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Apache OpenOffice」が“より大きなアップデート”のための貢献を呼び掛け／「OpenOffice 4.1」の初回リリースから6年、いまだ「OpenOffice 4.2」を出荷できない状態