ＩＦＲＳ義務化の是非の判断が、先送り

ということは、SIerさんで、ＩＦＲＳ関係で
儲けようとしていた人は、ひとまず、お休みということですよね。

日本版ＩＦＲＳを検討するそうなので、
それが決まるまでは、動けないかな・・・


国際会計先送りへ＝財界抵抗、米国動向も影響
http://news.goo.ne.jp/article/jiji/politics/jiji-130617X369.html

光より、無線だろう・・・

昨日、変な電話かかってきた（＞＿＜！）

NTT東日本と”名乗る人”（かなり怪しい？？たぶん、違う）から
（以下この人をNさんとします）


Nさん：「YAHOO　BBのサービス、ADSLでご使用ですよね」
私：「はい」
Nさん：「今後、支障がでますので、今なら工事費無料の光回線に変えたいと思いますので・・・」
私：「おいちょっとまて！なんで変えなきゃいけないんだ、光回線に」
Nさん：「じゃ、インターネット解約するんですか？支障がでるんですよ！！（怒）」
私：「はあ？？」


だれが好き好んで、
何が楽しくて、
光にしろ、なんにしろ、有線に変えるんだよ・・・

今、入っているから、
変えるのめんどくさいからADSLなわけで、
本当に支障が出るんなら、ふつう、WiMAXとか、無線に切り替えるだろう・・

あ～、それにしても、変な電話だった。
なんか、おかしなこと、おこらないだろうなあ（－＿－；）

P.S
　絶対、NTT東の人じゃなく、代理店の人だよねえ・・・
　もう、光にわざわざ、変える時代じゃないよねえ・・・

スクラム ブートキャンプにいってきた その３

スクラム　ブートキャンプ　for NII
講師　高江洲　睦氏(twitter,facebook: @takaesu0)
のお話の続き

Ｓｃｒｕｍって何？

のメモメモ

---

導入
・フレーワーク
　　３つのロール
　　４つのイベント
　　３つの成果物
　それらの関係性や相互作用を統括するルール

→技術的なプラクティスはない
　→ＸＰとの併用になる

特徴
・軽量
・理解は容易
・習得は非常に困難

　　Ｓｃｒｕｍアライアンス
　　　　理解の低いところ：ワースト３－日本

大事なこと
・経験的（エンピリカル）にプロセスを制御する
・反復的、漸進的に進めていく
・３本柱を大切に

３本柱
・透明性：関係者全員が共通理解をもつ
・検査：障害検知、ゴールに向かっている？
・適応：プロセスを調節

ロール（ヒト）
・プロダクトオーナー
・開発チーム
・スクラムマスター

プロダクトオーナー
・Ｗｈａｔを探求するヒト
・プロダクトバックログ（ＰＢＩ）の管理責任者
　　項目を明確に
　　優先順位付け（優先度（高がいっぱい）と優先順位（一列に）は違う）
　　価値を保証
　　プロダクトバックログの見える化
　　開発チームが理解できるように

開発チーム
・Ｈｏｗを探求する
・インクリメントを作成する
　　３～９人
　　自己組織化
　　職能横断的
　　専門家がいてもチーム全体の責任

スクラムマスター
・Ｓｃｒｕｍの番犬
・スクラムの理論、プラクティス、ルールを内外に守らせる
　　外部からのチームの盾となる
　　サーバントリーダー
　　ほかのロールを支援
　　スクラムイベントをファシリテート
　　ほかのロールの潤滑油

サーバントリーダーシップ
・傾聴
・共感
・いやし
・気づき
・納得（説得でなく）
・概念化
・先見力
・世話役
・人々の成長にかかわる
・コミュニティづくり


ＷｈａｔとＨｏｗ
Ｗｈａｔのじく：プロダクトオーナー
ＨＯＷのじく：開発チームが責任
理想はどちらも正

成果物
・プロダクトバックログ
・スプリントバックログ
・インクリメント

プロダクトバックログ
・ただひとつのプロダクトに対するバックログ
　　プロダクトに必要なものが順序付けされた一覧
　　　　優先順位の高いものは同じ大きさ
　　プロダクトオーナーにより管理される
　　　　バグ、技術的課題を含む
　　各項目は、ユーザーストーリーの書式を使用することが多い
　　　　大きさは１日から数日
　　スプリント内で手入れ（グルーミング）される
　　直近の数スプリント分は詳細に
　　　　受け入れ条件を明確化
　　　　　　デモ手順

バックロググルーミング
・スプリント内で行うバックログの手入れ
　　　スクラムチーム全員が参加
　　　頻度やどう手入れを行うかはスクラムチームで決める
　　　必要があれば見積もり

ユーザーストーリー
　　・＜役割＞として
　　・＜機能や性能＞がほしい
　　・それは、＜ビジネス価値＞のためだ

よいストーリー：ＩＮＶＥＳＴ
　　Ｉ独立してる
　　Ｎ交渉できる
　　Ｖ価値がある
　　Ｅ見積もれる
　　Ｓ適切な大きさ
　　Ｔ評価できる

スプリントバックログ
・ＷｈａｔとＨＯＷを結びつけるもの
　　プロダクトバックログ項目をインクリメントにする契約をまとめたもの
　　　　開発チームによって管理される
　　　　必要なタスクをすべて見える化
　　　　　　タスクボード
　　　　　　バーンダウンチャート
　　　　残作業の見積もりを日々更新
　　　　タスクは誰が担当してもいい
　　　　　　むしろ、固定化は悪

タスクボード
・Ｓｔｏｒｙ
・ToDo
・Doing
・Done
　タスク管理でよく使われる
　　　模造紙やホワイトボードを使用
　　　　　付箋がよく使われる
　　　　　強粘着タイプ必須
　　　地理的に分散した環境は、デジタルツールで

ふせんのはがしかた
　　Ｘ下からめくる→粘着面がそり、はがれやすくなる
　　○横にはがす
　　○上から下に引く

バーンダウンチャート
　　残作業管理の定番
　　　　スプリント内のタスクの合計残時間を記録
　　　　基準線と見比べて状況を把握
　　　　　　状況によってプロダクトオーナーと相談して調整
　　　　模造紙やホワイトボードを使用
　　　地理的に分散した環境は、デジタルツールで


インクリメント
・スプリント終了時の増分
　　スプリントで完了したプロダクトバックログ項目の成果物
　　　　スプリントの終わりには完了しているべき
　　　　プロダクトオーナーにより受け入れられるか否かにかかわらず
　　　　常に動く状態

完了の定義
・作業の完了についての合意を見える化
　　→チェックリスト
　　Ａさんの完了とＢさんの完了が違っていたら？
　　成熟度によって、厳しさも異なる
　　更新されることもある

完了の定義例
　テストコードがすべてパスしていること
　コードレビューが済んでいる
　　　　：
　　　　：

妨害リスト→スクラムマスターが管理
・非公式だがよく知られたもの
・デイリースクラムなどであがった妨害のリスト
・スクラムマスターが管理、優先度の高い障害から取り除く

イベント
・スプリント計画ミーティング
・デイリースクラム
・スプリントレビュー
・スプリントレトロスペクティブ

イベントの特徴
・定義かされていないミーティングの必要性を最小化
・スプリントそのものを含め、すべてタイムボックス化

スプリント
・１週間から１ヶ月のタイムボックス
　　　決めたら最後まで期間を変えないこと
・この間の変更受け入れは原則なし
　　　スプリントの長さを決めるのに影響
　　　なくはない（２週間でたまに？）
・途中で中止の可能性もある
　　　ＰＯが権限をもつ

２Ｗスプリントの例
・スプリント計画ミーティング
　　月曜はじめ１部、２部

・デイリースクラム
　　毎日朝（ないし昼）

・スプリントレビュー
　　金曜終わり１つ前
・スプリントレトロスペクティブ
　　金曜終わり一番最後


スプリント計画ミーティング第一部
　スクラムマスター（外）
　プロダクトオーナー
　開発チーム

　プロダクトバックログ
　プランニングポーカー

開発チームがスプリントで開発する機能を計画
　　スプリントの２．５％のタイムボックス
　　優先順位の高いバックログ項目を理解し
　　その大きさを見積もる
　　実績に基づいた収まる分量
　　　ベロシティ

見積もり
　　基準を決めよう
　　整数で考える
　　まよったら大きいほう

見積もりの流れ
・１、２、３、５、８、１３
準備
・優先順位の高いものから見て、簡単そうなものを２とする
・優先順位の高いものから見て、その倍ちかいものを５

流れ
１、優先順位の高いものから、
　　２と５と比べて決めていく
２、全員が同じ数字
３、全員がとなりあう数字になったら、大きいほうをポイントとして１へ
　　　１回目でそろったら、念のため根拠をいう
４、一番大きな数字と小さな数字を出したヒトが根拠を
５、２に戻る

ベロシティ
・開発チームの生産量
　　各スプリントリームの生産量
・固定するパラメータに応じて可変するパラメータを予測できる

スプリント計画ミーティング第二部
・Ｗｈａｔの実現をＨｏｗに落とし込む
・プロダクトバックログ項目を完了にする方法を決定
　　→スプリントの２．５％のタイムボックス
　スプリントバックログを作成
　　各タスクは１日以下の単位に分解
　　理想時間で見積もる
　　時間はチームのだいたいの平均
プロダクトオーナーの参加は任意
　　何かあったら聞けるところに

デイリースクラム
・タスクログ
・バーンダウンチャート
・日々の検査と適応の場
・毎日の情報共有
　　毎日定時１５分以内
　　開発チームとスクラムマスター
　　話すこと３つ
　　　前回のデイリースクラムからやったこと
　　　次回のデイリースクラムまでにやること
　　　困っていること
　　→進捗報告会ではない。今の状態をわかってもらう場
　　　スクラムマスターはファシリテートするだけ

スプリントレビュー
・スプリントの検査と適応
　　インクリメントの検査を行う
　　スプリントの２．５％のタイムボックス
　　スクラムチーム全員参加
　　ＰＯやステークホルダーへのデモ
　　ＰＯが受け入れをきめる

スプリントレトロスペクティブ
　次スプリントのカイゼン計画
　　　スプリントの２．５％
　　　スクラムチーム全員が参加
　　　　　ＰＯは任意、いいづらければはずれる
　　　うまくいった項目、改善点、改善案
　　　ＫＰＴ（けぷと）

ＫＰＴ
・振り返りの定番
　話し合うのは、次の３つ（付箋とか使う）
　　Ｋｅｅｐ
　　　よかったこと、続けたいこと
　　Ｐｒｏｂｌｅｍ
　　　よくなかったこと、カイゼンしたいこと
　　　→Ｔｒｙにあげていくように
　　Ｔｒｙ
　　　やってみたいこと、改善案
　　　→あがりすぎたら、できることに絞る

スクラム ブートキャンプいってきた！ その２

スクラム　ブートキャンプ　for NII
講師　高江洲　睦氏(twitter,facebook: @takaesu0)
の話のつづき。

「Agileって何？」について

をメモメモ

---

■アジャイルソフトウェア開発宣言
　　→どうやっているかを気にして、心構えがおろそか
はじめにスクラムがあって、ＦＤＤがあって、
　そのあと、アジャイルソフトウェア開発宣言がでた
　　　→アジャイルは共通部分

・アジャイル開発の４つの価値
　　左記の事柄に価値があることもみとめる
　　右記の事柄により価値を置く
　→ドキュメント書かなかったから、アジャイルではない
　ケンシュエーバー、ジェフサザーランド、
　ロバートＣマーチン

・１２の原則
（１）顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供します
　　　満足、継続重要、価値は定義されている？
（２）要求の変更はたとえ開発の後期であっても歓迎します
　　　変化を味方につけることによって、お客様の競争力を引き上げます
　　　　いつでも変更ＯＫ？
（３）動くソフトウェアを２－３週間方２－３ヶ月というできるだけ
　　　短い時間間隔でリリース
　　　　　スプリント、イテレーション
（４）ビジネス側の人々と開発者は、プロジェクトを通じて日々一緒
　　に働かなければなりません
　　　　組織パターンの「信頼で結ばれた共同体」→これが入り口
（５）意欲に満ちた一部とを集めてプロジェクトを構成します。
　　　環境と支援を与え、仕事が無事終わるまで彼らを信頼
　　　　「自己組織的」、「職能横断型」

（６）情報を伝える最も効果的で効率的な方法は
　　　フェイスＴＯフェイス
　　　　ドキュメント不要でない→ほかのヒトとの共有

（７）動くソフトウェアこそが進捗の最も重要な尺度です
　　　　「８０％できてます」ってどれくらい？
　　　　「テストのみ」は本当？→完了の定義

（８）アジャイルプロセスは、持続可能な開発を促進します。
　　　一定のペースを継続的に維持できるようにしなければなりません。
　　　「スプリント」は全力疾走ではない！！
　　　マラソンにおける１ｋｍの走り方を考えよう

（９）技術的卓越性と優れた設計に対する不断の注意が俊敏さを高める
　　　ジェームスグレニングさん：技術力重要（スクラムだけでなく）

（１０）シンプルさ（無駄なく作れる量を最大限にすること）が本質
　　　先読みして作りすぎちゃわないように→だれかが勝手に使う
　　　ＸＰの「ＹＡＧＮＩ」

（１１）最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出される
　　　→反対が「コマンド／コントロール脳」：責任と権限は誰のもの
　　　　自己組織的なチーム

（１２）チームがもっと効率を高めることができるかを
　　　　定期的に振り返り、それに基づいて自分たちのやり方を最適に調整
　　　→のどもと過ぎれば・・・
　　　　炎上したプロジェクト→打ち上げで忘れる→反省しない→同じこと繰り返す
　　　　ＸＰの回顧、スクラムのスプリント・レトロスペクティブ

Ｄｏ　Ａｇｉｌｅ：アジャイルする
Ｂｅ　Ａｇｉｌｅ：アジャイルになる
→Ａｇｉｌｅは、形容詞！！→図るべき
～やっているからアジャイルというわけでない

ＷＦでも、アジャイルに開発することはできる
自分ひとりからでも、できる　　

6月16日(日)のつぶやき

　ウィリアムのいたずら　@xmldtp　12:05

「うさみみ」のペアプログラミング blog.goo.ne.jp/xmldtp/e/a61d2…

2 件 リツイートされました

from gooBlog production

返信 リツイート お気に入り

---

Follow @xmldtp