12. よくある状況 品質の良さ 目標の品質 品質の確定性 実際の品質 テストフェーズ開始 目標の品質が共有できていないことも多い。結果論 として、不具合が多く出れば品質が低いということになる。
SIでアジャイルをやるとハイブリッドアジャイルやWater Scrum Fallになります。しかし以下の4点は解決はしません。SIのビジネスモデルでアジャイルが無理なのではなく、「期間と機能を固定して受注する」と変えられない点です。 営業中は、システム担当者は動くシステムを見れない*1。営業マンは見たことないシステムを想像しながら見積もるという高度なヒアリング技術が必要なまま。 開発会社とシステム担当者間で落とす機能を合意しても、「偉い」ユーザーの一声で落とした機能が復活する。多層構造*2による意思決定の遅さは残ったまま。 予算の見積もりは超過方向にしかブレない*3。(予算)見積もりのバッファ問題は残ったまま。 チームメンバによってベロシティ(開発速度)が2〜3倍は変わる。しかし単価はそれほど(40万〜80万)変わらない。 アジャイルといっても現時点でのSIのビジネス面へのインパクトは「少
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3,4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
『アジャイルソフトウェア開発』という言葉を聞いたことがありますか?アジャイルソフトウェア開発とは、製品全体を一度に設計/実装するのではなく、期間毎に完成させる機能を選択して設計/実装し、それを顧客に公開してフィードバックを得ることで、製品の完成度を高めていく開発スタイルです。 KRAYでは現在プロジェクトのアジャイル化を進めています。そこで今回はKRAYのアジャイルソフトウェア開発について紹介します。 なぜアジャイル? まず、なぜKRAYがアジャイル化を進めているかについてです。冒頭にも書いた通り、アジャイルなプロジェクトでは、設計/実装/デモンストレーション/フィードバックを反復することで製品の価値を高めていきます。これにより、我々は顧客に対して次ような価値を提供することができます。 決められた期間と予算の中で製品の価値を最大にする。 定期的に実際の動作するソフトウェアを見せられる。 プ
「わかりやすいアジャイル開発の教科書」を献本して頂き、じっくり読んでみた。 アジャイル開発を実践する時に最初に参考にするガイドブックとして使えるのではないかと思う。 感想を箇条書きでラフなメモ書き。 【1】アジャイル開発が目指すものは何なのか、というWhyを説明してくれている。 アジャイル開発そのものを自己目的化しないためにも必要。 【2】ソフトウェアの価値とは何なのか? この部分は、日本のIT業界が遅れている所だと思う。 理由は、受託開発案件が多いために、プロジェクトを納期までにとにかくCloseさせることに精一杯であり、納品したソフトウェアやシステムが顧客に役立っているのか、という観点まで頭が回らないから。 普通は、1次開発で赤字を出しながらも何とか本番稼動させて、2次開発や運用保守で、顧客の業務と実システムの不一致や、業務の改革まで目を向けるようになる場合が多いように思う。 本来は、
アジャイル開発においてもソフトウェアを作り始める以上、仕様を決める必要があります。いわゆる要件定義です。ただし、全く新しいものを作る場合と、古いものを新しく置き換える場合とで、やり方を変える必要があります。 新しいものを作る場合 ビジネスモデルはあるものの、それを実現するソフトウェア像はまだはっきりしない・・・新しいものを作る場合には、当然よくあるケースです。 ウォーターフォールとカウボーイスタイル この場合、「全部決めないと開発できませんよ!」というのが一般的ウォーターフォール開発であり、「とりあえず作りながら考えましょうか!」というのがカウボーイスタイルのアジャイル開発です。前者は冷静に考えて不可能(最初から決められたら誰も苦労しない)ですし、後者は手戻りすぎて永遠にローンチできません。 リーンスタートアップスタイル 新しいものを作り始める場合は、リーンスタートアップのスタイルを採用す
たまには便乗してみるよ。 Agile界のすごい人=スーパーエンジニアと呼ぶのかは疑問もあるけど。とりあえず対象は日本語のつぶやきをする人です。他にも沢山すごい方はいらっしゃるので流量が多めの方を恣意的に選択してます。(○○さんがいない、といって怒らないでください) 平鍋健児さん (@hiranabe) いわずと知れた第一人者。みんな本を読んでるはず 角谷信太郎さん(@kakutani) RubyとXP。アジャイルな見積もりと計画づくりやアジャイルプラクティス 和田卓人さん(@t_wada) TDD。プログラマが知るべき97のこと 倉貫義人さん(@kuranuki) XP。YouRoom等のサービスを社内ベンチャーで開発 林栄一さん(@essence_s) NLPやファシリテーションを使ったAgile導入。すくすくスクラム名づけ親 西村直人さん(@nawoto) アジャイルコーチ。スクラム道
アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。 【元ネタ】 Twitter / z200: スクラムを例に取ると、リリース(および検収)と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。 【続報】ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ 販売管理~売上の計上時期(売上計上基準) 【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。 作って納品しておしまい
XP祭り関西2013 - 日本XPユーザーグループ関西 | Doorkeeper http://xn--cck1b7gr48j.net/blog/2013/04/27/xpfes2013/ 2013/04/26に行われた、XP祭り関西に参加してきました。あたりまえだけど、XP祭り関西2012から一年経ったんですねー。 XP祭り関西2012で話したこと - 日々常々 月日が流れるのは早いものだ(しみじみ 箇条書きでメモったのをだらっと貼っとくます。 アジャイルの夢を現実に! - プラクティス・プラクティス - さかばさん あれもこれも一度にしない 優先順位を付けてやるのがアジャイル プラクティスの導入もそれでやろう パレートの法則(大きな問題は全体の2割) 小さな労力で大きな効果を生む プラクティス プラクティスが目的ではない よりよくするために…… *信頼貯金* 成功するところを見極めて改
これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人
いまさらながら『アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法』を読んだ。まだ、感想はとても書けない。ただただ、もっと早く読むべきだった。アジャイルなんて向こう側の別世界だと遠巻きにしていたし今でもそんな感じを持っているが、それでも、もっと早く読むべきだった。 『Succeeding with Agile: Software Development Using Scrum』は、まだ新しいし、翻訳が出るかもしれない。 『User Stories Applied: For Agile Software Development』は、もう古いので、たぶん翻訳は出ないだろう。この本の紹介サイトにサンプルがあったので、まず、イントロダクションだけ読んだ。 イントロダクション 私は1990年代の半ばのほとんどの期間を後ろめたさを感じて過ごしていました。毎年のように新しい会社を買収
リーンスタートアップは、このブログでも何度も取り上げた本で、僕らの会社が製品開発をする上で非常に参考にしている本です。 リーン・スタートアップ 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二出版社/メーカー: 日経BP社発売日: 2012/04/12メディア: 単行本購入: 24人 クリック: 360回この商品を含むブログ (95件) を見る この本を精読するのは2度目ですが、サービスを実際に手がけるようになってから読んだので改めて考えさせられるポイントが多くて、立ち止まってサービスへの展開や次のアイデアなどに思いが散って、2回目の方が1回目よりも先に進まない状態でした。 リーンスタートアップの中核は以下の「フィードバックループ」というものです。 ■「構築―計測―学習」のフィードバックループ リーン・スタートアップは具体的には、「構築―計測―学習」のフィードバックル
今日は「アジャイルサムライ」という本を読みました。 簡単に内容を説明するとソフトウェア開発の手法である「アジャイル開発」を説明したもの。 ここでアジャイル開発を全部説明してしまうと本の意味がないので、アジャイルサムライの中で自分なりによいと思ったところを抽出します。 ちなみにビジュアルはこんな感じ アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本(ソフトカバー)購入: 35人 クリック: 1,820回この商品を含むブログ (206件) を見る ソフトウェア開発における3つの真実 アジャイル開発は基本的にはきっちりと要件を決めることはありません。しかしウォーターフォールモデルなんかは最初にきっかり要件を決めて開発に進みます。ただ全ての開発に
最近アジャイル開発に関するブログを数多く見るので便乗して考察してみます。 アジャイルがダメだと思う7つの理由 - arclamp ことの発端はこちらのブログ。 ここから様々な人が論争を繰り広げられています。 (エントリーは3/21 確実に乗り遅れていますが…笑) アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog こちらの人がまず最初に反論のようなブログを書いたみたいです。 というわけで自分の意見なのですが、 結論からいうと 「WEBサービス・アプリケーションにはアジャイル開発が向いていると思う!!」 っていうのが自分の意見 というわけでその理由をいくつかに分けて書いていこうと思います。 そもそもアジャイルとは? アジャイル参考書 理想のアジャイル開発 まとめ こんな感じで書いていきます。 そもそもアジャイルとは? 元々は agility -敏捷性・機敏
先日スモールスタートについて書いてから、アジャイルといえばこれ!とおすすめされたアジャイルサムライを読みました。 もちろん実際にスクラム等でプロジェクトを回したことはないので、僕の妄想が多分に含まれます。 その感想文と僕なりの考察をつらつらと書こうと思います。 アジャイルって結局なんですか? アジャイルサムライ読んで一つだけ分かったのはアジャイルは「思想」であるということ。 決して方法論ではないです。その思想を具現化する方法はいろいろあってエクストリームプログラミングやらスクラムやらだったりするわけです。 だから多分方法論の押し付けは絶対やっちゃだめで、方法自体を常に改善していかなきゃいけないのだろうなと思いました。 アジャイルってgitと似てるよね! これはぼーっと考えててふと思ったことなんですが、アジャイルの思想の「細かい単位(ストーリー)」を積み重ねていく、というスタイルは「コミット
開発現場の智慧を体得しよう。 3月19日、IPAより「アジャイル型開発におけるプラクティス活用リファレンスガイド」が公開されました。 本書では、日本各地の開発現場からのヒアリングを通じ得られた知見を、パターン記述形式でまとめています。 内容は、55のプラクティス、25の事例、9つの活用ポイントで構成されており、224ページに及ぶ大部となっています。 このリファレンスガイドには、いくつもの現場の経験と工夫が集っています。 さて、ガイドとは、ただ読んで終えるためのものではなく、各自の実践を助けるためのものです。 本書の制作を終えて、我々は考えました。この大部となったガイドを公開しただけでは、プラクティスの活用は拡がりにくいのではないか、と。 そこで、このガイドを紹介するとともに、現場でどのように活用するかについて皆で考える時間を設けたいと考えました。 このリファレンスがどのようなもので、どのよ
本企画はWeb開発企業『クレイ』におけるアジャイルソフトウェア開発の経験を漫画「ブラックジャックによろしく」の名シーンを挿絵に紹介するドキュメンタリーです。 はじめまして、認定スクラムマスターの吉岡と申します。私は2011年にWeb開発企業『クレイ』に入社して以来、開発プロセスの改善に取り組んできました。クレイはエンジニア5人とプロジェクトマネージャ2人でWeb開発を請け負っており、プロジェクトの規模としては2~3カ月で完了する短いものが主流でした。 入社当時はエンジニアそれぞれのToDo管理はしていたものの、要件の解釈で行き違いがあったり、担当者以外に開発の状況が見えないなどの問題がありました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く