「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
一括請負という契約形態のままアジャイル化するのは危ない - すこしふしぎ
何年か前に、顧客（と元請けの営業）だけがアジャイルに盛り上がった結果盛大に火を噴いて関係者が闇に消えた開発に関わったことがある。立場上そのままは書けないし、適宜フェイクも混ぜていくが、バッドノウハウの一例として紹介するとともに、ウォーターフォールからの脱却という意味でのアジャイルについて書いておきたい。 前提 契約はSI型一括請負、全外注。且つ、アジャイル。 闇アジャイル化の経緯 営業がアジャイルを売り込みたかったという背景があり、「だいたいこれぐらい」で契約が成立（仕様がないのに見積もりだけはあった） その時点で、元請け企業の偉い人たちがこの案件を切り捨てた（応援要請も突っぱねるよう根回しがあった）（まあしかし偉い人はさすがである、経営的な観点では正しい） 全外注は予想されうる責任回避のための手段として決定された（選択権もなかった） 顧客は仕様を決めなくてもなんとかなるのがアジャイルだと
受託開発にアジャイルは適用できるか？
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
＠ITイベントカレンダー
平素よりイベントカレンダー＋ログをご利用いただき、誠にありがとうございます。 イベントカレンダー＋ログは「IT・製造業・ビジネス関係のイベント（セミナー・展示会・勉強会・コンテスト・Webイベントなど）を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー＋ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年6月30日（火）15:00をもちましてイベントカレンダー＋ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
【CyberAgent】技術情報／TechReport - テックレポート／SCRUMによる実践的アジャイル開発手法 | 株式会社サイバーエージェント
概要 現状、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、一定規模の開発をする場合、何かしらの開発手法を採用した方が良いのは自明である。担当プロジェクトにおいて近年注目されているSCRUMを適用して開発を行ったが、導入時に戸惑うことや疑問に思うことがあった。本稿では、実際にプロジェクトでSCRUMの手法を適用した際の具体的な方法、手順、独自の工夫などについて整理する。SCRUM開発を導入する際の一つのやり方として参考にしていただきたい。 目次 序論 社内ではデカグラフ戦略に伴い、新規プロジェクトが大量に立ち上がっている状況である。現状では、適用する開発手法に関しては、各プロジェクトに任されているため、特定の開発手法を採用していないプロジェクトも多い。しかしながら、新規開発などで、一定規模の開発をする場合、何かし
ウォーターフォールとアジャイルにおけるマインドセット | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 Allan Shalloway氏のMindsets: Waterfall, 1st & 2nd Generation Agileがとても素晴らしい記事だったので、ご本人の承諾を得て一部日本語訳で紹介します。 なお、氏がかかれたこちらの記事(拙訳)を先に読むと理解が深まると思います。 以下の表は、ウォーターフォールとAgile（第一世代、第二世代に分けた。）におけるマインドセットを表にしたものである。誤解されないようにしてほしいのは、どのマインドセットが正しいとか正しくないとかいうことは無いということである。 我々はもっと仕事をうまくやるために、マインドセットを自由に持ち、変化していくことが必要かもしれない。 ただし自分自身を変化させることは難しいし、ましてや他人を変化させることはもっと難しい。 第1世代アジャイルと第2世代アジャイルの類似点
アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう？ "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか？」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵（たぶんどこかにある４象限の図）がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
RSpec の入門とその一歩先へ - t-wada の日記（旧）
和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 東京 Ruby 会議 03 の RSpec ワークショップの資料です。このワークショップでは参加者の方に「写経」(コードを書き写すこと)をして貰い、TDD/BDD と RSpec を同時に学べるように都度説明を入れるかたちで行いました。 第2イテレーションも書きました。続きに興味ある方はご覧下さい (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 1st iteration favotter の みたいな NG ワードのフィルタリング機能を RSpec で作りましょう。まずは NG ワードの検出機能を作成します。 このイテレーションでは最初ベタな形のテストコードと実装を書き、だんだんとそのコードを洗練させてゆきま
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
アジャイルへの道 第一章 チーム開発の苦悩と模索編
チーム開発の苦悩と模索 クレイでは、ずっと開発方法や情報共有をいろいろと模索してきました。 以前ブログで紹介した Basecamp や Backpack の紹介も、その一つです。 小さなチームを加速させる！ Basecampで簡単プロジェクト管理 Backpackでタスク管理から情報共有まで 最近、弊社ではチーム開発というものが、うまく機能するようになってきています。 @irohiroki を筆頭に全員でアジャイル開発を進めてきていることが確実に実になってきていると思います。 少しでも参考になればと思い、今までの苦悩と模索を「アジャイルへの道 第一章」として綴りたいと思います。ちなみに第十三章まではありませんし、第二章以降は @irohiroki に任せたいと思います。 1年前までの開発 基本的に受託での開発が多いため、次のようなフローになっていました。 1年前までの開発フロー 打合せの内
強いリーダーを求めるよりもチームビルディングを志向する先に成功がある - FutureInsight.info
この前、NHKスペシャルの「リーダー論」という番組を見ていたら強いリーダーが必要という論調の意見が特に50代の管理職に多く見られた。ただ、最近いろいろと本を読みながら、この強いリーダーという概念にすごく違和感を覚えるようになった。というのも、最近たまたまなのだが、チームビルディングについての本をいろいろ読む機会があったが、なんとなく強いリーダーを求める先に日本での成功はないのではないかと思うからだ。 世界最高のイノベーションファームIDEOのチームビルディング方法 まずは以下はIDEOでチームを結成するときに人材をどのように分類し配置するかについてのノウハウが記載された本。イノベーションの達人!―発想する会社をつくる10の人材 トム ケリー ジョナサン リットマン Tom Kelley 早川書房 2006-06 売り上げランキング : 109660 Amazonで詳しく見る by G-To
ペア・プログラミング：An Agile Way：オルタナティブ・ブログ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
「アジャイルサムライ」読書会 | Lab by engineering@dwango.jp
今回の記事はちょっと趣向を変えて、「アジャイルサムライ」という本と、ドワンゴが取り組んでいるアジャイル開発手法についてご紹介します。 「アジャイルサムライ」とは 今年7月にオーム社から訳書が刊行された「アジャイルサムライ――達人開発者への道」という本のことです。 開発現場でアジャイル開発を実践するための現実的な手法や取り組みについて、軽妙な文体と親しみやすいイラストで語られています。 「エクストリーム・プログラミング入門」や「アジャイルプラクティス」、「アート・オブ・アジャイル デベロップメント」といった名著が「アジャイル開発の教科書」であるならば、本書は現場で実践するための「アジャイル開発のマニュアル」というべき位置づけの本です。 監訳を担当したのは、日本におけるアジャイル開発の第一人者である角谷信太郎氏と西村直人氏。弊社のエンジニアであるレオがレビューに参加しています。 「アジャイルサ
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 － Publickey
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化（Semantic Diffusion）が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」について。 土木や建築に由来するのが「計画駆動開
開発者用Webチャットシステム『AsakusaSatellite』をリリースしました - みずぴー日記
最近、[twitter:@suer]、[twitter:@mallowlabs]、[twitter:@shimomura1004]と夜な夜なSkypeでチャットしながらソフトウェア開発をしてるんですが、だんだんとSkypeチャットの機能に対する不満が溜ってきました。 というわけで、SkypeチャットをリプレースすべくWebチャットシステムを作ってみました。 開発者にとってハッピーな機能満載なので、是非使ってみてください。 →公開サイト Skypeの不満点 全文検索ができないので、過去の発言を探すのが面倒 コードがハイライトされない #42と書いてもRedmineのチケットにリンクしてくれない← AsakusaSatelliteの特徴1: 普通につかえる 最近のChromeはけっこう凄くて リアルタイムな発言更新 デスクトップ通知 D&Dによるファイルアップロード が平気でできてしまいます。
グラス片手にアジャイル開発 第4回 － ハイブリッドアジャイルの実践法
エンタープライズ分野へのアジャイルの適用 ここ2、3年のアジャイル開発の再評価は第2のブームとも呼ばれています。実際のところは10年前にブームであったものがじわじわと現場に浸透し、それが表面化して見えてきたと言うところでしょう。こうした中、エンタープライズ（企業）系のアプリケーション開発でもアジャイルを適用するケースが多くなってきました。Web上のちょっとしたツールやアプリの開発でアジャイルの成果を実感し、今度は本格的な基幹業務システムの構築でも適用してみようという機運が高まってきたのです。 業務システムへのアジャイル適用の3つの課題 「業務システムにもアジャイルを適用」という目標を掲げた場合、3つの課題が浮かび上がります。1つは契約の問題です。連載第1回目に述べたようにアジャイルは「変更があって当たり前」というスタンスなので、いつまでもお客様が変更を要求してきたらコストが膨れ上がるのでは
グラス片手にアジャイル開発 第3回 － アジャイル開発における計画と運営サイクル
ソフトウェア開発において、重要かつ難しい作業の1つが「計画」です。アジャイル開発では、計画を立てずに実装を始めるイメージがあるかもしれませんが、実際には計画を立ててから実装します。ただし、“すべてを事前に予測はできない”という前提で、継続的に計画を立てていくことが肝要です。本稿では、アジャイル開発における計画と運営サイクルに焦点を当てて解説します。 アジャイルにおけるプランニング アジャイル開発を導入すると、一般的にプロジェクトの初期品質は良くなりますし、要求の充足率も高くなります。何より開発者のモチベーションの向上にもつながります。しかし、プロジェクトを上手く運営できないときもあります。 プロジェクトが上手くいっている場合もそうでない場合も、開発者は各関係者に計画と進捗を説明する責任があります。実際のプロジェクトには、開発のみでなく計画／構想のフェーズ、UIデザインの外注、翻訳、性能テス
グラス片手にアジャイル開発 第2回 － アジャイルの主な実践手法とその取捨選択
第1回ではアジャイル開発の理念や位置付け、特徴について紹介しました。アジャイル開発にはより良いソフトウェアを低コストで、かつ高品質に開発できる大きなポテンシャルが秘められていると感じたことでしょう。今回は、アジャイル開発の代表的な手法「XP」と「スクラム」の特徴を紹介し、これらの手法を実際の開発現場にどのように適用していくのかを示します。 アジャイル開発の代表的手法 アジャイル開発には、さまざまな手法があります。 XP スクラム 動的システム開発手法（DSDM：Dynamic Systems Development Method） クリスタル 機能駆動型開発（FDD：Feature Driven Development） アジャイルユニファイドプロセス（AUP：Agile Unified Process） リーンソフトウェア開発 このように数え上げればきりがないほどですが、この中で人気を二
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Togetter - 「Agile Conference tokyo 2010 #agiletokyo」
グラス片手にアジャイル開発 第4回 － ハイブリッドアジャイルの実践法