みなさんこんにちは。@ryuzeeです。 InfoQのアジャイルが「チームの５つの機能障害」に取り組むが良い記事でしたので紹介します。 すごく良い記事なのでぜひリンク先を読んでみてください。 ここでは次のように言っています。 アジャイルの実践は、明確に「ソフトウェア開発のよりよい方法の発見」を目標にしているが、チームの機能障害という側面も微妙に扱っている。直接人々に行動を改めるように言うのではなく、アジャイルの実践が、もっとも共通のチームの機能障害を克服する助けとなり、その結果、チームが仕事をするのに必要な強い基盤を構築できるようになる。 より低いレベルのチームの障害が取り除かれた時に、相互信頼の基盤が生まれ、チームの約束の対する責任と説明責任が生じることが、仕事中に、個人的な意図を優先させるのではなく、チーム全体の結果に、チームを集中させるのを助ける。 これらは言い換えれば以下のようにな

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 2つめの作業に入る前に1つめの作業を終わらせようビルドを壊してはいけないルーチンはユースケースの実装で必要になるまでは作ってはいけないユースケースの実装で必要になるまでは、メンバー変数を追加してはいけない意思決定することを恐れるな品質を向上させる方法を常に勉強しろ測定しろ、測定しろ、測定しろシステムではなく人を中心とした設計をしろ(最終的な目的はシステムを使って人々の仕事が成し遂げられるのを助けることだと理解しろ)テストは製品の一部だコードを書く前にテストを書け無駄を省けビルドが壊れたらすぐに対応する土壌をつくれ(壊れたビルドを放置するな)全てのチームメンバーは顧客の要求を理解する必要がある関連する事柄は一緒にしておけ(密接

みなさんこんにちは。@ryuzeeです。 他所の現場のデイリースクラムを見る機会は普通の人はなかなか無いと思うのでご紹介します。 この動画はシアトルのマイクロソフトでTeam Foundation Server（TFS）のアジャイル対応部分を作っているチームとのことです。 動画を見ていただくと分かるがいくつか特徴があるので解説しておきましょう。 スクラムでプロジェクトを行なっており、スクラムマスターやプロダクトオーナーというロールがちゃんと存在するデイリースクラムの基本に則り、スタンドアップで行なっているこれも基本通り、昨日やったこと、今日やること・・・のフォーマットで行われているタイムボックスも守られている（動画の時間から推察するに）スクラムボードの前で行うのが基本だが、そのかわりにTFSの画面を大きく写して行なっているすなわち、マイクロソフトといえども、守破離の守を行なっていることが分

みなさんこんにちは。@ryuzeeです。 10 Ways to Kill Your Retrospectiveという記事で、失敗するふりかえりについて、要因のリストが紹介されていたので、抜粋・意訳にてご紹介します。 そもそもふりかえりは自分たちのプロセスの改善のために行うのであって、ふりかえりを行うこと自体は目的ではありません。 ただし、うまくいかないチームを見ていると、問題は出せるが、具体的なアクションに落とせていないとか期限を切っていないためにずるずるやるやる詐欺になっていたり、もしくはあまりに大量の問題が出てしまいチームが諦め気味になってしまったりすることが多くあります。 少しづつでも改善していくことに価値があるので、たとえば、KPTというフォーマットで常にやらなければならないわけでもないですし、いつもと違う場所でやっても構いません。 1. 何も準備していないNG : スクラムのミー

みなさんこんにちは。@ryuzeeです。 定期的にSlideshareをウロウロして良い資料がないかを探しているのですが、技術的負債に関する分かりやすい資料があったのでご紹介します。 技術的負債とは、現在の進捗のために、将来のキャパシティ(ソフトウェアの開発能力)を犠牲にすることであるもうちょっと具体的に言えば、技術的負債とは、ソフトウェアの内部的な問題（見つかっているか見つかっていないかは関係はない）、要求の明確化の欠如、ダメな設計、ビジネスの要求に適していない設計、自動化できるはずの箇所の手動処理などを指す**利子の支払いは時間のムダである。**例えば欠陥を直すのに時間を取られる、要求が明確になった後に再度作りなおす、複雑なコードを理解するために余計な時間を取られる、などなど技術的負債の悲惨なサイクルがあるテストを書く時間がない、リファクタリングする時間がない、設計レビューする時間がな

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 1. ふりかえり（レトロスペクティブ）をしないか、間違ったふりかえりをするふりかえりをせずして、どうやって物事をよりうまくできるようにすることができるというのだろうか？ ふりかえりは、全てのチームメンバーがうまく行ったこと、もっとうまくできるだろうことについて議論できるという点で必要不可欠だ。 そしてもちろん言うまでもなく、失敗から学習しなければならない。もしそういったことが行われていない（形式的なふりかえり）なら、ふりかえりは役に立っていない。 2. ダメなプロダクトオーナープロダクトオーナーはいつでもプロジェクトのために時間を使えるようでなくてはならない。 プロダクトオーナーはスプリントプランニングやふりかえりに参加しな

はじめるにあたって必須のルール（骨格）フルタイムで参加できるスクラムマスターが決まっていて、スクラムチームのメンバーが仕事できる状態であることスクラムチームは30日以内に動作するソフトウェアのデモをすることに同意していることステークホルダーをデモに招くことできるかぎり早期に実現すべきスクラムの基本ルールスクラムマスターは必須や基本のルールに従うことを保証することフルタイムのプロダクトオーナー（専門知識と権限を持っている）が決まっていることスクラムマスターとプロダクトオーナーを含む機能横断チーム開発チームのサイズは6プラスマイナス3人プロダクトオーナーは開発チームや他のステークホルダーとともに働くことプロダクトオーナーによってプロダクトバックログの作成、管理がなされること3つの質問によるデイリースクラムミーティング（昨日やったこと、今日やること、障害事項）デイリースクラムを同じ時間に同じ場所

みなさんこんにちは。@ryuzeeです。 Agile Adviceの24 Common Scrum Pitfalls Summarizedより、スクラムで陥りがちな間違い24個がまとめられていたので、抜粋・意訳にてご紹介します。 スクラムはフレームワークとしてはそんなに複雑ではないですが、実践するのは結構難しいのが実情です。 よく聞くのがデイリースクラムが15分では終わらずに1時間かかるとか、出荷可能な製品をスプリント毎に作れないとかいったものです。 そして多くの組織において、基本としてのスクラムを実現できない（という思い込み）が故に、何かを変えたり、本来のスクラムの価値を失った間違ったやり方をしています。 以下にあがっているような症状があるのであれば、もう一度原理原則に立ち返って考えなおしてみるべきでしょう。 過剰な準備や計画作成：スクラムにおいては定常的な大きな前払いの計画作成は必要で

みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ

著作 SCRUM BOOT CAMP THE BOOK 著者／訳者：西村直人 永瀬美穂 吉羽龍太郎 出版社：翔泳社( 2013-02-13 ) 定価：￥ 2,520 スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。 CakePHPで学ぶ継続的インテグレーション 著者／訳者：渡辺 一宏 吉羽 龍太郎 岸田 健一郎 穴澤 康裕 出版社：インプレス( 2014-09-19 ) 定価：￥ 4,320 Webアプリケーション開発における継続的インテグレーションについて、CakePHPのサンプルをベースにして、その概要から使用ツール解説、導入方法、メンテナンスまでを解説 Chef実践入門 ~コードによる

みなさんこんにちは。@ryuzeeです。 5 min on Scrum | Retrospectives| 10 Ideasが良い記事だったので、抜粋・意訳にてご紹介します。 個人的には、ふりかえり（レトロスペクティブ）は近所の緑の多い公園にいってやったりできると素晴らしいと思っています。 ふりかえり（レトロスペクティブ）の形式を変えて行こう。新しい質問を追加したり、違うテイストでやってみるのだオフィスの中じゃなくて、公園とか庭でふりかえりしようNLPに関する本を読んで、本に記述されている表現方法を使ってみよう質問することを学ぼうふりかえりの最後に、次回のふりかえりをどうやって良くすることができるかを尋ねようスプリントで作ったものを持ってこようチームに事前に開催通知を送ろう。そうすればチームはふりかえりにデータを準備してくることができるストーリーワークショップをふりかえりとして実施しよう。

チームはスプリントの間ベストを尽くしたと信じよう最初にファクトデータを集めよう議論するのではなくて、ファシリテーションのテクニックを使ってファクトデータを集めようまずは良い雰囲気を作ろうふりかえりの内容を承認しようこの先改善するためにできることを見つけるためのブレストのセッションを設けよう未来に焦点を当てよう。チームが改善すべき問題とスクラムマスターが改善すべき問題を分離しよう 大事なのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し（すぎ）ないことです。 チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがあります。 アジャイルの基本理念の1つに「オープンであること」がありますが、それがなくなると、チームとしての力が結集できなくなります。 またふりかえりのファシリテーター役は、チームを非難しないことも大事です。 スクラムマス

みなさんこんにちは。@ryuzeeです。 スクラムにおける欠陥の扱い方について考えてみました。 スクラムでは欠陥の扱い方には特に規定はないので、以下はあくまで経験を踏まえた個人的なアプローチであることに注意してください。 欠陥の定義欠陥とは、プロダクトバックログアイテムが「完成」した後に見つかった欠陥のみを指すここでいう欠陥とはソースコードのバグと要求実装の欠落の双方を指す双方の具体的な定義や判断基準はプロジェクトによって異なる（欠陥の定義を作ると良い）バグと技術的負債は異なるスプリントで実装中のプロダクトバックログアイテムにおける動作不良や問題は、その時点では欠陥とみなさないなぜなら完成の定義や受け入れ基準に従ったものを開発チームは作る必要があること、プロダクトオーナーは受け入れ確認の際に、欠陥がある場合にプロダクトバックログアイテムを受け入れるか受け入れないかを決めることができるため対

〒194-0022 東京都町田市森野1-33-11 町田森野ビル 205 TEL : 042-720-2356 FAX : 042-720-2658 SERVICE chevron_rightRuby on Railsとの関わり chevron_rightサービス・開発の流れ chevron_right開発実績 ABOUT chevron_right代表挨拶 chevron_right会社概要 chevron_right沿革 chevron_right社員紹介 NEWS RECRUIT CONTACT SITEMAP