SCRUM/アジャイル開発の入門資料を全力でまとめてみた
『アジャイルサムライ－達人開発者への道－』に続いて、アジャイル開発のバイブル的書籍『SCRUM BOOT CAMP』を読みました。SCRUMの実践的な知識を漫画をおりまぜながら、本当にわかりやすく書いている良本でした。これから何度も読み直して、アジャイルの習得に努めます！ ということで、今回は書籍を読む過程で集めたSCRUMやアジャイル開発に関するスライドやPDF、ブログ記事などをまとめていきます！ 🗽 アジャイル開発手法特論 From Agile-development-course-advanced-1-2 産業技術大学の2013年2Qの講義『アジャイル開発手法特論』の資料だそうです。SCRUM BOOT CAMPの著者の一人であるながせ☆みほさんの作です。ちなみにながせさんのブログ上に#6までの資料がアップされています。ほかのスライドもかなりのボリュームで読み応え抜群です！ 😀
「アジャイルでの開発がうまくいかない」と思っている人に伝えたいたったひとつのこと - assertInstanceOf('Engineer', $a_suenami)
先日、とあるスタートアップ企業の役員の方々に来社いただき、プロジェクトの進め方に関する相談を受けたのですが、その際にきっと伝えたいことをうまく伝えられなかった気がするのでブログにまとめてみます。 すごく具体的な悩みを抱えてるように感じたのでとても抽象度の高い話で参考にならないかも知れないですが、大切なことだと思うのでできれば彼らに最後まで読んでもらえればと思って書きます。 僕がアジャイルに出会って約2年くらい経ちますが、それを整理する意味でもいい機会かと。 結論 先に結論を書きます。 アジャイルとは組織論だと思っています。 相談内容 ざっくり相談された内容を列挙してみます。 ベロシティがなかなか安定しない スケジュールが遅れることがある 専門性が分散（サーバサイド、フロントエンド、スマートフォンアプリ等）してしまっていて、タスクの融通ができていない どのようなツールを使っているか いろいろ
【アジャイルアカデミー2013年度第2期】アジャイルサムライの見積りと計画づくりに参加してきました！ | DevelopersIO
こんにちは、おおはしりきたけです。9月6日(金)に翔泳社さんが主催している、アジャイルアカデミーに参加してきました。色々学ばせていただいたので、レポートを書かせていただきます。 アジャイルアカデミーとは？ アジャイルアカデミーは、一流講師陣による1日完結型の少人数ワークショップです。過去にも以下のようなワークショップが行われてきました。 第1期 2013/6/24：『アジャイルサムライ』でつかむアジャイル開発の全体像：角谷信太郎氏 2013/6/25：TDD Boot Camp (Agile Academy Edition)：和田卓人氏 2013/6/26：実践アジャイル製品開発マネジメント：角征典氏 2013/6/27：Scrum Boot Camp Premium：西村直人氏 2013/09/02：Scrum Boot Camp Premium (Agile Academy Editi
アジャイル開発プロセスの実証的効果検証について - Kentaro Kuribayashi's blog
これまでこのブログであれこれ書いている通り、今年は勤務先の有志によりスクラムが大規模に導入され、様々なひとたちの協力と粘り強い実践のおかげで、徐々に定着しつつある。当初の理想のようにはうまく行かないことも多かったけれども、もっとよくしようという工夫、よくなるはずだという信念によって、実践に取り組んでいる人々の中では、改善の効果が実感されつつあるように思う。 しかし、問題がないわけではない。もちろん、プロセスそのものをさらに改善できるという意味でも課題はあるが、それとともに、導入の効果を実証的に示すことがなかなか難しいということも大きい。簡単にいえば「で、スクラム導入によってなにがどれぐらいよくなったの？」という端的な質問(別に誰かにそうきかれたわけじゃないけど、自分自身にそのように問いなおした場合)に、うまいこと答えられないということだ。 VersionOneによる年次報告のような継続的な
アジャイル開発と反復型開発は違うのか？ - Cube Lilac
所用で Code Complete を読んでいると「反復型開発 (Iterative and Incremental Development)」と言うキーワードが出てきました*1。「反復」と言う単語を聞いてまず思い浮かんだのは昨今よく話題になっている「アジャイル開発」なのですが、「アジャイル開発」と言うキーワードが指しているものと「反復型開発」と言うキーワードが指しているものは果たして同じなのかどうか自分では判断が付かなかったので Web 上の記事を漁ってみる事にしました。 漁ってみた結果ですが、少なくとも「完全に同一のものである」と言う認識の人はほとんどいないようです。 インクリメンタル型開発とイテレーティブ型開発を合わせたソフトウェア開発手法のこと。システム全体をいくつかの部分に分割して反復しながら機能や品質を洗練し、それを段階的に全体に統合していく開発プロセスをいう。狭義にはアジャイ
顧客を満足させ続けるプラクティスについて
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOKKotaro Ogino
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
ScaleOut | Supership
「ミライリアルの幸せを、デジタルの力で創る」ことを目指すSupershipグループの社内報です。日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipグループの”Be Super”なストーリーをみんなでシェアしていきます。
アジャイルがユーザーや顧客企業に嫌われる理由 | スラド デベロッパー
「アジャイル」なソフトウェア開発がここ数年注目されているが、アジャイルなソフトウェア開発において特徴的な反復 (イテレーション) や柔軟性といった手法は、顧客やユーザーにとってはまとまりも終わりも無い開発手法に見えるという。これを取り上げたITWorldのブログが本家/.にて話題になっている。 アジャイル開発を好む開発者は多い。イテレーションはユーザのニーズを的確に反映できるだけでなく、対応すべき要件があがってきたとしても問題が大きくなる前に対処することが可能だ。各要件に一つずつ取り組むため、きちんとフィードバックを受けて問題が無いことを確認してから次の要件に着手することもできる。 しかしユーザにとってみると、アジャイル開発は不透明で分かりづらく、故に不安を生んでしまうもののようだ。まるで開発プロセスが無く、開発方針も定まっていないように見えると、アジャイルプロジェクトに加わったとある人は
アジャイル開発において、技術と品質の重要性は不可欠だ（前編）。Agile Japan 2013
年に一度行われるアジャイル開発のイベント「Agile Japan」が今年も開催されました。今年の基調講演は、アジャイル開発の中で品質の重要性をあらためて位置づける目的で、James Gernning氏が「“Demand Technical Excellence”アジャイルにおける技術と品質の重要性」という題で行っています。 アジャイル開発とは、単にすばやく柔軟に開発する手法なのではなく、そこに品質を作り込んでいくことが欠かせないのだ、というメッセージでした。非常に多くの内容が詰め込まれた講演でしたが、その概要を記事として紹介しましょう。 “Demand Technical Excellence”アジャイルにおける技術と品質の重要性 James Grenning氏。 その前に、私がアジャイル開発に関わった経緯について触れておきましょう。 1999年当時、私はRobert Martin（著名な
「正しいアジャイル」でなくてもいい
AgileSamurai Reading Yokohama Dojo Introduce LT in Scrum Alliance Regional Ga...M I
アプリケーションの漸進的リリースについて - おともだちティータイム
とりあえずメモ アプリケーションの機能や UI を大きく変更する際、変更後のアプリケーションがどんなに優れていたとしても既存ユーザからは悪い反応しか来ない。 それはそうだ、既存ユーザは "優れた UI" や "画期的な機能" を使いたいのでは無くて、いままで使っていたアプリケーションを明日も変わらず同じ操作で使い続けられることを期待しているからだ。 しかし、今のアプリケーションでは、明らかに良くない UI 、不足した機能、 UX 上の問題がある。開発者としてはアプリケーションを変更する必要を感じている。 では、一体どうやってアプリケーションをリリースすれば良いのだろうか。 当たり前の話なんだけど、少しずつアプリケーションを変更していけば、そういった問題は無くなる。だけど、一般的にはそういうリリースをしているアプリケーションをあまり見掛けない気がする。 そもそも少しずつ変化していくアプリケー
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
アジャイルをダメにしないためにすべきこと - arclamp
「アジャイルがダメだと思う7つの理由」をエントリしてから一週間が経ちました。まさかPublickeyにまとめが載るとは思いませんでしたよ。 内幕を正直に書くと、あの日の昼に「アジャイルも普及してきて妙に執着する人が増えたよね」と茶飲み話していており、それを「受託開発に真面目に取り組むマネージャーが、知り合いでアジャイルにハマった人に久しぶりに出会って『時代はアジャイル』と熱くねちねちと語られているうちに、どうにも納得できなくてキレた」という設定で書いたものです。刺激的な表現もあってお騒がせしました。 反応していただいたBlogは「アジャイルがダメだと思う7つの理由」に追記してあります。その他の反応ははてブでも見てもらえればと思います。 職業アジャイラーの皆様からは同意と反論が混ざった反応をいただいております。ご意見がある方は引き続きBlogで書いて頂ければ幸いです。あのエントリは仮想人格が
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
アジャイルの「顧客に価値を届ける」の嘘と本当 - mizchi log
酔った勢いでアジャイルについて思うところを書く。 顧客に価値を届けるのは誰か 顧客に届く価値 = 目に見える成果物、という評価は、フロントに近い人間しか評価されなくなる傾向を抱え込む。顧客に価値が届くまでには段階がある。複雑なものほどワークフローが長大になる。お互いの価値を見積もれるのは、小さいチームでお互いの職種について理解がある場合の理想であり、多くの場合理想は理想である。大きなチームほど、フロントに遠い人間は自分の価値を伝えるのが難しい。 難しいことを難しいということ エンジニアが自分の仕事について、エンジニア以外への責任説明を果たそうとすると努力は必要だが、必ずしもそれが伝わるとは限らない。 難しいことを難しいと言えないと、「それってすぐできるんでしょ？」という展開になりがちで、「任せてくれ！」と言えるのはかっこいいが、誰しもがスーパーエンジニアではない。そして見積もりに失敗する。
Scrum概要 #tfsug
Scrum概要 #tfsug 1. Scrum概要 2013/2/1 Ryutaro YOSHIBAhttp://www.flickr.com/photos/18091975@N00/3654141771/13年2月1日金曜日 2. 吉羽 龍太郎 Ryutaro YOSHIBA アジャイルコーチ Ryuzee.com Twitter: @ryuzee13年2月1日金曜日 3. Agile研修やオンサイトコーチングの提供13年2月1日金曜日 こちらからは営業しませんw 4. • これから超大事なこと言います！http://www.flickr.com/photos/32397140@N00/3744438913年2月1日金曜日 5. 2013年2月に Scrum Boot Camp の本が出ます！13年2月1日金曜日 6. 2013年2月発売 先行予約受付中 定価：2520円 http://ww
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"DAD本"の歩き方 - DevLOVE #134
Hud美さんと学ぶRedmine×Jenkinsの神アジャイル
技術的負債のユーザストーリーを作るべきか
