国内におけるアジャイル開発、どのプラクティスがいちばん使われている？ IPAが調査報告書を公開
国内でアジャイル開発を普及させることを目指し、IPAはアジャイル開発の国内での活用事例をまとめた｢アジャイル型開発におけるプラクティス活用事例調査｣として、調査報告書、およびプラクティス活用のためのリファレンスガイドなどを公開しました。 IPAがこのような調査報告書を公開する背景として、「国際競争力強化のため、世界的に主流になっているソフトウェア開発手法であるアジャイル型開発に日本でも取り組む必要がある。しかし、現状、日本では「普及が遅れており、ようやく認知され始めた」段階であるとされている」と調査報告書に記述されています。 報告書では、国内の26のアジャイル開発事例についてその状況をまとめることでナレッジの集積をはかるとともに、今後の普及に向けた提言を記しています。 日次ミーティング、ふりかえり、イテレーションが国内3大プラクティス 国内でアジャイル開発の普及が阻害されている要因として、
柔軟なウォーターフォールはアジャイルと見分けがつかない - arclamp
2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について ～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。 講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。 資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。 確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはど
企業システムにアジャイルは必要か
2015/6/22にアイ・ラーニング様にて開催された「悩める管理職のためのエンタープライズ・アジャイル導入セミナー」の講演資料です。Read less
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
7つのアジャイルメトリクス
アジャイルコーチとか名乗っていると、開発生産性の定量的なデータを聞かれることがしばしば。今日は日頃計測しているデータの紹介です。元ネタはSWプロジェクトにおけるツールの活用を考える会 第五回勉強会のボーナスステージとして発表させていただいた内容です。 開発の安定度を確認するベロシティ アジャイル開発で有名なベロシティです。ベロシティ＝速度と訳せるのですが、開発チームの速度メーターとして計測しています。 上の図の数値は、イテレーション（私の場合、1週間）での実績日の合計です。作業にどれだけ時間を使ったかで計測しているので、ストーリーポイントではなく実績日を使っています。 「Redmineでアジャイルチームのスピードやパワーを見える化する」でも書かせて頂きましたが、どこまでベロシティを高めるかではなく、安定しているかどうかを意識しています。作業ごとのばらつきもあるでしょうが、上の図をみると、じ
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
スクラムの先へ進む
アジャイル初心者の多くは、スクラムでアジャイルをはじめる。スクラムには明確な指針、ルール、プラクティスがあり、チームにアジャイルを導入するのに役に立つ。ところがスクラムもまた組織の中でさまざまな問題に直面し、多くの会社にとって成功を難しくする一因になっている。スクラムをやってきた人たちは自問する。どうすればよいのだろう？ スクラムだけで十分なのだろうか？ Jimmy Bogard氏は、なぜスクラムをやめたのか、なぜ彼のチームはスクラムで成功した後、そのコアプラクティスをいくつかやめることでパフォーマンスを改善できたのかについて、次のように説明する。 イテレーションはpullベースのアプローチほど効率的ではない。 タイムボックスで仕事をすること、割り当てて空きを埋めることには、何かしら心理的影響があります。明確なタイムボックスのイテレーションをやめて、できる限り早く納品することにのみ注力する
アジャイル開発におけるドキュメンテーションの実際(2) ―― ドキュメントの「必要最低限」の見つけ方
本連載では，アジャイル開発とウォータ・フォール開発の両方を経験している筆者が，アジャイル開発におけるドキュメントの位置づけや作成方法について解説する．今回は，開発において作成するべき「必要最低限のドキュメント」について考える．（編集部） 技術解説・連載「アジャイル開発におけるドキュメンテーションの実際」 バック・ナンバ 第1回 本当に必要ですか？ そのドキュメント 前回は，アジャイル開発におけるドキュメンテーションの考え方として以下の点を説明しました． アジャイル開発では必要最低限のドキュメントを作成する． 必要最低限を決めるために，それぞれのドキュメントについて「いつ」，「誰が」，「何のために」利用するのかをよく考える． Face To Faceがもっとも強力なコミュニケーション手段であり，ドキュメントはそれを支援する目的で用いられることが多い． そうは言っても，「何が必要最低限なのか
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート - 4Gamer.net
［CEDEC 2012］「ドラゴンクエストX」における開発進捗管理法とは？ セッション「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」レポート ライター：大陸新秩序 2012年8月20日から22日にかけて，神奈川県内のパシフィコ横浜にてCEDEC 2012が開催されている。本稿では，開催初日に行われたセッションから「大規模開発のプロジェクト管理 〜ドラゴンクエストXにおけるマネージメント事例〜」の模様をレポートしよう。 「ドラゴンクエストX 目覚めし五つの種族 オンライン」公式サイト スクウェア・エニックス 開発部 ドラゴンクエストＸ デザインセクションマネージャー 荒木竜馬氏 本セッションの講師を務めたのは，スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャー 荒木竜馬氏だ。荒木氏は，「ドラゴンクエスト」シリーズや「FINA
プロダクトバックログにおけるよくある質問と答え | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラム道FullBoostで出ていた質問と議論で若干うずうずするところがあったので、好き勝手に答えてみます。 なお、回答はあくまでコーチとしての勝手な見解であり、全てのコンテキストに有効な絶対解では決してありません。 そもそも自分達のおかれたコンテキストを踏まえた上で、どうやったらもっとうまくいくのかを考え続け改善していけばよいのです。 「パーキンソンの法則」を「ストーリーポイント」で防ぐ事はできるのか？パーキンソンの法則とは、「ある資源に対する需要は、その資源が入手可能な量まで膨張する」という法則で、開発にあてはめれば、確保した時間は、それを使い潰すまでつ使ってしまう、ということになる。 この症状をストーリーポイントによって解消できるか、という質問に対しては、答えはNoだ。 それは以下の理由だ。 ストーリーポイントは単なるポイントであり、なんら
アジャイルの概念を取り入れたCMMI - プログラマの思索
岡本 隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。 ラフなメモ書き。 【元ネタ】 徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント CMMI | CMMI Solutions | Translations | CMMI 日本語翻訳版 上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。 ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。 「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
「7人のアジャイルサムライ」に参加してきました。 #devlove #agilesamurai - ミッションたぶんPossible
4月24日 七人のアジャイルサムライ(東京都) 昨日は、東京：飯田橋のクラスメソッド株式会社で開催されたDevLove主催勉強会「七人のアジャイルサムライ」に参加してきました。 その名の通り、7人で「アジャイルサムライについて語り尽くす」のがこの勉強会の主旨。少人数の座談会形式で、各々持ち寄ったテーマについて、フランクに参加者が意見を出し合いました。 この勉強会、参加者が7名というのが非常にハードルが高くて、「そもそもオレみたいな勉強不足野郎が参加していいんだろうか？」と遠巻きにイベント告知を見ていたのですが、直前で2名辞退し、開催自体が危ぶまれる事態に。こんな面白そうなイベントが中止されるのは勿体ない、だったら力不足でもなんでも参加して開催できるようにしちゃえ！ とばかりに、勢い参加してきた次第です。いやぁ、開催されて本当に良かった。 自己紹介 残念ながら1名は業務多忙で直前辞退。6名で
中規模大規模プロジェクトにアジャイル開発を適用するにはどうすればいい？ IPAが14件の事例を基に報告
中規模、大規模のアジャイル開発において成功に寄与する主な要因は、リーダーシップを発揮するキーマン、教育と経験、段階的な導入、などの内容を含む報告書を、独立行政法人情報処理推進機構（IPA）が公開しました。 報告書のタイトルは「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査 調査概要報告書」で、プロジェクトの実メンバー数が30名から100名程度を中規模、100名以上を大規模と位置づけ、中規模の事例6件、大規模の事例4件、そして中規模大規模のプロジェクトで部分的にアジャイル開発を適用した事例4件を基に書かれました。 プロジェクトの内容はゲームソフト、ソーシャルゲーム、SNS、医療健康関連、ECサイト、基幹システムなどで、自社開発、受託開発ともに含まれています。 公開された概要からポイントを引用します。 非ウォーターフォール型の方が「いきいきしている」 基にした14件の事例。
スクラムを1枚で説明する資料7選
みなさんこんにちは。@ryuzeeです。 スクラムを1枚の絵で説明する資料はいろいろ出回っているので、整理をしてみました。 どれもちょっとずつ内容が異なったりしているので比較してみると面白いです。 是非自分用のものを作ってみると良いのではないでしょうか。 http://www.axosoft.com/ontime/videos/scrum/#scrum-diagramCC-3.0のライセンスで公開されている。ダウンロードは前述のページの下部から可能です。 The War Room - Does your Scrum room have the best Scrum image?Free Intro To Scrum Wallpaperマイク・コーン氏のスクラムの説明資料の中の絵を格好良くしたもの。CC-2.5ライセンス。 SCRUM PosterCC BY-NC-ND 3.0ライセンス.
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
Scrum ではコードレビューをどうやっているか？ - haradakiro's blog
森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
