エンタープライズアジャイル勉強会の資料 - @m_seki の
エンタープライズアジャイル勉強会という勉強会に呼んでいただけたので資料公開しますね。広島の旅費が苦しいのでこういうのうれしい！ Gumroadからの課金勢のみなさんへ 恒例！スライドに名前を入れる券 2017-2018 反復開発を中心に お話したこと 反復開発は全工程やって1ターンだよっていうみんなが知ってる（けど、ある方面のScrumではやられていないことが多いらしい）ことを45分間ずっと説明しました。 その結果チームの境界（サブシステムとか工程別チームとか）がどうでもよくなると思う（実感してる）んだけど、Scurm Incの説明だと階層がたくさんある例を示していたし、永田さんはQA部門にこだわりがあるのがおもしろいなー。自分も含めて、みんな自分の状況が好きなんだな。いいことだ。 再演バイト待ってます。 （再演したいんじゃなくて、RubyKaigiの旅費かせぎたいので！） speaker
Microsoft PowerPoint - ProjectFacilitation20070314.ppt[読み取り専用]
1 Copyright © 2005-2007 Kenji HIRANABE, Some rights reserved 現場力を高める 現場力を高める見える化 見える化手法 手法 プロジェクトファシリテーション プロジェクトファシリテーション ～ ～モチベーションアップの モチベーションアップの ツールと場づくり ツールと場づくり～ ～ 株式会社永和システムマネジメント 株式会社チェンジビジョン 平鍋 健児 http://www.ObjectClub.jp 2 Copyright © 2005-2007 Kenji HIRANABE, Some rights reserved 本日のお話 本日のお話 z 自己紹介（簡単に） z プロジェクトの見える化を実践例で z プロジェクトファシリテーション（PF）とは？ z PFの価値 z PFの原則 z PFの実践 プロジェクトファシリテーション
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
ベロシティに対する誤解 | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは？まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』（Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29）の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
INVEST in Good Stories, and SMART Tasks - XP123
XP teams have to manage stories and tasks. The INVEST and SMART acronyms can remind teams of the good characteristics of each. Are you a Product Owner or a writer of user stories? I’d love to hear about your challenges and successes at william.wake@acm.org! In XP, we think of requirements of coming in the form of user stories. It would be easy to mistake the story card for the “whole story,” but R
ストーリーポイントとファンクションポイント法の比較 - プログラマの思索
ストーリーポイントに関するInfoQの記事をまとめたのでリンクしておく。 ラフなメモ書き。 【元ネタ】 InfoQ: ストーリーポイントは複雑さや時間と関係があるか？ InfoQ: ストーリーポイントとは何か？必要ものなのか？ InfoQ: タスクに費やした時間ではなく開発速度をトラッキングする InfoQ: 価値とベロシティ、そしてバリューベロシティの比較 InfoQ: ストーリーポイントの間違った使い方。 今振り返ってみると、ストーリーポイントの概念はXPが提唱して生まれ、Scrumがアジャイルな開発プロセスに組み込んで厳密に定義したように思える。 ストーリーポイントは、従来のソフトウェア開発から考えると奇妙な考え方だろう。 ソフトウェアの開発規模を表すが相対比較になっているので、厳密な開発規模の単位にはならない。 あくまでも固有のプロジェクトでしか通用しない規模の単位。 元来、開発規
Martin Fowler's Bliki in Japanese - 標準ストーリーポイント
http://martinfowler.com/bliki/StandardStoryPoints.html 標準ストーリーポイントというのを XP やってる複数のチームに適応する なんてーのはどうですかという質問を受けた。 同じストーリーポイントを使っているチームをいくつか集めて、 あるチームの3ストーリーポイントが他のチームのそれと同じだーとかなんとかやりたいんだと。 そんなもんたかが知れてるように思うんだがなあ。 最悪、デンジャラスなことも起こるしなあ。 XP での見積もりは、XP速度と昨日の天気に基づいている。 これはつまり、見積もりに使う単位はぜんぜん重要じゃないっつーことだ ――重要なのは、大まかな相対価値を用いた見積もりと、 目安としての昨日の天気だ。 ストーリーポイントは、昨日の天気のフィードバックループのアンカーとして機能する ――それ以上のもんじゃない。 そこには、 チ
アジャイルな見積りと計画づくり：第2部：規模を見積もる「４章 ストーリーポイントによる規模の見積もり」まとめ - 基本へ帰ろう
個人的感想 「期間を導出する」と「自分で期間を見積もる」 この差は大きいと感じた。暗黙的に過去の経験をもとにして期間を見積もっているかもしれないが、数字に落とし、計測していくと、その数字が定規となり、顧客に見せられ、何もないよりも、説得力がでると感じた。顧客とのコミュニケーションの信頼が増すことで、よりいっそう仕事がしやすくなり、価値の高いものを生む仕組みが作れると感じた。 目次 規模を見積もる ストーリーポイントは相対的 ベロシティ ベロシティが見積もりミスを補正する 規模を見積もる アジャイルチームは、規模の見積もりと期間の見積もりとを分けて考える 規模の見積と期間の見積の違い。この違いを理解するために、これから私の庭の端にある一山の土を、庭の反対側の端まで運ぶことになったとしよう 期間のみを見積もる場合 私は土の山を眺めて、手持ちの道具を思い浮かべる（シャベルと手押し車だ）。そして、
テストについて考える #devlove
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: プロダクトオーナーを成功させる
ペアプログラミングが難しい理由
Theory Of Constraints: Productivity Metrics in Software Development · Los Techies
Backlog Refinement Meeting - CollabNet Scrum Training Part 2
Subversion LDAP Authentication with Apache
SSSSLIDE
ThoughtworksのTechnology Radar 2012年3月版
