Enterprise Transformation Solutions | AI-Powered Workflows & Intelligent Operations
Intelligent orchestrationreimaginedYour competitors are transforming. Your customers expect more. Don’t just keep up—transform your enterprise by reshaping your operating model and rewiring your workflows in perfect sync. Reshaping your operating modelRewiring your workflowsYour company needs more than incremental change. Through deep analysis of your unique challenges and goals, decades of real-w
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
QA to AQ: Quality Assurance から Agile Quality へ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 伝統的な品質保証(QA)からアジャイル品質(AQ)へと変わっていこう 2016/9/30、Hillside Group(後述)の代表Joseph Yoderさんが来日され、鷲崎先生と特別セミナーが開催されたとのこと。 そこで紹介された、**「QA to AQ: 品質保証(Quality Assurance)からアジャイル品質(Agile Quality)へ」**というパターンが秀逸で、かつ、日本のアジャイルオーディエンスに興味がある方が多いであろう、と思い、紹介します。 アジャイル開発は徐々に日本の開発現場にも浸透しています。特に、We
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
クオリティエンジニアの役割とは「お客様の視点を提供すること」 ～ セールスフォース・ドットコムの作り方（後編）
クラウド上に構築した企業向けアプリケーションを提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、サービス開発を行っています。 同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方 どのように世界最大規模のアジャイル開発を実現したか」が行ったセッションの内容を紹介します。 （本記事は「大規模アジャイル開発の実態～ セールスフォース・ドットコムの作り方（前編）」の後編です） クオリティエンジニアの役割について 開発においてクオリティエンジニアが果たす役割は結構大きい。スクラムチーム内のコミュニケーションのハブとして積極的に働いている。デベロッパは
タイム・コンサルタントの日誌から : R先生との対話－－アメリカ製造業の教訓
久しぶりに、またR先生を訪ねた。かつては企業経営にタッチし、現在は半ば引退した経営コンサルタントだが、今でも教えられることは多い。 「元気かい。出張に行っていたみたいだが、最近の景気はどうだね？」 －－厳しいですね。半月ほど欧州の地方都市に行っていたんですが、今回の米国発金融危機は、想像していたよりずっと速く影響が出てきてます。我々の業界でも、世界中であちこちのビッグ・プロジェクトが中断ないし立ち往生をはじめました。向こうではしょっちゅう“今回の経済危機の影響はどうだ。日本はどう立ち向かうのか”と聞かれました。聞かれても、これといっためぼしい政策もないし、答えに困るんですが・・。 「そうだな。自動車や消費財業界はもう影響が出始めているが、生産財その他の業種はまださほど危機感がなく、“日本は金融危機の影響が小さいおかげで、円高になって困る”という程度の認識のようだ。まるドメ企業が多いからなあ
「良いデザイン」の工数は見積ることができるか | タイム・コンサルタントの日誌から
目の前に広げられたのは、30数枚に及ぶスケッチの紙だった。我々の顧客が打合せを終えて帰った後で、そのグラフィック・デザイナーの人が見せてくれたのだ。CI（コーポレート・アイデンティティ）の世界では、かなり名前を知られた人である。彼が顧客に見せたのは、3つのデザイン案だけだったはずだ。ダイナミックでポップなもの、端正で清潔なもの、柔らかで明るいものの3つで、ずいぶん違う印象の候補案を用意してくれていたのに感心したばかりだった。でも、その裏側には10倍以上の半製品があったのだ。 その人は、候補の3案に至るまでの案出しとデザイン展開の結果を何枚もめくって見せながら、どのような発想から出発して、どうバリエーションをつくり、それからどう最終成果物に結びつけたのか、素人の私にたいして簡単に説明してくれた。私は完璧に驚いてしまった。ひらめきから生まれるものとばかり思っていたグラフィック・デザインが、じつ
KPTを使ったプロセス改善(2)：An Agile Way：オルタナティブ・ブログ
Issue … Problem の本質化。問題を見つめ、本質的「課題」としたもの。「５回のなぜ」などで到達できるもの。「アンチパターン」や「AntiPractices」では、root causeと呼ばれている。 Knowledge … Keep の結晶化。Keepの中には、ナレッジとして抽象化できるものがある。ナレッジの表現形式としては、「名前付け」がまず必要。そして、それを表現する形式としては、Pattern、新しいPractice、AntiPractice、Tips、FAQ、注意書きとして、壁に貼るなどが考えられる。 これを、KPTIRK（ケプターク）と言う名前でKPTの拡張として、Alistairに提案したところ、「日本人はカイゼン慣れしてるな～」という感想をもらった。 hiro さんのご要望にお答えして、KPTIRKのフォーマット例。まだ決まったものはない。 Keep->Knowl
JPCERT/CCとの「脆弱性情報ハンドリング」の記録 : DSAS開発者の部屋
■ はじめに 「△△製のソフトウェア××に脆弱性が発見された」というニュースが連日のようにネットの上を行き交っています。 このブログの読者にはプログラム開発者の方も多いと思いますが、 自分の携わるソフトウェアの脆弱性を第三者から指摘された経験のある方はどのくらいおられるでしょう？ 先日、筆者は「HttpLogger」というフリーソフトウェアのセキュリティホールを修正しました。 そのきっかけとなったのはJPCERT/CC（有限責任中間法人 JPCERT コーディネーションセンター）様から届いた 一通のメールでした。 それから私は同センターと連携し、10日余りの準備期間を経て修正ずみのモジュールの公開と 旧バージョンにおける脆弱性情報の開示を行いました。 この「脆弱性情報ハンドリング」と呼ばれるプロセスに関わったことは、一般的な知名度とは裏腹に 普段あまり身近な存在ではない「JPCERT/CC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
uTest - The Professional Network for Testers