2017/09/22 DevLOVE関西~大きなSIerの中で「アジャイル開発で飯を食う」までの歩み
アジャイル・クラウド・DevOpsとエンジニアの採用と評価についてRyuzeeさんに聞いてみた(14,000文字インタビュー!) はじめに 2月某日、Ryuzee.com の Ryuzee さんこと吉羽龍太郎さんに、アジャイル・クラウド・DevOps についてのお話を伺う機会がありました。本エントリーは、その時の様子を文章化したものです。 アジャイル・クラウド・DevOps は実際のところどんなものなのか? 上手くいく/上手くいかない取り組みの違いはどこなのか? そもそもそれは本当にやるべきか? 組織とエンジニアの関係、評価はどのようにすれば良いのか? といった幅広いテーマについて語っていただきました。 このインタビュー記事は、 アジャイル・クラウド・DevOps などをやりたいけど、どこから手を付けていいのかわからない方 手を付けたけど、なんだか上手くいっていないことにお悩みの方 もしく
5. Scrum lives ... 5 https://www.scrum.org/About/Origins By 2006, we had 30,000 CSMs. By early 2009, there were more than 60,000 CSMs. 6. ... and gets dying 6 https://www.scrum.org/About/Origins (2009年8月に辞任勧告) in August 2009 when the Scrum Alliance board of directors unanimously asked for my resignation (自分で作った組織に追い出される)
@yusuke_kokuboさんが分かりやすい記事を書かれていたのでメモ。 【元ネタ】 Issue Tracking Systemの利用パターン - こくぼ@Everything is the experience. 【1】RedmineやTracのようなITSは高機能でとても柔軟なため、いろんな状況で使い道がある。 チケット駆動開発の発端はTracのチケット管理であり、テスト工程のタスク管理をToDoリスト代わりに使う発想から生まれた。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 更に僕は、Redmineにチケット駆動開発を適用したらアジャイル開発が自然に運用できた経験をした。 そして、IT業界に限らず、営業・製造業・製薬業・情報システム部門などの色んな立場の人達がタスク管理だけでなく課題管理や要件管理
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム(BTS)や課題管理システム(ITS)を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
いま再びキてる「アジャイル」開発 世界で広がりつつあるアジャイル 2001年の「アジャイルソフトウェア開発宣言」から10年が経過しました。アジャイルマニフェスト登場当時の熱狂的な雰囲気は一時期停滞気味でしたが、最近再びアジャイル開発が広がりを見せています。 その理由の中心は、ITの進歩や世界のボーダレス化とともに、ビジネスの変化のスピードが早くなり、競争が激化したため、一刻も早く顧客に新しい価値(ソフトウェア)を届ける必要性が増したため、アジャイルに開発する必要が出てきたためでしょう。 欧米はもちろん、日本でもアジャイルに対する注目は増していて、先日開催されたDevelopers Summit 2012のデブサミ2012アワードでも、角谷信太郎氏の講演『アジャイルマニフェスト ディケイド』が1位を取り、来場者数も過去最高を記録するなど高い注目を浴びています。 群雄割拠 アジャイルプロジェク
前回はiPhoneアプリ「AnkiBlank」をご紹介した後、アプリを開発し続けながらサーバ側も開発し続ける上での課題を挙げ、その解決策として適切なツールを使っていく必要があるということを説明しました。今回はコミュニケーションツールとして使用したyouRoomとPivotalTrackerについて、より詳細にご説明してまいります。 youRoomとは youRoom(http://youroom.in/)はグループでの情報共有と共同作業を支援するツールです。ソニックガーデンではyouRoomの開発/運用を行う傍ら、youRoomをフル活用して様々なプロジェクトを推進しています。 youRoomをコミュニケーションの要としている理由として、以下が挙げられます。 チャットと違い、非同期であること コメントが構造化されること タスク管理と統合されていること ここからは、それぞれの理由について説明
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 (今は Android 版 もあります) HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
こんなエントリを書いて早4ヶ月。 なんでアジャイルに取り組みたいか - kaji_3's blog BtoBで対価を頂いてアジャイル開発として遂行した案件が先日終わったのでKPT形式でふりかえります。 前提 期間一ヶ月半 Scrumを参考にしてプロジェクト運用 イベント用WEBアプリケーション 案件の内容をぼかして書いているので、一部整合性の合わない記述があるかも知れませんがご了承ください。 Keep 高い顧客満足度 プロダクトオーナーから「自分たちの意志が反映できた物を作ることができた」とコメントを頂きました。フィードバックから実際のものができるまでのスプリントという考えについても好評でした。顧客の社風として良い物を最後まで模索するという考えがあるとのことで、仕様凍結後の変化は、仕様変更として好まれないウォーターフォールには不満があったとのことでした。 育つシステム 当初想定されていたシ
2012年7月18日(水)に行われたAgile Conference Tokyo 2012に登壇してきました。 30分という短い時間(予定通りの長さで延長したわけではありません!)の中で駆け足でAgile開発から継続的デリバリー、継続的フィードバックやALMへの流れ、なぜテスト自動化が求められるのかといった話と、それに絡めたツール導入の方向性の話をしたつもりです。(もうちょっと笑いを誘える流れにしたかったのですが固くてスイマセン) 当日の参加者の方の多くがAgile開発未経験ということで、Agileに関して銀の弾丸を期待していたり色眼鏡で見られていたりする方もいるかもしれませんが、Agileな開発のやり方や各種ツールは目的達成のための道具でしかありません。 全てのプロジェクトをAgileでやるべきだとも思わないし、Agileでやったからといってうまくいくかの保証もない。ツールも同じで高いお
ということでタイトルの通りなんですが、本日2月8日発売の日経Linux3月号の特集1「クラウド活用で“簡単” “タダ” “楽しく” サーバー構築の新常識」の一部を執筆しました。 僕が書いたのは、Amazon EC2 API Toolsを使ってコマンドラインからEC2インスタンスを立ち上げて、そのインスタンスに対してChef Soloを使ってさくっとApacheやPHPやMySQLをインストールしよう、という内容です。 応用編としてEC2のインスタンス上にTracとSubversionをコマンド一発で作るChefのレシピなんかも用意しました。 日経 Linux (リナックス) 2012年 03月号 [雑誌] 出版社:日経BP社( 2012-02-08 ) 定価:¥ 1,533 雑誌 ( 172 ページ ) ISBN-10 : ISBN-13 : 4910071930327 環境構築の自動化を
最近、大手ベンダーのアジャイル開発への取り組みがニュースになっています。アジャイル開発がいよいよ普及期に入ってきたという印象を受けました。それと共に、それがこれまでのアジャイルコミュニティの言っていたアジャイルと同じものなのか、あるいは別のものなのか、とても気になるところです。それはそれで大切ですが、ここでは、なぜ大手ベンダーがアジャイル開発に取り組もうとしているかを考えてみたいと思います。 従来の開発法 いわゆるウォーターフォール開発では、あらかじめ要件となる仕様を確定して、そのシステムの実現を請け負う方法です。「不確実コーン」(リンク先はAct as Professional)で考えていただければわかりますが、これはリスクの高い方法です。 リスクの高い場合には、保険のビジネスが成り立ちます。大きな問題の起きる可能性のある場合には、個別のリスクを抱える顧客に対して平均的なリスク(発生確率
ちょうど、先日アマゾンのオープンハウスというイベントでお話をさせていただく機会があったのですが、開発者向けの20日のセクションだけで90名近くの方々にご参加いただきました。平日にもかかわらず、多数の方々にご参加いただき、どうもありがとうございました。 私自身は、昨年秋にSIerからアマゾンに転職してまだ半年ですが、この機会にアマゾンにおけるソフトウェア開発の文化や考え方について、ブログでご紹介できる範囲でまとめてみたいと思います。 私は、ずっとブログに書いてきたようにSI業界からの転職だったのですが、一般的なSIerにおけるソフトウェア開発の考え方や手法といろいろな面で違っているということは予想していたというか、もともと覚悟の上での転職でした。それでもやはり最初のうちはあまりにも大きな変化に自分の仕事のスタイルを合わせるのにいろいろと苦労しました。基本的には転職したての頃に抱いた感想(転職
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) (顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く