/// BANGBOO BLOG ///

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30

January 2, 2016

Agile
■アジャイル
http://codezine.jp/article/detail/5465
スコープを柔軟化するため、スプリントで区切り、スプリント後は動作するようにする、しかしスケジュール/リソースは固定
ボトムアップとして(ストーリー、タスクなどの)バックログ。WBSはトップダウンだった
スクラムやXP等を使う
- 要求機能はストーリーとして表現される
- プロダクトバックログを作成し、直近のリリース(スプリント数個分)ごとにリリースバックログを作成する
- スプリントごとにスプリントバックログとして作業を詳細化(時間単位)する
- スプリントの完了時には、テストされ、デモが可能な状態でなければならない
スプリントを導入しても、設計、実装、単体テスト、結合テストとタスクを分割していたのでは、ミニウォーターフォール
 逆に管理工数がかかったり品質が下がるかも。継続的統合やテスト駆動開発などが要る

1.計画を簡易的に行なう(スプリント単位で等)
2.その代わり定期的に見直す
3.簡易な計画/管理ツールを利用する
4.チームとしてスケジュールを組む

粗い要求までもリストアップするプロダクトバックログ(エクセルレベルで可)
次のリリースのためのリリースバックログ(エクセルレベルで可)
直近のスプリントのためのスプリントバックログ(タスク管理システムにすると意識しなくても良いかも)

初日にプランニングミーティングを行い、直近(2週間等)のタスクを計画
そして、毎日デイリースクラムを実施し、最終日にレトロスペクションミーティングで締めて
スプリントの1サイクルとなる

ミーティングでは、タスク管理システムないしは、
ホワイトボードに張られたタスクやバックログリスト(場合によってはガントチャート)などの
タスクを一覧できるツールを用いる

 ///プランニングミーティング
 プロダクトバックログから優先順位に従って選択したストーリーをタスクにブレークダウン
 ミーティング前
  1.タスクを決定する
 ミーティング時
  2.前スプリントのタスク完了を確認する
  3.メンバーの予定作業時間を確認する
  4.スプリントのゴールを共有する
  5.タスクを説明し工数を見積もる
 ミーティング後
  6.タスクを割り当てる

 ///デイリースクラム
昨日何をしたか?
今日何をするか?
進捗を妨げている問題は何か?

 ///レトロスペクションミーティング
 何をしたかについて、1人数分から十数分説明する
 何ができないか、どのような課題が残っているかに言及する


↓↓↓↓↓↓アジャイルから明確にスクラム

■スクラム
https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
///対話の価値(左が要らないとは言っていない)
プロセスやツール < 個人と対話
包括的なドキュメント < 動くソフトウェア
契約交渉 < 顧客との対話
計画に従う < 変化への対応

透明性:スクラムチームの現状や問題点を見える化すること
検査:見える化により問題点を見つけること
適応:スクラムチームに問題があった場合に、改善策を考えて対処すること

個人はスクラムチームのゴールの達成を確約しなければならない
メンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない
スクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開する
メンバーはお互いを能力のある独立した個人として尊敬しなければいけない

 ///プロダクトオーナー(PO)
- プロダクトバックログアイテム(PBI)の管理
- リリース計画策定
- 市場調査
- ステークホルダとの対話
- 開発チームとの対話
- 予算管理
- スプリントレビューで"DONEの定義"にしたがって受け入れ判断をする
注意点:POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。

 ///スクラムマスター(SM)
- 妨害リストの管理
- 妨害の除去
- POのサポート
- 開発チームのサポート
注意点:チームが自己組織化するために、SMはメンバーに直接的な指示(タスク割り当てなど)や管理(進捗管理など)をしてはいけない。スクラムにはPMは存在しない。

 ///開発チーム
- 開発、インクリメント(成果物)を完成
- プロダクトバックログの追加
- 妨害リストの追加
注意点:開発チームは自己組織化されており、外部から仕事の進め方やタスクを指示されるようなことがあってはならない。1つの開発チームは3-9人で構成されなければならない。それより少ないと機能横断的でなくなる可能性が高くなるためNG。多すぎると調整が大変になってしまうためNG。多すぎる場合は別のスクラムチームをもう1つ作るべき。開発チーム内で年齢や役職、会社の違いがあったとしても全員フラットな関係でなければならない。開発チームに専門能力の高いメンバーがいて、その分野ではその人に頼りがちだけど、そこで問題が起きたとしてもそれはそのメンバーだけの責任でなく開発メンバー全員の責任であることに注意する。

 ///ユーザーストーリー形式 
「〜として、〜したい。それは、〜だからだ。」を書きます。これは、INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testableの頭文字をとったもの)を満たす必要があります。プロダクトバックログのDoneの定義も定義

 ///スプリントバックログ
開発チームにより作成される。スプリント期間中での修正、追加、削除も可能である。スプリントバックログの管理を行えるのは開発チームだけである。規模や工数はバラバラで問題ないが、1つのスプリントバックログアイテムの見積もりは1日以下の大きさに分割すること。スプリントバックログアイテムは"未着手"、"着手中"、"完了"などのいずれかのステータスがラベル付けされており、そのステータスが可視化されている必要がある。JIRAでも付箋とホワイトボードによるアナログ方式でもどちらでも問題ない。自己組織化されているので、誰かに割り当てられるものではなく自ら挙手する。設計、コーディング、テストコードの作成だけでなく、結合テストなどの実施、CI環境改良、ノウハウを残すなどもスプリントバックログとして分割するべきである。

 ///妨害リスト
スクラムチーム内外で、妨害になっていることを優先度順にリスト化したものである。どのロールの人でも追加できるが、妨害リストの管理の責任者はSMである。いつでも追加可能だが、特にデイリースクラムやスプリントレトロスペクティブで課題(妨害)の共有が行われやすい。

 ///スプリント
1ヶ月以内の固定した開発期間を何度も繰り返す。1週間、2週間、1ヶ月のいずれかが一般的。スプリント期間内に完了しなかったプロダクトバックログアイテムがあったとしても、スプリントを延長してはいけない。スプリントの中止はよっぽどのことが無い限り、行われるべきでないが、もしものときは実行権限を持つのはPOだけである。

 ///スプリント0
自己紹介、スクラム理論の勉強会(認識合わせ必須)、当面のプロダクトバックログの作成と共有、必要技術スキルの勉強会、開発環境構築などを行うスプリント開始前の準備期間のこと。必要期間はチームにより異なる。

 ///リリーススプリント
インクリメントの統合テストや通常スプリントで残ったタスクを実施してリリースを行うための特別なスプリント。 原則、このスプリントは存在しません。スプリント毎にリリース可能なものを作成するので、リリーススプリントが無いことが理想だが、そうでない場合に用意される。リリーススプリントはPOがリリース準備が整ったと判断するまで続く。

 ///イベント
開発チームでイベント以外のミーティングができるだけ行われないようにする。全てのイベントはタイムボックス化されている(何分とか、何時間までとかが決まっている)。もし、タイムボックスを超えてしまった場合、議論をそこで打ち切る必要はないが、タイムボックスを越してしまったという事実は妨害リストに追加したり、スプリントレトロスペクティブで話し合う必要がある。

 ///スプリントプランニング
第一部は全てのロールが参加する。ただし、第二部はPOは連絡がつく状態であれば参加しなくてもよい。第一部では、ベロシティをもとに今回のスプリントで対応できそうな範囲でプロダクトバックログを開発チームが選択する。(POが選択してはいけない)
プロダクトバックログはリファインメントによってすでに見積もりがされている状態のはずだが、リファインメント後に新規追加されたプロダクトバックログアイテム(つまり見積もりがまだされていないもの)が含まれている場合は、この場でリファインメントを実施する。第二部では、開発チームは選択したプロダクトバックログアイテムをスプリントバックログに分割する。これにより、POとSMにどのようにプロダクトバックログアイテムを消化できるかを伝えられる状態になる。分割したスプリントバックログに時間数を見積もり、その総計が1スプリントでのチームが開発できる時間をオーバーした場合は優先度の低いプロダクトバックログから外していく。逆に余裕がある場合なプロダクトバックログを追加する。POの予想より多すぎたり少なすぎたりする場合は、開発チームとPOは話し合う。開発チームは選択したプロダクトバックログアイテムを完了することに全力を注がなければならないが、完了することを約束するわけでない。なぜならば、見積もり時にはわからなかった技術的に困難な事象が発生することはよくあるからである。無謀な長期の残業は行わない。

 ///デイリースクラム
- いつ?⇒毎日同じ時間(一般的には朝)
- どこで?⇒どこでもいいがいつも同じ場所
- 誰が?⇒開発メンバー。SMは必要に応じて参加する。POは見学(発言は基本的にNG)してもよい。
- 目的は?⇒開発チームの検査
- どれくらい?⇒最大15分
昨日やったこと、今日やること、あれば課題(妨害)の共有。課題は共有に留めること。管理職の見学は避けたい。なぜならば、共有でなく管理職への報告になりがちで自己組織化が損なわれやすいのと、課題共有がしにくい雰囲気になりやすいからである。もし管理職にエスカレーションするべき課題があるならば、デイリースクラム後に報告すること。

 ///プロダクトバックログリファインメント
- いつ?⇒スプリント期間中であればいつでも良い。
- 誰が?⇒全てのロール
- 目的は?⇒プロダクトバックログの透明性の獲得
- どれくらい?⇒最大1日(8h)
POはプロダクトバックログの説明(前回からの変更分、追加分、削除分、詳細決定部分、順序変更部分など)を行う。リファインメントの対象は、次のスプリントあるいはさらにその次のスプリントで開発対象となりそうなくらいの範囲となる。優先度低いプロダクトバックログの説明までは行う必要はない。本当に実施するかも不透明だし変更も発生しやすいため。開発チームはプロダクトバックログへの意見(追加アイディアや順序変更や質問など)、新しいプロダクトバックログアイテムの見積もり、必要であれば再見積もりを行う。

 ///プランニングポーカー
プロダクトバックログの見積もりには"プランニングポーカー"と呼ばれる手法が一般的に使われる。プ開発チーム全員がフィボナッチ数列(0, 0.5, 1, 2, 3, 5, 8, 13,...∞)の値が書かれたカードを持ち、プロダクトバックログアイテムごとに「いっせーのせ!」でカード(見積もり)を提示する。この見積もりは単位のない"相対見積もり"である。見積もりの値が似たような値で均等に分散したとき(例えば5が3人で8が3人の場合)は、悲観的に考えて大きい値(ここでは8)をストーリポイントとして計算したほうがよい。

 ///スプリントレビュー
- いつ?⇒スプリントの終わり
- 誰が?⇒全てのロールとPOが招待した重要な関係者(ステークホルダーなど)
- 目的は?⇒インクリメントの検査とプロダクトバックログの適応
- どれくらい?⇒最大2時間(スプリント2週間の場合)
開発チームはインクリメントのデモを実施して、質問に答える。また、完了できなかったプロダクトバックログがあれば説明する。開発チームはデモをやることと受け入れに通ることばかり考えがちだが、大切なのはスプリントレビューを通して、よりよいプロダクトを得るための手がかりを見つけることである。デモはそのための手段であって目的ではないことに注意しよう。また、デモの説明スライドは作るべきでない。そこに労力が割かれがちだからだ。POはDONEの定義に従い、インクリメントが受け入れ可能かを判断する。

 ///スプリントレトロスペクティブ
- いつ?⇒スプリントレビュー後かつ次のスプリントが開始される前
- 誰が?⇒SMと開発チーム。POは参加してもよいが必須でない。
- 目的は?⇒スクラムチームの検査と適応
- どれくらい?⇒最大1.5時間(1スプリント2週間の場合)
スプリントで人・プロセス・ツールの観点から問題がなかったか、もっと成果を出すためにできることがないかを議論し、次回のスプリント以降の改善策を考える。手法として、KPT(Keep, Problem, Tryを出し合うこと)がよく使われる。

 ///ベロシティ
ベロシティとは、そのスプリントで開発したプロダクトバックログのストーリーポイントの合計である。スクラムチームはベロシティを高めて安定させることを目指す。そもそもストーリーポイントがいい加減な値。フィボナッチ数列の値しかだせないし、開発者は技術的な不安点があるからとりあえず大きな値をしばしば出しがちである。さらに、スプリントの日数は祝日、メンバの休暇などでスプリント毎に異なるものである。

スクラムではテスト専門チームの存在を許していない。スプリントの中で徹底的にバグを発見して潰すべきなのである。


■マネジメント向け アジャイルの利点
https://www.ryuzee.com/contents/blog/13147

twitter
Hatena
Google Buzz
newsing
Yahoo!
Buzzurl
Technorati
del.icio.us
Choix
Iza!
Livedoor Clip
Facebook
Evernote
 

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)


PhotoGallery


TWITTER
Search

Mobile
QR for cellphone  QR for smart phone
For mobile click here
For smart phone click here
Popular Page
#1Web
#2Hiace 200
#3Gadget
#4The beginning of CSSレイアウト
#5Column
#6Web font test
#7Ora Ora Ora Ora Ora
#8Wifi cam
#9みたらし団子
#10Arcade Controller
#11G Suite
#12PC SPEC 2012.8
#13Javascript
#14REMIX DTM DAW - Acid
#15RSS Radio
#16Optimost
#17通話SIM
#18Attachment
#19Summer time blues
#20Enigma
#21Git
#22Warning!! Page Expired.
#23Speaker
#24Darwinian Theory Of Evolution
#25AV首相
#26htaccess mod_rewite
#27/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28竹書房
#29F☆ck CSS
#30Automobile Inspection
#31No ID
#32Win7 / Win10 Insco
#33Speaker
#34Arcade Controller
#35Agile
#36G Suite
#37Personal Information Privacy Act
#38Europe
#39Warning!! Page Expired.
#40GoogleMap Moblile
#41CSS Selectors
#42MySQL DB Database
#43Ant
#44☆od damnit
#45Teeth Teeth
#46Itinerary with a eurail pass
#47PHP Developer
#48Affiliate
#49/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51/// BANGBOO BLOG /// On 2020-03-01
#52/// BANGBOO BLOG /// On 2020-04-01
#53Windows env tips
#54恐慌からの脱出方法
#55MARUTAI
#56A Rainbow Between Clouds‏
#57ER
#58PDF in cellphone with microSD
#59DJ
#60ICOCA
#61Departures
#62Update your home page
#63CSS Grid
#64恐慌からの脱出方法
#65ハチロクカフェ
#66/// BANGBOO BLOG /// On 2016-03-31
#67/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70/// BANGBOO BLOG /// On 2020-01-21
#71Bike
#72Where Hiphop lives!!
#73The team that always wins
#74Tora Tora Tora
#75Blog Ping
#76無料ストレージ
#77jQuery - write less, do more.
#78Adobe Premire6.0 (Guru R.I.P.)
#79PC SPEC 2007.7
#80Google Sitemap
#81Information privacy & antispam law
#82Wifi security camera with solar panel & small battery
#83Hope get back to normal
#84Vice versa
#85ハイエースのメンテ
#86Camoufla
#87α7Ⅱ
#88Jack up Hiace
#89Fucking tire
#90Big D
#914 Pole Plug
#925-year-old shit
#93Emancipation Proclamation
#94Windows env tips
#95Meritocracy
#96Focus zone
#97Raspberry Pi
#98Mind Control
#99Interview
#100Branding Excellent
Category
Recent Entry
Trackback
Comment
Archive
<     September 2020     >
Sun Mon Tue Wed Thi Fri Sat
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
Link