『超初心者向け！visual studio + git で始めるアジャイル開発』 .NETラボ勉強会...

超初心者向け！ Visual Studio + git で始めるゕジャル開発

2014年07月26日(土) 16:00-17:10

.NETラボ勉強会 2014年7月 Microsoft MVP for Visual Studio ALM @fullvirtue

Copyright © fullvirtue. All rights reserved.

本日の概要本日のセッションの概要について確認していきます

Copyright © @fullvirtue. All rights reserved. 2

本日の概要（1/1）

本セッションについて（1/1）

概要

– 「gitって何？ゕジャルって何？」分散型バージョン管理システム(git)における、プルリク゛スト主体のゕジャルなチケット駆動開発について、実案件での経験を踏まえてお話します。

対象者

– 分散型バージョン管理システム(git)について知りたい方

– ゕジャルについて知りたい方

– チケット駆動開発について知りたい方

Copyright © fullvirtue. All rights reserved. 3

おことわり（1/4）

今回の資料について（1/4）

今回の資料は、以下を参考にしています。私自身のゝリジナルはほとんどありませんので、ご了承ください。

– デザイナのためのGit入門

» http://www.slideshare.net/dsuket/git-16343460

– サルでもわかるGit入門

» http://www.backlog.jp/git-guide/

– 知らないと現場で困るバージョン管理システムの基礎知識

» http://www.atmarkit.co.jp/ait/articles/1305/20/news015.html

– バージョン管理とは : 集中型 vs. DVCS

» http://japan.blogs.atlassian.com/2012/11/version-control-centralized-dvcs/


http://www.slideshare.net/dsuket/git-16343460




http://www.backlog.jp/git-guide/



http://www.atmarkit.co.jp/ait/articles/1305/20/news015.html


http://japan.blogs.atlassian.com/2012/11/version-control-centralized-dvcs/











– A successful Git branching model

» [Eng]http://nvie.com/posts/a-successful-git-branching-model/

» [日本語訳] http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html

– キャスレーの社内開発で利用するgitのブランチモデルとかPull Requestの簡単な解説とか

» http://www.casleyconsulting.co.jp/blog-engineer/git/キャスレーの社内開発で利用するgitのブランチモ/


http://nvie.com/posts/a-successful-git-branching-model/











http://keijinsonyaban.blogspot.jp/2010/10/successful-git-branching-model.html









http://www.casleyconsulting.co.jp/blog-engineer/git/キャスレーの社内開発で利用するgitのブランチモ/












– Agile vs. Waterfall, Revisited

» http://www.commonplaces.com/blog/agile-vs-waterfall-revisited

– 新人エンジニアが知っておきたいアジャイル開発

» http://www.slideshare.net/schoowebcampus/ss-30477398

– アジャイルソフトウェア開発宣言

» http://agilemanifesto.org/iso/ja/

– アジャイル開発の現在・過去・未来

» http://www.publickey1.jp/blog/10/post_121.html


http://www.commonplaces.com/blog/agile-vs-waterfall-revisited








http://www.slideshare.net/schoowebcampus/ss-30477398




http://agilemanifesto.org/iso/ja/


http://www.publickey1.jp/blog/10/post_121.html





– PMBOKの「10の知識エリア」

» http://consulting-skill.com/pmo/pmbok.html

– Scrum概要 #tfsug

» http://www.slideshare.net/Ryuzee/scrum-tfsug

– ウォーターフォールモデルの起源に関する考察ウォーターフォールに関する誤解を解く

» http://barrel.ih.otaru-uc.ac.jp/handle/10252/5163


http://consulting-skill.com/pmo/pmbok.html




http://www.slideshare.net/Ryuzee/scrum-tfsug




http://barrel.ih.otaru-uc.ac.jp/handle/10252/5163





本日のゕジンダ（1/1）

8

バージョン管理とgit

ゕジャルとソフトゕ開発

まとめ

バージョン管理とgit バージョン管理やgitの概要について説明します




10



まとめ

バージョン管理とgit（1/34）

よくあるバージョン管理の例（1/7）

フゔル名で管理

Copyright © fullvirtue. All rights reserved. 11 デザナのためのGit入門 http://www.slideshare.net/dsuket/git-16343460







フゔル名で管理


どれが最新？







共有フ゜ルダで管理


共有フ゜ルダ

index.html









共有フ゜ルダ

index.html

更新









共有フ゜ルダ

index.html

更新更新









共有フ゜ルダ

index.html

更新更新

衝突









あれ、上書きしちゃった…

共有フ゜ルダ

index.html

更新更新

衝突






バージョン管理システムとは（1/1）

フゔルに対して「誰が」「いつ」「何を変更したか」というような情報を記録

過去のある時点の状態を復元したり変更内容の差分を表示できるようにするシステム

Copyright © fullvirtue. All rights reserved. 18 知らないと現場で困るバージョン管理システムの基礎知識 http://www.atmarkit.co.jp/ait/articles/1305/20/news015.html





バージョン管理システムを使うと（1/1）

すぐ前の状態に戻せる

複数人で同じフゔルを更新しても大丈夫

変更履歴が観れる

リリース管理も簡単







なぜ開発の現場でバージョン管理を使うのか（1/1）

1. ゕジリテゖを高める » もし開発中にソフトゕにバグを埋め込んでしまっても、

問題の発生する以前の状態へ簡単に戻せる

2. 素早い開発が可能に » ある環境でバグなどの問題が発生した場合には、

過去にさかのぼって変更の差分を確認することで原因を分析したり、別に同じ環境を作って同じ問題が再現するかどうか調査できる

» ソフトゕへの影響が大きな“変更”や試験的な機能の追加を安心して行えるので、結果として素早い開発が可能になる

3. 余計な情報でコードが肥大しない » 変更内容はバージョン管理システムに記録されるので、変更前の内容を

コメントゕトしてコード中に残すようなことをする必要はない






何をバージョン管理するのか（1/1）

ある時点のソフトゕ・環境を構築するために必要なものすべて

– ソフトゕのソースコード

– ビルドスクリプト

– データベースのスキーマ定義、マグレーションの SQL、初期データ

– 環境構築用の設定フゔル・スクリプト






何をバージョン管理してはいけないのか（1/1）

バージョン管理する必要がない、共有してはいけないフゔル

– ソースコードをコンパルしてできたバナリフゔル

– 秘密鍵フゔルなどの他人に見せてはいけないもの






バージョン管理システムの方式（1/9）

『集中管理方式』

– プロジクトの単一の “中心” コピーがどこかに存在

» たいていはサーバー上であることが多い

– プログラマーはこの中心コピーに変更を “コミット”

» 単純に中央システムにその変更を記録することを意味

– 代表的な集中型バージョン管理システム

» CVS（Concurrent Versions System)

» SVN（Subversion)

» Perforce

『分散管理方式』

Copyright © fullvirtue. All rights reserved. 23 バージョン管理とは : 集中型 vs. DVCS http://japan.blogs.atlassian.com/2012/11/version-control-centralized-dvcs/













– プロジクトのフゔルの全バージョンを保管するための中央サーバーを必要としない

– 各開発者はレポジトリのコピーを “クローン” し、自身のハードドラブ上にそのプロジクトの完全な履歴を持つ

– 代表的な分散型バージョン管理システム

» git

» mercurial

» Bazaar

Copyright © fullvirtue. All rights reserved. 24 バージョン管理とは : 集中型 vs. DVCS http://japan.blogs.atlassian.com/2012/11/version-control-centralized-dvcs/














編集中編集不可

編集不可編集不可

編集中編集中

編集中編集中

デザナのためのGit入門 http://www.slideshare.net/dsuket/git-16343460










サーバー上のリポジトリ

ローゞルフゔルの編集

リモートリポジトリ


ローゞルリポジトリ












チックゕト＆フゔルロック

















コミット & フゔルロック解除ローゞルフゔルの編集


















ブランチ切替



プル















ブランチ切替



プル

マージ & コミットプルリク゛スト or プッシュ







分散管理方式のメリット（1/2）

手軽にコミットできる

ゝフランでもコミット出来る

コミットが増えると履歴が増える

履歴が増えると戻すのが簡単







分散管理方式のメリット（2/2）

ブランチ・マージが便利

別バージョンを作るのが簡単

別バージョンをマージするのが簡単







Gitが不得意なこと（1/1）

バナリフゔルの管理が苦手

– 遅くなる

– 差分が取れない







ブランチを中心としたソフトゕ開発（1/7）

ブランチとは

– 履歴の流れを分岐して記録していくためのもの

– 分岐したブランチは他のブランチの影響を受けない

– 同じリポジトリ中で複数の変更を同時に進めていくことができる

Copyright © fullvirtue. All rights reserved. 35 サルでもわかるGit入門 http://www.backlog.jp/git-guide/stepup/stepup1_1.html

http://www.backlog.jp/git-guide/stepup/stepup1_1.html






5種類のブランチを軸に構成

1. master

2. develop

3. feature

4. release

5. hotfix

Copyright © fullvirtue. All rights reserved. 36 A successful Git branching model http://nvie.com/posts/a-successful-git-branching-model/














master hotfix release develop feature















本番環境の不具合対応

不具合対応を開発環境にも反映

不具合対応内容を本番環境に反映

本番リリース時にタグを付与















リリース前確認で不具合発見し

たので対応

不具合対応を開発環境にも反

映

リリース内容を本番環境に反映

本番リリース時にタグを付与















開発環境に反映

Featureブランチを新たに作成














ブランチがmasterに収束している例

複数の開発が並行で進んだ例

順番に開発を進めた例


プルリク゛ストのススメ（1/2）

「プッシュ」と「プルリク゛スト」の違い

– プッシュ(push)

» 誰からもレビューされていないソースコードを、開発者の判断で、全員に影響があるブランチに反映

– プルリクエスト(pull request)

» 誰かしら変更内容を確認したソースコードを、権限のある役割の方の判断で、全員に影響があるブランチに反映



プルリク゛ストのススメ（2/2）

Copyright © fullvirtue. All rights reserved. 43 http://www.casleyconsulting.co.jp/blog-engineer/git/キャスレーの社内開発で利用するgitのブランチモ/










gitを操作するのに便利なツールのご紹介（1/1）

『SourceTree』

– git や mercurial 用の強力な無料 Mac / Windows クラゕント

– https://www.atlassian.com/ja/software/sourcetree/overview


https://www.atlassian.com/ja/software/sourcetree/overview

https://www.atlassian.com/ja/software/sourcetree/overview

アジャイルとソフトウェア開発

Copyright © fullvirtue. All rights reserved. 45 http://www.commonplaces.com/blog/agile-vs-waterfall-revisited











46



まとめ

ゕジャルとソフトゕ開発（1/31）

これまでのソフトゕ開発（1/1）

Copyright © fullvirtue. All rights reserved. 47 新人゛ンジニゕが知っておきたいゕジャル開発 http://www.slideshare.net/schoowebcampus/ss-30477398

市場

事業

IT

市場分析

依頼/発注

納品

リリース要件

設計

実装

テスト

半年～数年






近年のソフトゕ開発のニーズ（1/1）


スピード重視

初期ユーザーを獲得するため早期に市場に出したい

スモールスタート

事業初期にかかる初期投資額はなるべく下げたい

フゖードバック

開始後に出るニーズや経験を反映していきたい

スケールゕト

事業が軌道に乗るに従って拡大をしていきたい

要件が不確定で小規模なため、これまでの開発は非効率

新人゛ンジニゕが知っておきたいゕジャル開発 http://www.slideshare.net/schoowebcampus/ss-30477398






よくある開発の落とし穴（1/1）

いつまでも完成しない

完成しても誰も使わない

直したくても改修できない







ゕジャル開発の効果（1/1）

リスクを初期に下げる

可視性を常に高く保つ

変化コストを一定に保つ







ゕジャル開発のプロセス（1/1）

短いサクルで、分析・設計・実装・テストを同時並行で行い、繰り返す







゜ーターフ゜ールモデルの誤解（1/1）

゜ーターフ゜ール[原著]は、一方通行の開発モデルではない

– ゜ーターフ゜ールが間違って広まっている事実を知らない人が多い

Copyright © fullvirtue. All rights reserved. 54 ゜ーターフ゜ールに関する誤解を解く http://barrel.ih.otaru-uc.ac.jp/handle/10252/5163






ゕジャルソフトゕ開発宣言–4つの価値（1/1）

私たちは、ソフトゕ開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して私たちは以下の価値に至った。

– プロセスやツールよりも個人と対話を、

– 包括的なドキュメントよりも動くソフトゕを、

– 契約交渉よりも顧客との協調を、

– 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

Copyright © fullvirtue. All rights reserved. 55 ゕジャルソフトゕ開発宣言 http://agilemanifesto.org/iso/ja/





ゕジャルの原則（1/1）


顧客価値の優先

変化に対応

短期のリリース

全員同席

モチベーションと信頼

会話

動くソフトゕ

持続可能なペース

技術的卓越性

シンプル

自己組織的チーム

ふりかえりと改善






ゕジャルソフトゕ開発宣言–12の原則（1/3）

ゕジャル宣言の背後にある原則

私たちは以下の原則に従う

1. 顧客満足を最優先し、価値のあるソフトゕを早く継続的に提供します。

2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

3. 動くソフトゕを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

4. ビジネス側の人と開発者は、プロジクトを通して日々一緒に働かなければなりません。









5. 意欲に満ちた人々を集めてプロジクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

6. 情報を伝えるもっとも効率的で効果的な方法はフス・ト・フスで話をすることです。

7. 動くソフトゕこそが進捗の最も重要な尺度です。

8. ゕジャル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。









9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

11. 最良のゕーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。






フゖードバックサクル（1/1）

『作って、見せて、調整していく』ことをひたすら繰り返す

フゖードバックサクルを数多く回す



ゕプリケーションラフサクルマネジメント（1/1）



プロジクトマネジメント（1/1）


スコープマネジメント

コストマネジメント

コミュニケーションマネジメント

統合マネジメント

ステークホルダーマネジメント

リスクマネジメント

調達マネジメント

人的資源マネジメント

タイムマネジメント

品質マネジメント

What

How How much

When

How How How

Why How

Who Where

PMBOKの「10の知識゛リゕ」 http://consulting-skill.com/pmo/pmbok.html






プロダクトマネジメント（1/1）


『製品』を対象

①意思決定されたものを実行

②日常的な業務を遂行していくため

の役割を期待されている

③新製品の開発

既存の製品ランの管理

④現在のシステムが機能し続ける

ように複雑さに対処すること

『チーム』を対象

①意思決定を行う

②会社を変革していくための役割を

期待されている

③さまざまな役割を持つチーム

メンバーを、企業やチームが描く

ビジョンを、製品を通して実現

しようと動機づけをする

④現在のシステムを変革していくこと

マネジメントリーダーシップ


計画を立てる


プラン


計画を立てる


プラン

Version エピック

バックログ

スプリント

クイックフィルター


計画を立てる


エピック課題


計画を立てる


エピック課題

エピックの基礎情報

エピックに関する概要

エピックの各工程毎に課題タイプ「ストーリー」を作成


スプリントをまわす


作業




作業

作業前のタスク・オープン・再オープン・保留

進行中のタスク・設計中・開発中・テスト中

解決済みのタスク・設計完了・開発完了・テスト完了

クローズしたタスク・設計レビュー済・最終マージ済・テスト確認済

クイックフィルター




レポート




ダッシュボード




ダッシュボード

リリースノート

バーンダウンチャート

自分が抱えている課題




[ポイント] 事前にテンプレートを作成して共有しておく ↓ 起票の度に各項目を入力する手間が省ける


リリースを管理する




リリースを管理する



リリース対象の課題の一覧を、リンク付きで表示

リリース対象の課題の一覧を、 HTMLで表示

まとめ



本日お話したこと（1/1）

79



まとめ


ご静聴ありがとうございました。

『超初心者向け！visual studio + git で始めるアジャイル開発』 .NETラボ勉強会...

Technology

Transcript of 『超初心者向け！visual studio + git で始めるアジャイル開発』 .NETラボ勉強会...