組織パターンを用いたScrumの微調整 - @m_seki の
組織パターン (Object Oriented SELECTION) 作者: James O. Coplien,Neil B.Harrison,ジェームス・コプリエン,ニール・ハリソン,和智右桂出版社/メーカー: 翔泳社発売日: 2013/08/06メディア: 大型本この商品を含むブログ (15件) を見る 2013-10-30、コプリエンの研修にレポータ枠として参加しました。がんばってレポートします。 本来は組織パターン (Object Oriented SELECTION)を読んだ人、組織パターンやScrumの好きな人、そしてコプリエンファンの人が参加する研修だと思いますが、どれにも該当しないままでの参加となりました。 会場入り 9:45。6Fにつくと喫煙所に角谷さん(id:kakutani)を発見。朝からついてる感じです。会場に入ると裸足のコプリエンと三人の通訳、TAの皆さんが準備し
ゲーム開発プロジェクトマネジメント講座(SQUARE ENIX OPEN CONFERENCE)
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
アジャイルが語る。価値あるソフトウエアを届けるために必要な12の価値観 - 基本へ帰ろう
私は日頃から「価値あるソフトウェアを提供したい」「開発スピードを向上したい」「顧客も開発者も幸せな環境を作りたい」、そう思いながら開発を行なっています。それらを達成するために必要だと感じているのが、”顧客とプロジェクトメンバー全員”で「価値観（大切だと思うこと）を共有して納得すること」だと思っています。極端な話ですが、もし顧客が「予算も仕様も開発期間も開発メンバーも固定だ。遅れたら土日祝日を使って取り戻せ。残業代はもちろん支払わないぞ。そしてソフトウェアが役に立たなかったら買い取ってもらうからな。フハハハハ！」という価値観をもった顧客と契約（約束）できるでしょうか？価値観というのはとても大切なのです。 私はアジャイルについて、以前から興味を持っています。例えば下記のエントリーがその現れです。 RubyKaigi2010で「本当のアジャイル」を学んだ - 基本へ帰ろう アジャイルな見積りと計
「FindBugs」「Jenkins」をサポートし、不具合検出の幅が大きく広がった静的解析ツール「Coverity Static Analysis 5.5」
2011年10月4日、コベリティは、C/C++やJava、C#のソースコード解析ツールの新バージョン「Coverity Static Analysis 5.5」を発表しました。発見が難しく、誤動作の原因となるバグを効率よく検出できる同ツールの新バージョンでは、前バージョンに比べてコード解析速度が向上し、より広範囲な開発環境に対応できるよう強化が施されました。Coverity Static Analysisの特長や新機能から、ソースコード静的解析のメリットについて考えてみましょう。 テストケースの用意は不要。ビルド時に不具合を発見 「Coverity Static Analysis」は、C/C++やJava、C#の各言語で記述されたソースコードに含まれるバグを検出できるソフトウェア開発支援ツールです。大規模・複雑化するソフトウェア開発において、ソースコードの不具合は、出荷遅延や修正対応による
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほど、
組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
ストーリーベースのアジャイル開発に。Railsのプロジェクト管理·Fulcrum MOONGIFT
Fulcrumはストーリーベースのアジャイル開発にマッチしたプロジェクト管理システム。 FulcrumはRuby on Rails製のオープンソース・ソフトウェア。アジャイル開発において用いられるユーザストーリー。利点としては機能をユーザ視点で捉えることで、実装されるべき機能が明確になりイテレーションが終わった段階できちんとできているか確認がしやすいことだ。 4つの枠が特徴 そのため通常のタスク管理に比べると大ざっぱに見えてしまい、逆に細かな進捗が見づらくなってしまう場合もあるようだ。そんな状態を解決するには、最適なプロジェクト管理を導入することにあるだろう。今回紹介するのはFulcrumだ。 Fulcrumはストーリーベースのタスク管理を実現する、アジャイル開発向けのプロジェクト管理だ。完了したストーリー、作業上、バックログ、Chilly Bin（終わらなかったタスクを放り込んでおく場所
アジャイルアーキテクチャの相互作用
図 1. アジャイルのアーキテクチャに関する作業のハイブリッドなフレームワーク。プロジェクトにアーキテクトを巻き込むことは、プロジェクトの目的を達成する手助けとなります。テーブル1では、さらに相互作用ポイント(緑)、重要な技術(金)、アーキテクチャ機能(紫)というフレームワークの要素を説明しています。 テーブル 1 は、図1の要素を簡単に説明しています。このリストは網羅的ではありませんが、アーキテクチャ機能は、アーキテクトが通常プロジェクトで実行するものです。 テーブル 2は、交差している点においてアーキテクトの主な関心や相互作用点とアーキテクチャ機能がどのように交わるのかを示します。まとめて言うと、3つのカテゴリと4つの項目によって、他の優先順位や選択肢に基づいてカテゴリや項目を追加することで、アジャイルアーキテクチャを拡張できることを理解し、指導するのに役立つフレームワークが作り出され
アジャイル契約
原文(投稿日：2011/02/08)へのリンク アジャイル手法に関してよく質問されることのひとつに，"アジャイル開発の契約はどのようにすればよいのか"，というものがあります。 従来のウォーターフォールモデル手法，すなわち要件を定義し，サプライヤが (自身の要求解釈とコスト見積に基づいて) 価格を提示して，両者が法的拘束力を伴う契約書にサインする，というやり方は，企業が何かを購入する場合にはとても都合のよいものです。 サインが完了すれば，次は開発期間です。開発のスコープ内に実際にあるものは何か，何が範囲外なのか，契約変更を要するものは何か，などについて全員で議論します。そうこうしているうちに開発作業が完了します。白熱した議論を繰り返した後，顧客がソフトウェアを正式に受け入れれば支払いが行われます。そして顧客は 200kg のソフトウェアを，サプライヤはお金を手にいれて，全員が – あるいはほ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発とTDDを半年間実践してみた顛末と、これから
@tarosite
アジャイル開発はなぜ難しい？--アジャイル開発を実案件に生かすための基礎知識（2） - ZDNet Japan
Y.M | 株式会社ラグザイア
2000人のアジャイル実践者が集うカンファレンス～Agile 2011 Conference
スクラムプロジェクトの中長期の見積もりとは？
効率的なアジャイルミーティング
アジャイルのまずい考え方
スクラムで気難しい人たちの抵抗に対処する
アジャイル/スクラムの振り返り - ヒントと秘訣
