xp入門 ~これで分かる!究極のxp入門~
TRANSCRIPT
4【氏名】
西 丈善(にし たけよし)
1971年生まれ
【仕事】
組込系ソフトウェア開発
【スキル】
C、C++、オブジェクト指向、リファクタリング、デザインパターン、XP、PF
【コミュニティ】
・「日本XPユーザーグループ関西」 副代表
・「PFP関西」 スタッフ
・「IT技術者ダンス部」 主催
6
開発現場を変えるエクストリーム・プログラミング入門
�Share Wiz ACT�「開発現場を変える エクストリーム・プログラミング入門」
�https://act.share-wis.com/courses/12�料金:3,000円
本日のセミナーのフルサイズ・バージョンを動画でご視聴頂けます。
7
IT技術者向けパラパラ入門 Vol.2
� 日時:2016年7月2日 13:00 ~16:00� 場所:AJITO� 申込:Doorkeeper 47064� https://itdanceclub.doorkeeper.jp/events/47064
今回、運動不足がちなデスクワークの多いIT技術者の皆様へ向けて、「パラパラ」入門編を企画致しました。
パラパラに触れる事ができるこのチャンス、是非お見逃しなく。
11
XPの歴史
• 最初にXPが実践されたのは「C3プロジェクト」。• 危機的状況にあったC3プロジェクトを救うべく、過去に経験した手法を最大限に実施。その結果、プロジェクトの建て直しに成功。
• この経験を元に、XP本を執筆。急速に拡大。
1996年 ケント・ベックがC3プロジェクトに携わる。
1999年 米国で『eXtreme Programming Explained』刊行。
2000年 日本で翻訳本『XPエクストリームプログラミング入門』刊行。
12
名前の由来
•[extream]=極端な/究極の– 良い事を徹底的に行い
– 不要な事を徹底的に行わない
•[Programming]– プログラミングこそソフトウェア開発の「中心活動」と捉えている。
良い事 不要な事
100%
0%
ソフトウェア開発プロジェクト
100%
0%
13
XPとアジャイル開発
•XPは「アジャイル開発宣言」に参加している開発手法である。
アジャイルソフトウェア開発宣言
アジャイルソフトウェア開発手法
XP Scrum FDDCrystal
Clear DSDM
15
アジャイル開発宣言~4つの価値~
プロセスやツール
包括的なドキュメント
契約交渉
計画に従う
個人と相互作用
動作するソフトウェア
ユーザとの協調
変化に対応
より
より
より
より
【従来の価値観】 【アジャイルの価値観】
• 左側にも価値はあるが、右側の方が、より多くの価値を含んでいると考える。
16
アジャイル開発宣言~12の原則~1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
19
XPの基本思想
1.前提
3.5つの価値
4.14の原則
4つの管理変数
開発環境
見積もり
開発プロセス
開発Tips
5.開発プロセス
プラクティス郡
ソフトウェア開発を成功させるために配慮しなければならない前提
XPの目指す方向性
XPの目指す方向を汎用的に示す指標
価値を得るために実施する行動原則
2.指針
20
1.前提
・すべてのシステムに適用可能な開発手法は無い
・人の重要性
・変化は起きる
開発対象、開発者、規模……など、様々な条件が完全に一致するプロジェクトは無い。プロジェクト毎に、開発手法を変える必要がある。
ソフトウェアは人の手によって生み出される。人には個性があり、開発プロセスの画一化のためこれを排除しようとしてきた。しかし、XPでは「個性」こそソフトウェア開発において重要な要素であると考えている。
「ツールのバージョンアップ」、「競合他社が類似製品をリリース」、「スタッフの移動、転職、退職」、「景気の悪化」、「開発マシンの故障」、……など、予測困難な変化が発生する可能性は十分ある。
ソフトウェア開発を成功させるために配慮しなければならない前提。
21
2.指針
・人が満足すること
・変化に適応すること
・実績を重視すること
ソフトウェア開発の中心は「人」である。ユーザーも「人」、開発者も「人」、管理者も「人」。XPは、ユーザー、開発者、管理者、すべての「人」が満足することに焦点をあてている。
未来に起こる変化を予測することは非常に困難。変化を予測して実装しても、予測が外れる場合、ムダなコストが発生する。「予測」は止め、ソフトウェアをいつでも変更可能な状態にしておくことだけに集中する。
見積もりの際、「予測」が必要になる。過去の実績から未来を予測することで、予測の確率を向上させることができる。過去の実績を重視することで、あいまいな予測を可能な限り排除する。
ソフトウェア開発を成功させるために目指す方向性。
22
3.5つの価値
・コミュニケーション
よりよいソフトウェア開発には、チーム内の円滑コミュニケーションが必須。
・シンプル
必要なモノ・コトのみ残す。無駄なものは排除する。
・フィードバック
「結果」を得ること。早く、多く、結果を得る方が良い。
・勇気
判断、決断すること。決断する際「コミュニケーション」「シンプル」「フィードバック」「尊重」が得られるか判断する。
・尊重
相手(顧客、上司、チームメンバー、社長、事務、両親などすべての人)に気配りする心。
「指針」で示した方向性を汎用的に示す指標。
23
4.14の原則
1.人間性– 休養や達成感は必要。人間は馬車馬ではない。
2. 経済性– 利益がちゃんと得られる開発をしよう。
3. 相互利益– みんなの利益になるように活動しよう。他人のバグでも取るのだ。
4. 自己相似性– 開発の基本はみんな同じ。テスト作成→テストの動作の繰り返し。
5. 改善– 理想と現実を近づけるために日々努力しよう。
6. 多様性– 多様性を否定しない。チームの衝突を納得行くように解決しよう。
7. 反省– 失敗を隠さず理由を分析しよう。
8. フロー– ソフトウェア間の結合は細かく行い、開発のフローを止めない。
9. 機会– 問題が起きたら、それは変更するための機会と前向きに考える。
10. 冗長性– 冗長性も時には必要。大事な冗長性は取り除かないように。
11. 失敗– 失敗することは無駄ではない。解の出ない議論を繰り返さず、とりあえず作ってみよう。
12. 品質– 品質を低くしたからと言って、プロジェクトが早く進むことはない。
13. 小さなステップ– 一度に大きく変更せず、小さく変更してすぐテスト。
14. 責任の受け入れ– 権限と責任にずれがないようにする。さもないと「お前がやれ」ということになる。
プラクティスを実践する際、「5つの価値」を得るために実施しなければならない行動原則。
26
XPの開発プロセス
• 繰り返し型開発(イテレーション型開発)
• 「極小のウォーターフォール」の集合。
• 小さな設計/開発を何度も繰り返す。
• 何度もリリースする
• 開発中に顧客からのフィードバックが得られる
• 後工程のリスクを削減することができる
• 全部完成するまで待たなくても、一部の機能からメリットを教授することができる
27
XPの開発プロセス
▼お客様
リクエスト
ストーリカードストーリカードストーリカードタスクカードタスクカードタスクカード
製品
▼リーダー
▼メンバー
・要求を1件づつカードに書く・カード単位に見積もりを実施・優先度/工数/期間により、実施するストーリーを決定
・ストーリをタスクに分割・タスクを実行
・期間内に開発したストーリを満たすソフトウェアをリリース
28
XPの開発プロセスリリ|ス計画
リリ|ス
リリ|ス
リリ|ス
イテレーション
ストーリストーリストーリカード
イテレ|ション計画
イテレ|ション実施
イテレ|ション実施
イテレ|ション実施
タスク タスク タスク
手短な設計
テスト
コ|ディング
リファクタリング
ストーリストーリタスクカード
ストーリストーリタスクカード
ストーリストーリタスクカード
イテレーション イテレーション
ストーリストーリストーリカード
ストーリストーリストーリカード
タスクカードには、「ソフトウェア開発」以外の内容も含まれる。(例)・仕様書作成・環境構築・手順書作成
etc"
ペアプロTDDリファクタリング
29
プラクティス群
• 経験に基づいて有用性が立証された実践項目。
• XPの開発プロセスの中に、散りばめられている。• XPでは、初版では14種類、第2版では24種類のプラクティスが提案されており、このプラクティスこそXPを最も象徴するものとなっている。
• プラクティスを実践することが、XPでは無い。• ソフトウェア開発を成功させるために何を行うべきか現場に合わせて取捨選択する必要がある。
30
� 全員同席� 計画ゲーム� 短期リリース� 最適ペース� スタンダップミーティング� ユーザテスト� シンプル設計� ペアプログラミング� テスト駆動型開発� リファクタリング� 常時結合� コード共同所有� コーディング規約� メタファ
プラクティス群の変遷
�<主要プラクティス>
�全員同席
�チーム全体
�情報満載のワークスペース
�いきいきとした仕事
�ペアプログラミング
�ストーリー
�週次サイクル
�四半期サイクル
�ゆとり
�10分ビルド
�継続的インテグレーション
�テストファーストプログラミング
�インクリメンタルな設計
�<導出プラクティス>
�本物の顧客参加
�インクリメンタルなデプロイ
�チームの継続
�チームの縮小
�根本原因分析
�コードの共有
�コードとテスト
�単一のコードベース
�デイリーデプロイ
�交渉によるスコープ契約
�利用都度課金
XP入門 【初版】 14種類 XP入門 【第2版】 24種類
31
XPの管理変数
• QCDに相当する。
• QCDに無い「開発規模」=Scopeがある。• 「Scope」でQCDを明示的にコントロールする。
Scope
Resource
Quality
Time
・Time(開発期間)・Resource(開発人員/機材)・Quality(品質)・Scope(開発規模/ストーリの数)
限られた時間(Time)の中で、要求される品質(Quality)のものを、予算内(Resource)で消化可能なストーリ(Scope)をお客様に選択頂く
33
開発手法の比較
� XPは、従来型と逆の価値観を持っている。
� XPの場合、変更コストを一定に保つことができる。
【従来型】 【XP】
実装後に単体テスト 単体テスト作成後に実装
ユーザは外部 ユーザは開発チームの一員
リリースは一番最後に1度だけ できるだけ頻繁にリリース
すべて完成したら結合 1モジュールが完成したら結合
将来の要求を予測して実装 現在必要な機能だけを実装
開発後期の変更コストは高い 変更コストは常に一定
プロセス重視 人を重視
ドキュメント重視 コード重視
コスト
時間
▼従来型
時間
コスト
▼XP
XPに期待することは何ですか?�会社の開発環境改善
� XPについては、初体験です。分かりやすく解説していただければ幸いです。
�今回は期待できるものがあるかどうかを知りたい。
� XPで使われているプラクティスを理解し、今の現場に適用させチームと商品、それぞれの価値向上を目指したい。
�勉強会で布教の仕方の入門がしりたい。
�人間中心設計、リーンスタートアップ、コードを質のいい状態に保つ開発内コミュニケーションの改善
�業務の効率化
�開発サイクルの高速化
�効果的なプロジェクト運営
�実際のxpとは、どのように動くものなのか
�開発における生産性の向上とコミュニケーションの円滑化
�テスト駆動の最新情報
�品質の向上
�プロジェクがうまく推進できること
�アジャイルプロセスの導入や評価方法が知りたい。
�ウォーターフォールでの開発が多いので、どのようにシフトして行けば良いのか考えたい。