アジャイルコーチングで学んだ78のこと
みなさんこんにちは。@ryuzeeです。 78 Things I Have Learned in 6 Years of Agile Coachingの記事が素晴らしいので、78個の項目を意訳にてご紹介します。 「私が6年間のアジャイルコーチングで学んだこと」というテーマでアジャイルに関する経験談がまとめられています。 アジャイルについて説明させてくれるように頼む人の数＝アジャイルメンタルモデルの数±2分散した開発では各サイトのチームごとに愛とスクラムマスターが必要だフットボールテーブルはあなたの最良のアジャイルなツールのうちの1つかもしれない地理的分散はタイムゾーンの違い以上の問題がある。その場合はインフラのサポートが必要だローカルのイベントやオンラインのメーリングリストやカンファレンスやカジュアルな集まり等を通じてアジャイルコミュニティに精力的に関わることには十分な価値がある。プロダクト
ゴールに向かうためにサイドチェンジした - 冥冥乃志
私の今までの取り組みと、このところの取り組みの変化を整理したエントリなので長いです。個人的な話なので、ソフトウェア開発全般に適用できる話を期待されている方にとっては読む価値が薄いエントリだと思います。 3年前に初めてすくすくスクラムに参加して以来、すくすくスクラム瀬戸内の代表として小さいながらも勉強会を開催したり、Agile Japanのサテライトを開催したり、自社の開発をアジャイルに方向づけていこうと小さな取り組みをしたりしてきましたが、最近取り組みかたというか自分の活動に対してフォーカスが当たっている個所が変わってきました。そして、その変化のベクトルが今までとは変わった気がしていて、ゴールが変わってしまっていないかと若干不安になっているところもありました。 変化の理由について自分でもいまいち整理がつかなかったのですが、あるエントリがきっかけで自分の中でも少し言葉になってきたのでまとめて
Agile Testing Practices
The document discusses using automated testing tools and techniques in agile teams. It covers emerging technologies like continuous integration, testing DSLs, model-based testing, and example driven testing. It provides examples of generating test cases using all combinations and all pairs techniques to systematically test interactions. The document also introduces QuickCheck for automatically gen
SAFe 6.0 Framework
Overview The SAFe Overview is a visualization of the seven core competencies of Business Agility and the dimensions of each. Essential The Essential SAFe configuration provides the minimal elements necessary for ARTs to deliver solutions and is the simplest starting point for implementation Large Solution The Large Solution SAFe configuration is for enterprises building large and complex solutions
ソフトウェアをつくるための３つの役割〜アジャイルに外部設計は必要か | Social Change!
ソフトウェア開発にはどんな役割が必要だろうか。よくあるウォーターフォールの世界では「要件定義」「基本設計（外部設計）」「詳細設計（内部設計）」「実装」などといった名前で工程を分けることで役割を分けています。アジャイル開発のスクラムでは「プロダクトオーナー」「スクラムマスター」「チーム」といった名前で分けています。役割の名前が違えば、ソフトウェアのつくり方が違うかというと、そうではなくて「やるべきこと」は同じだと考えています。 ソフトウェアをつくる上で「やるべきこと」は何か ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。 最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。 一人で
Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（前編）
先週の水曜日（10月19日）に、アジャイル開発手法「スクラム」を学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。 スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み ～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。 同社は2名の担当者が中心となり、社内セミナーなどでスクラムに興味を持ってもらうことで社内の自主的な変化を促す一方、評価制度や内部統制などの制度を調整する担当役も置くことで制度面での変化も後押しするなど、スクラム導入の具体的な手法が紹介されました。 そのセッションの内容を紹介しましょう。 2名で分担してアジャイル開発の推進を開始 ヤフー株式会社 R&D統括本部プラットフォーム開発本部本部長 志立正嗣氏。 組織の立場から見て、どういう風にスクラムを導入してき
Fearless Journeyかんたんガイド
Fearless Journeyのルールや準備・進め方をまとめた資料を作りました。 2012/05/21追記 1. ちょっとだけ改訂しました。 2, 私が作ったpngファイルは印刷するには解像度が低すぎました… 印刷したい方は次のリンク先にあるpdfをご利用ください。 https://docs.google.com/open?id=0Byh-cIUeiW9wRV9IVmVCZ3o2Zjg ◇Fearless Journeyって何？ ゲームです。 目的の妨げとなっている障害を、いかにチームで克服するのかを学ぶためのものです。 障害を取り除くための戦略をFearless Changeという本の48のパターンから持ってきているのが特徴です。 詳しくは以下のリンクをどうぞ。 公式サイト http://fearlessjourney.info/ @kdmsnr様のスライド http://www.sl
自己組織化やTimeboxを理解する簡単なワークショップ
An Agile Game - Management by Walking Aroundより。以下に紹介するワークショップは認定スクラムマスター研修などでもよく行われるもので、自分の会社でも簡単にできるので是非やってみていただきたい。 コーチやトレーナーやスクラムマスターがチームを教育するための簡単なゲームを紹介しよう。このゲームは時間もかからず簡単な体を使うもので、単純なルールやタイムボックスによって自己組織化された環境がつくられる様を示している。自己組織化された環境はリスクを軽減し、エンゲージメントやスピードや柔軟性を向上させる。 概要と事前準備所要時間：感想や報告を含めて10分〜15分対象人数：10人〜50人準備：テーブルや椅子等の物が置かれている十分に広い部屋、部屋の中にゲームの参加者が十分動けるだけのエリアの境界線を引くためのマスキングテープ。そしてタイマーラウンド1のやり方参加
ペア・プログラミング：An Agile Way：オルタナティブ・ブログ
アジャイルのプラクティスを、もう一度解説して行きたいと思います。できるだけ、日本の文脈にあった内容を加えて、実践できるように。また、野中先生に後でコメントを頂く予定。 ペア・プログラミング 文字通り、2人一組になってペアでプログラミングを行う。XPでの１つのプラクティスに挙げられており、１台のPCを交互に使って行うのが基本形。昨今ではデュアルディスプレーを使ったり、ネットワークと画面共有を使ったりして遠隔地で実践しているチームもある。 コーディングは単純作業ではない。１つ１つの変数や操作の名前を決めることや、その構造、アルゴリズムにいたるまで、多くの設計判断が入り込む、クリエイティブな活動である。また、ミスが起こりやすい作業でもある。刑事やパイロット、スキューバダイビングなど、リスクが高い作業はペアで行うことは現実の世界にはたくさんある。二人でプログラミングを行うことで、リアルタイムにレビ
)
Ten Year Agile Retrospective: How We Can Improve In The Next Ten Years
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Jeff Sutherland invented Scrum in 1993 and worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto. Jeff's blog reviews the origins and best prac
アジャイルユーザーエクスペリエンスプロジェクト
アジャイルプロジェクトはまだ十分にはユーザー主導になっていないが、最新の調査によれば、開発者の方が実際のところ、UX関係者よりもユーザーエクスペリエンス（UX）の重要な課題に対しては楽観的だった。 Agile User Experience Projects by Jakob Nielsen on November 4, 2009 我々は昨年、ユーザビリティ手法のアジャイル開発プロジェクトへの統合における成功事例について、調査を実施した。 通常、1年しか経ってないのに、同じ問題についての調査をわざわざする価値はない。ユーザーの行動というのはそれほど変化するものではないからだ。しかし、このプロジェクトに限っていえば、問題になっていたのはユーザーの行動ではなく、ユーザビリティを保証するための最適なアジャイルプロジェクトの運営方法であった。 この分野はまだ新しいので、我々は新たにより詳細な調査を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IIBA
アクセス集中エラー
http://guide.agilealliance.org/subway.html
トラクターはアジャイルで作られた
?title=We're_Having_a_Party!