組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
効果的なデイリースクラムのやり方に関するTips10個
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） ミーティングの前にタスクのステータスと残り時間を更新すること。これによってチームがどんな状況にあるかに関する最新のスナップショットを持っていることを保証する。ミーティング中に、ボードの更新に時間を使うべきではない 前回のミーティングから変わった点についてしゃべれるように準備しておくこと。チームにとって価値がある共有すべき情報は何なのか？について考えること。すなわちあなたが完了したことについて事細かにしゃべる必要はないということだ。他の人が聞く必要のある情報か、あなたがチームの助けを必要としている情報についてだけで良い 事実を提供することに集中することで話す内容を制限し、会話を簡潔に保ちなさい。ポイントは全員から聞くことだ。
なぜWIPの制限が重要なのか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 WIPの制限についてExplaining why Limiting WIP is so importantにて良い説明があったのでご紹介します。 ※図は上記サイトより引用 1. WIP(仕掛り中)の同時許容個数を減らす個人的には1開発者が同時に着手するタスク数は1〜2個であるべきと思っています。 したがって、WIPが「2 * チーム人数」より多いのは実質的に制限がなされていないことになってしまい効果が出ないかもしれません。 現実的に何個にするのかは仕事の内容やチームの人数に依存するので、運用しながら順次見直していけば良いでしょう。 ただし安易に数値を増やすことは慎むべきです。 2.
アジャイルサムライ 達人開発者への道 - idesaku blog
アジャイルサムライ−達人開発者への道− Jonathan Rasmusson 西村 直人 オーム社 2011-07-16 売り上げランキング : 230 Amazonで詳しく見る by G-Tools アジャイルを知るためにまず読むべき本は何か？この問いへの答えとして本書以上に相応しいものはないだろう。アジャイルの基本、実践的手法、そして奥義…知るべき全ての情報がそこにあり、それでいて堅苦しくなくて面白い！ オーム社様より献本していただきました。ありがとうございます。 ちょうどいい 本書はSamuraiなどという尖った名前から得られるイメージに反して、"ちょうどいい"本である。 さて、アジャイルっていうのを何となく知っていて、ちょっくら試してみたいなぁ、と思っている人がいるとする。または、次の現場がそういう取り組みをしているから、予習しておきたいなぁ、という人がいるとする。そうした、いくら
守破離/何が偉大なスクラムマスターを作るのか
みなさんこんにちは。@ryuzeeです。 ジェフ・サザーランド博士のブログ記事、Shu Ha Ri - What Makes a Great ScrumMaster?のご紹介です。 元記事に対応して、以下の部分はCC BY-NC-SAライセンスとします。 守破離のコンセプトは日本の合気道という武術から来たものだ。 私はデンバー(センセイは破の段階だった)とケンブリッジ(センセイは離の段階だった)で合気道の道場に数年通った。 生徒はまずは「守」からはじめて、センセイの指示に正確に従わなければならない。 黒帯を取ると、彼(彼女)は「破」の段階にたどり着いたことになり、素晴らしい型の練習をしたり、よりよくするために洞察して適用することが可能になる。 「離」の段階はちょっと違う。センセイが手を動かすと相手は触られてもいないのに宙を舞ったりする。もちろん「気」の力の使い手を見たことがなければ、こんな
スクラムの概要を1分で理解できるイラスト【2018版】
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 アジャイル開発のコーチングやトレーニングでスクラムの全体像を1枚の絵を使って説明することが多いのですが、以前作成したものを最新化したので公開します。 スクラムの本質的な価値やスクラム以外でも日々のプロセスに組み込んだほうが良いこと（テスト自動化や継続的インテグレーション）は含めていません。 あくまでスクラムの概要のみを書いています。 PDF版はこちらにおいておきます。 ※改変なしで引用元併記の上であれば自由に使っていただいて結構です。著作権自体は私に留保します。 内容の誤りや足りない事などがありましたらTwitterなどでお知らせください。 自分のスライドに入れて使うためのパワーポイ
より良いユーザーストーリーを書くための10個のヒント
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 Roman Pichler氏によるユーザーストーリーの書き方の資料が分かりやすいので紹介します。 https://www.romanpichler.com/wp-content/uploads/2013/06/WritingGreatUserStories.pdf より良いユーザーストーリーを書くための10個のヒントシステムの利用者に焦点をあてるストーリーの記述ではユーザーロールを意識するユーザーストーリーをもとに議論するユーザーストーリーはチームとステークホルダー間の議論を活性化させるための道具ユーザーストーリーは仕様ではなく、機能に関する議論のエッセンスであるユーザーストーリーを
プレス発表 俊敏かつ柔軟なシステム開発を可能にするアジャイル型開発を推進するための活動成果を公開：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：藤江 一正）ソフトウェア・エンジニアリング・センター（以下、SEC）は、アジャイル型開発の適用領域や適用方法を整理するための活動を行い、アジャイル型開発に適したモデル契約書案2種を含む「非ウォーターフォール型開発WG（*1）活動報告書」（以下、報告書）を公開しました。 URL： http://www.ipa.go.jp/sec/reports/20110407.html 現在、日本におけるソフトウェア開発の殆どは、ウォーターフォール型と呼ばれる手法です。この開発手法は、初期にシステムに対する要件を正確に決め、前工程を誤りなく完了させ次に進むことが求められます。しかし現実的には、要件の間違いが後で判明することや、開発着手までに要件を確定できない場合もあり、これらに起因するシステムトラブルや開発の遅れが生じています。 このように、初期段階で顧客ニー
Fearless Change 第一章の非公式翻訳 - kawaguti’s diary
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
テスト自動化に関するスライドの紹介
みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、
初リーダーでのアジャイル開発
（1）今回の事例: 企業向けクラウド・サービスのポータル・サイト構築 第2回の「情報共有」では、筆者がアジャイルな開発の基本をどうやって身に付けたのかを解説しました。第3回の「改善」では、筆者がより実践的な内容をどのように学んでいったのかを解説しました。 今回のテーマは「反復」です。筆者が反復について経験を積んだ背景には、筆者自身の立場の変化があります。筆者は、プロジェクトのリーダーとして、これまでの学びを基に、プロジェクトを「反復」して育てていったのです。 これまでの筆者は、アジャイル経験が豊かな上司、先輩、そして、社外のチーム・メンバーとともに、アジャイルな開発を実践してきました。今回は、リーダーとして、チームに対して率先してアジャイルを展開する立場になったのです。 今回は、過去の2回の事例とは異なり、プロジェクト全体の流れを、開始当初から収束するまでにわたって解説します。これまでの2
社外常駐で学んだアジャイル開発
（1）今回の事例: 業務システムをWeb化で刷新 第2回では、新人のころに筆者がかかわった事例を取り上げ、「情報共有」の仕方と、「情報共有を通して、どのようにアジャイルの基礎的な内容を学んだのか」を説明しました。 前回の計画をチームで立てるというトピックで、「アジャイルでは、イテレーションを何度も継続して回す」ことを伝えました。ここで大切な点は、「ただ単に繰り返す」ことを意味しているわけではないということです。イテレーションで得られたフィードバックを、次のイテレーションでより良い活動ができるように生かすことが重要です。 今回は、この「フィードバックをもとに、より良くする（改善する）」ことに焦点を当て、筆者が社内SNS構築の次に参画したプロジェクトを取り上げます。まずは、今回の事例で取り組んだ「業務システム」について、簡単に紹介します。 筆者が所属するTISでは、プロジェクトが完了すると、プ
スクラム概要とストーリーの書き方 | Ryuzee.com
著者のPeter Saddington氏はアジャイルコーチで、AgileScoutというブログやScrum Pocket Guideという本を書いたりしています。 このスライドでは前半でスクラムの説明（ロール、アプローチ、鶏と豚、会議体、作るもの等）をして、途中一旦の締めとして、アジャイルやスクラムにおける大事なこととして以下を説いています。 アジャイルの核はチームにあること優先度が最高のもっとも価値のあることから集中して取り組むことコミュニケーションの重要性ドキュメントはプロセスの中で書いて、前払いはしないことレビューを繰り返し繰り返し繰り返し行うこと完成を定義すること後半ではユーザーストーリーについてのより良い方法についてです。 ここでは、ユーザーストーリーは会話であり、異なるロールの人たちの間の会話をファシリテートするものであると定義して具体的な書き方についてワークショップ形式で記述
要求開発×アジャイル開発のポイント
1. 企業価値につなげるアジャイル開発 要求開発×アジャイル開発のポイント ～ビジネスに貢献するシステムを開発するために～ ウルシステムズ株式会社 ディレクター 河野正幸 ULS Copyright © 2011 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 2. アジェンダ 1. 従来のシステム開発方法の限界 2. 要求開発×アジャイル開発のコンセプト 3. 事例紹介 4. 自社で実践する上でのポイント ULS Copyright © 2011 UL Systems, Inc. All rights reserved. Proprietary & Confidential Powered by 1 4. システム開発の抱える本質的問題 1.つくり過ぎのムダ（使われないものを作る） 2
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
ARCによる新しいビジネスモデルの可能性
ARCでの開発プロセス 前回は、ARCモデル（Agile×Ruby×Cloudモデル）についての概要と価値について解説しました。今回は、ARCを実践していくうえでの開発体制、ツールや手法、マネージメント、そしてビジネス・モデルについて紹介していきます。ここでは、筆者たちSonicGardenでの実際の事例を元にしたものを、ARCの一例として紹介しています。 ARCでは、クラウドを介してエンドユーザーにサービスを提供していきます。エンドユーザーからすると、いつでも、いつからでも利用できることが価値になるわけです。ずっと最高の価値を提供し続けるのが"Point of Use"なので、「開発期間があって、テストをして、納品があって、それからは保守期間に入る」というプロセスではありません。開発と、テストと、実際に利用されるサービスの運用を、一体となって継続的に進めています。継続するクラウドの提供に
Martin Fowler's Bliki in Japanese - ユースケースとストーリー
http://www.martinfowler.com/bliki/UseCasesAndStories.html ユースケースとXPのストーリーとの違いは？ これはよくある質問だが、なかなか答えがまとまらない質問でもある。XPコミュニティの人々は、ストーリーはユースケースを簡単にしたものだと捉えている。私も以前はそう思っていたが、今は別の見方をしている。 ユースケースとストーリーは、どちらも要求をまとめる（organize）方法という意味で一致している。違うのは、まとめる「目的」である。 ユースケースは、ユーザーがシステムにどう携わるか、どう使うか、といったナレーティブ（narrative）を形作るために要求をまとめていく。したがってユースケースは、ユーザーのゴールとシステムとの相互作用がどれだけそのゴールを満たすかに焦点があてられる。 一方、XPストーリー（やよく機能などと呼ばれるもの
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） アジャイルなソフトウェア開発手法としてもっとも広く使われているのが「スクラム」です。このスクラムは、1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによって提唱されたものですが、その考え方の基盤となったのが1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。 1月14日にコミュニティが主催し都内で行われたイベント「Innovation Sprint 2011」は、このスクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏がそれぞれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Offshore XP experience with Shanghai
【資料公開】DevLOVE Test Dayでお話しました
