開発 - みる会図書館


検索対象: アジャイル:ソフトウェアエンジニアリング
154件見つかりました。

1. アジャイル:ソフトウェアエンジニアリング

開発 第 6 章 包括的なドキュメントよりも動くソフトウェアを。 - ーアジャイルマニフェスト・ △図 6-1 ュートンの振り子は定番の卓上玩具である。一方の端からカを加えると、鉄球 が規則的で予測可能な揺れ方をする。そこで反対側からカを加えると、鉄球は無 秩序な反発連動を始める。これは開発プラクティスのメタファーになっている。 単純な、方向を持つ力は予測可能性を助長し、矛盾する力は混乱状態を引き起こ す可能性がある。 この章は、プログラミング言語やデザインパターンを説明する章ではありません。 これらの重要なトピックについては、他の多くの書物の中で十分に論じられていま す。この章では、 Visual Studio を使ってコードを動作可能なソフトウェアに変えて http://www.agilemanifesto.org/ ①

2. アジャイル:ソフトウェアエンジニアリング

第 5 章 アーキテクチャ —Alan C. Kay 単純なものは単純でなければならず、複雑なものは実現可能でなければならない。 △図 5-1 どんなシステムにもアーキテクチャがある。 チャの好例と言える。 ミッパチの巣は創発的なアーキテク こまでの章では、スプリントでどのように開発を行い、チームがどのようにし て進捗状況を把握するのかについて説明してきました。以降の 4 つの章では、スプ リント期間中の活動、つまりプロダクトバックログ項目 (PBI) を動作するソフトウェ

3. アジャイル:ソフトウェアエンジニアリング

278 移植性 .. 索 引 依存関係グラフ… イテレーション ... イリティーズ .. グリーンフィールドプロジェクト .. クラス図 .. 規定中心のメトリクス .. 技術的負債 .. 「完了」の定義 . 管理可能性 .. かんばん .. 環境互換性テスト .. 可用性 .. ガバナンス . 狩野分析法 .. 過度の負担 .. 価値フロー 仮想テスト環境 .. 過剰生産 . カオスの境界線 .. 回復性 .. 開発者チーム .. ■か 大野耐ー ■お エレベーターピッチ .. エピック .. 工クスペリエンス .. ■え 連用性 .. 運搬 . 受け入れテスト… インストール容易性 .. インクリメンタルな反復型開発 . 継続的インテグレー 形成ー混乱ー統一一機能 .. ・け ンヨン .. ... 69 … 23 … 65 … 23 ... 68 … 69 … .70 … 55 . … 54 … 22 … 68 … 56 … 42 … 68 … 183 , 185 … 10 , 38 … 27 , 203 … 104 , 121 ... 6 , 203 … 5 , 39 . … 203 … 32 , 132 , 175 … 13 , 36 , 173 … 52 … 103 . … 116 ... 12 ケイデンス .. ゲートチェックイン .. 欠陥モデル .. 懸案事項 . 検査と適応 .. 創発的アーキテクチャ… 探索的テスト… 効率性 .. コードレビュー コードメトリックス .. コードベースの完全性 . コードチャーン… コードクローン… コードカバレッジ .. コード化されたテスト .. コンポーネント図 .. コンウェイの法則 .. コミットメント .. 顧客による検証… 顧客価値 .. 手動コードレビュー 自動コード分析… 殺虫剤のパラドックス 作業分解 .. サイクルタイム ... サービス容易性 .. 受け入れテスト .. サービス品質 .. 刺激因子 . 仕掛品 シェルプセット .. シェルブ .. シーケンス図 . 残存作業 .. 自動ビルド . 自動コード分析… 実証的プロセスモデル .. 実証的プロセス制御 .. 実現性 .. システム思考 . 事実中心のメトリクス .. 自己組織化されたチーム… ... 32 , 132 ... 5 , 8 , 37 ... 151 … 148 … 148 … 128 … 270 … 218 … 67 … .203 … 1 開 … 91 , 137 , 141 … 238 … 27 ... 64 … 48 , 53 … 148 … 60 ... 8 , 15 … 56 … 135 … 134 … 196 … 214 … 70 … 172 … 69 … .203

4. アジャイル:ソフトウェアエンジニアリング

( 12 ) 序文 ロセスとツールがあります。しかし、本書でも触れているように、アジャイルの手 法を理解したり、プロセスやツールの価値を認識したりするのは開発者という「人」 です。本当に苦労するのは「人」の部分です。これまで 20 年間にわたって「リソー ス」として扱われる立場だったものが、説明力、創造性、責任感のある「人」とな るのは簡単ではありません。最初の難関は、開発者を管理する立場の人です。 VisualStudi02010 のツールで得られるメトリクスを、プロセスや開発者の一挙一動 を隅々まで管理するために使ったとしたら、創造性は少しも発揮されず、アジリティ がまったく上がらない結果に終わる可能性もあります。一方、同じツールのメトリ クスでも、開発者が直面している問題を理解するために使ったとしたら、開発者の 良き道しるべとなり、創造性と生産性をより高いレベルに引き上げることができる かもしれません。これはどんなツールにも共通する課題です。どんなに素晴らしい ツールでも、成果を上げられるかどうかは使い方次第なのです。 本書を書き上げてくれた Sam と Nen 。に心から感謝します。 Ken Schwaber スクラムの共同開発者

5. アジャイル:ソフトウェアエンジニアリング

100 5.1.1 第 5 章アーキテクチャ アの構成要素へと変換していく活動に焦点を当てることにします。この章では、アー キテクチャがいつどのようにして決定されるのかを詳しく説明し、併せて Visual Studi 。が提供するツール類についても説明します。 アジャイルコンセンサスにおけるアーキテクチャ アプローチの主な利点は次の 2 つです。 がきちんと機能し、すべての受け入れ基準を満たしていることを証明します。この PBI と必要なアーキテクチャをデリバリーすることによって、そのアーキテクチャ 価値があるものを提供しなければならないからです。各スプリントは、完了した スプリントはありません。なぜなら、すべてのスプリントは必ず顧客にとって直接 enough) 」のアーキテクチャを設計することです。アーキテクチャだけに専念する ムの「完了 (done) 」の定義に従って完了させるための「必要最低限 (just スクラムで求められるのは、スプリントの目標を達成するため、つまり PBI をチー ません。 うなフェーズ進行に慣れているチームの場合は、頭の切り替えに苦労するかもしれ を準備万端整える」という非アジャイル的な考え方とは大きく異なります。このよ 「実装作業を始める前にかなり長いアーキテクチャフェーズを設けてアーキテクチャ わりに、完了した PBI という形で価値を提供できることです。このプラクティスは、 スプリントで達成した価値によって測ります。最終的な目標は、各スプリントの終 アジャイルコンセンサスでは、成功したかどうかを各スプリントにおいて、その 検査と適応 : 創発的アーキテクチャ 者が日常的に行っているアーキテクチャ設計タスクに関係してきます。 したがってこの章の内容は、アーキテクトだけでなく、すべての開発者と、開発 せることで、最適な選択肢が浮上してくるのです。 設計上の 1 つ 1 つの問題に適したソリューションを選択します。集団の知恵を働か ム合意を形成します。チームは話し合いを通じて、考えられる多数の選択肢の中から、 に、 PBI を動作するソフトウェアに「どのように (how) 」変換するかについてのチー PBI を実施可能なタスクに分解するスプリント計画の前に実施されます。このとき ムがそれぞれの責任でアーキテクチャに責任を持ちます。最初の設計セッションは、 スクラムでは、アーキテクトという明確なロールは存在しません。代わりに、チー

6. アジャイル:ソフトウェアエンジニアリング

監訳者 序文 ソフトウェア開発に携わるすべての方に読んでほしい 本書は、アジャイルの概念解説書でもなければ、プラクティスやツールの技術解 説書でもありません。本書は、アジャイルプラクティスとソフトウェア工ンジニア リング環境をそれらの背景から必要性までを説き、さらに具体的な実践へ導く、今 までにない画期的かっ、現実的な書籍です。 アジャイルコンセンサスに触れ、スクラムを中心にアジャイルプラクティスを解 説しつつ、ツールを積極的に活用して、規律あるソフトウェア工ンジニアリングと して相乗効果を得る方法について的確に確実に学んでいただくことができるでしょ その意味で、本書はソフトウェア開発に携わる方、経営者、プロジェクトマネー ジャ、開発者を問わす読んでいただきたいです。本書は、それぞれの立場で読むこ とで、その立場だからこそ得られる気づきを得ることができるでしよう。また、開 発者ならば経営者の、経営者ならば開発者のといった異なる立場の置かれている状 況、あるべき姿を知るきっかけにもなるでしよう。 本書は、以下を漠然と考えている方にとって見通しを立ててくれます。 ・開発ツールを活用したソフトウェア工ンジニアリングの最新動向 ・アジャイルプラクティスとその活かし方 一個人とチームで相乗効果を得る秘訣 ・今求められている開発スタイルと現場の差分 VisuaI Studio 2010 をソフトウェア工ンジニアリング環境として採用している現場で 体的に手に入る開発ツールでの具体的な実践例が盛り込まれているのが特徴です。 特に本書は、概念を解説しているだけにとどまらず、 VisualStudi02010 という具 ■ Visual Studio 2010 の包括的かっ実践的な利用モデル

7. アジャイル:ソフトウェアエンジニアリング

第 6 章開発 いく方法について説明します。 この章では、読者が熟練した開発者であるものと想定しています。また、私がこ れまで出会ったほとんどすべての開発者がそうであったように、質の高い仕事がし たい、質の高いソフトウェアを提供することの妨害要因を取り除きたいと望んでい るものと想定しています。 126 アジャイルコンセンサスでの開発 早い段階で品質を確保するほうが、後でバグを取り除くよりもずっと安上がりだ ということは、 30 年も前からわかっています。・しかし、開発手法がアジャイルコ ンセンサスに移行し始めたのは、ほんの 10 年ほど前のことでした。アジャイルコン センサスでは、顧客が価値を認める成果物のみを評価します。これはつまり、顧客 に引き渡すのにふさわしい品質の、実際に動作するコードということです。スクラ ムではこれを「潜在的に出荷可能なインクリメント」と呼びます ( 図 6-2 を参照 ) 。 潜在的に 出荷可能な インクリメント ディリ スクラム 継続的 インテグレーション スプリント チェックイン レッド / グリーン / リファクタリング スプリント バックログ スプリントを通じて、チームはプロダクトバックログ項目を潜在的に出荷可能な インクリメントへと変えていく。それを達成するために必要なタスクはスプリン トバックログで定める。開発者は「レッド / グリーン / リファクタリング」のサ イクルを何度か繰り返して、コードをバージョン管理にチェックインする。 ② Barry W. Boehm, Software Engineering Economics (Englewood Cliffs, NJ: prentice Hall, 1981 ). △図 6-2

8. アジャイル:ソフトウェアエンジニアリング

細谷泰夫 ( ほそたにやすお ) TFSUG 認定スクラムプロダクトオーナー。 Agile Tour Osaka オーガナイザ、 実行委員。関西を中心にアジャイル開発コミュニティにて活動中。 柴山洋徳 ( しばやまひろのり ) Agile Japan 2012 株式会社 N 幵データ技術開発本部プロジェクトマネジメント・イノベーションセンタシニアエキスパート 認定スクラムマスター。 NTT データ認定プロジェクトマネージャ。社内のプロセス改善 Microsoft MVP for Visual Studio ALMO 開発プロセスごとの TFS の導入支援を行った TFSUG 和田宏之 ( わだひろゆき ) コンサルティングをしつつ、 TOC/CCPM とアジャイル開発の普及展開に従事。 杉本奈緒子 高橋伸輔 高田純 根岸睦 小室哲也 日本マイクロソフト株式会社 ケーション開発が最近の仕事。 認定スクラムマスター。 Microsoft MVP for VisuaI Studio ALMO TFS と Kinect アプリ TFSUG 中村薫 ( なかむらかおる ) り、 TFSUG にて各種登壇を行ったりといった活動を行っている。

9. アジャイル:ソフトウェアエンジニアリング

( 26 ) 著者の言葉 ているということでした。また、モデルでは開発、テスト、運用の重要な問題には 対処できませんでした。 いずれの場合も、点と点を結んでチームの全体像を把握することの難しさに苦労 しました。アジャイルプロセスの 1 つであるスクラムが提示した、すべての作業を 1 つの場所で参照できる「単一のプロダクトバックログ」という発想はすばらしい と思いましたが、当時実際に使用可能だったツール群では、作業はそれぞれの方法 でばらばらに分断されていました。この要求はあのタスクとどういう関係にあるの か、このモデル要素とは、あるいはそのテストとはどういう関係にあるのか、そし てそれに対応するソースコードはどこにあるのか こうしたことはまったくわか りませんでした。 歴史的観点から見ると、 IT は手動プロセスを自動化しようとする試みを中断し、 代わりに「自動化によって基幹業務プロセスをどう改革できるか」を問い始めた時 点で転機を迎えたのだと思います。そのときから IT は真のビジネス価値を提供し 始めました。 「靴屋の子供は裸足」 ( 紺屋の白袴 ) という諺がありますが、 IT の世界も同じです。 我々は、他人の業務プロセスの自動化にばかり取り組んでいて、自分たちの仕事の ことはほとんどないがしろにしてきました。 IT 従事者や IT チーム用のツールは、 今でもほとんどが古い手動プロセスを自動化したものばかりです。自動化する前の 古いプロセスの負荷は大きく、そして自動化した後もその負荷は大きいままです。 1 時間の予定のプロジェクトミーティングだったのに、始まってから 1 時間半は「誰 の数字が正しいのか」という議論に終始したという経験を何度したことでしよう。 Visual Studi 。を活用できる今、我々は真剣に問いかけています。「自動化によっ て基幹 IT プロセスをどう改革できるか。よいプロセスに従うことで、どのように 負荷を減らせるか。多様な役割それぞれの生産性を高めながら、パフォーマンスの 高いチームにまとめあげるにはどうしたらよいか」 ご覧のとおり、 このとき書いた内容は今でもそのまま当てはまります。 Neno LOje 私のキャリアの出発点はソフトウェア開発者でした。趣味で始めたものが仕事に なったのです。ソフトウェア作りが大好きになったのは高校に入った頃でした。自 分のアイデアを、他の人にとって現実的な価値があるものとして形にし、有益な何

10. アジャイル:ソフトウェアエンジニアリング

2.33 2.3.4 2.3.5 2.3 プロセスサイクルと TFS トの最終日は、レピューとふりかえりにあてられます ) 。これにより、スプリント期 間の 90 % がスプリントバックログの作業にあてられます。 ポトムアップサイクル リリースとスプリントという 2 つのマクロサイクルに加え、 TFS では、チェック インとテストという 2 つのきめ細かなサイクルを使用して、データの収集および自 動化のトリガーを行います。この方法により、 TFS はユーザー側の負担を増やさす に、「完了」の定義を自動化し、プロジェクトメトリクスを透過的に収集できるメカ ニズムを実現しています。 個人的な開発準備 詳しくは「第 6 章開発」で説明しますが、 Visual Studi 。は開発者に対して、テ スト駆動開発や、 IntelliSense による正しい構文への支援、ローカルビルド、テスト およびチェックインポリシーによるレビューによるエラーチェックを実践し、継続 的にフィードバックを得られる仕組みを提供します。これらは個人的な活動であり、 開発者がチェックインすると決めないうちに、 Visual Studio がこれらの活動から生 じたデータを収集することはありません。 チェックイン TFS がデータの収集やワークフローの適用を行う際に、その最も小さい単位とな るのは、チェックインと呼ばれるコーディングサイクルです。チェックインとは、 要するに、開発者が個人的なワークスペースから共有の分岐にコードを引き渡すこ とです。このサイクルは、きちんと動作するコードの「完了」を測定する最初の機 会となります。チェックインサイクルに対する最も一般的なアジャイルプラクティ スは、継続的インテグレーションという処理であり、チェックインが行われるたびに TFS のビルド定義に基づいてチームビルドをトリガーします。チームビルドは、す べてのコントリビューターのすべてのチェックインソースのうちで最新のバージョ ンを取得し、ビルドサーバーをプロビジョニングし、定義されたビルドワークフロー を実行します ( これには、コード分析、テスト環境へのデブロイ、またはビルド内 で定義されているビルド検証テストが含まれます ) 。詳細については、「第 7 章ビ ルドとテスト環境」を参照してください。