ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

マイクロソフトのALMつーかアジャイル対応をきいてきた

2014-11-17 17:12:21 | Weblog
Microsoftの

Architech Jumpup Start セミナー
今こそ考えるエンタープライズ向けアプリケーションのライフサイクル管理
にいってきた。

その内容をメモメモ




<<クラウド時代のアプリケーションライフサイクルを考える>>

■ALMおさらい
・Application Lifecycleの例
 ウォーターフォール
 V字型
 スパイラル
 インクリメンタル
・アジャイルソフトウェア開発
 短期間で価値のあるソフトウェアをお客様へ

クラウドコンピューティングのインパクト
・IaaSを導入した会社2013年から8.3ポイント→19.4
 (4000社のうち)
・新しいアプリはクラウドシフト(80%以上)

クラウド化のメリット
・フレキシブルな開発・テスト環境
・モダンアプリケーション基盤
・マルチOSサポート
・基盤セキュリティ
・ビジネスの変化にすばやく対応するITインフラ

■Cloid時代のALM
ビジネスの変化にすばやく対応するITインフラ
・サーバ0の購入、セットアップに数ヶ月
・クラウドで同じ環境を用意するなら1~2日

ビジネスの変化にすばやく対応するITインフラとアプリケーション
・アプリケーション開発は早くなっていない
Microsoftの事例
・Cloud時代のアプリケーションに必要なスピード感
  4にんづつ
  4週間ごとにクラウドに新機能
  年に一度オンプレミス製品に反映
・機能のアップデート
  2年→3週間へ
・12ヶ月でVSへの変更点

なぜ、アプリケーション開発にスピード感が必要なのか?
  ビジネス要求をタイムリーに反映できるITが
  ビジネスの差別化を推進
・IT部門より、高校生のほうが知っている
  でも、ビジネスは進む・・・
・ビジネスにフォーカスした戦略的なIT
  DevOps
 →何年も言われている=できてない
 運用の評価は可用性
 →共通ゴール:早くリリース・MTTRで評価
  成果物の共同所有
  自動化

DevOpsへの主な課題→いっぱい

成功するCloud時代のALM
  継続的デリバリー
  アジャイルな手法
  DevOpsをまわす

ALM:Application Lifecycle Management
  計画
  モニタリング
  フィードバック

テクノロジーが改善できること
 ・ツールを使って改善

DevOpsを可能にするテクノロジー
・仮想化、構成管理、リリース管理
・もにたりんぐ、分析、インシデント対応
・ビルド・測定・フィードバック:仮説主導型開発

事例紹介
・ソフトバンクテクノロジー
・日本郵政スタッフ
・ビービーシステム:人による品質のぶれがない
・富士通システムズ・ウェスト
  →3回繰り返すなら意味あり

何をするかを決めるのは、人

■今後のALM
・Cloud上で稼動するDevOpsが活用される
・Cloud上でのALM実践によりテストと本番が同一環境となり更新リスクが低減
・Dockerにより促進

Docker(Azureでもサポート)により促進されるもの
・軽量、移植しやすい
・オンプレでテスト、クラウドで運用
(公式な見解ではありません)

まとめ:クラウド時代のALM
・継続的デリバリー
・Agileな手法
・DevOpsをまわす

AzureとVisual StudioでDevOpsが現実解に





<<TFSスクラム開発とリリース管理を使えばRapid Releaseが行える>>

Online Service Gate
・クラウドサービスを利用するためのセキュリティゲートウェイ
・シングルサインオン

開発プロセスの課題
・Office365はrapid release
・世界標準の変化も早い
・開発スピードをあげる

従来の開発はウォーターフォール
・要件定義ですべてのタスクを洗い出し、WBSを作成
・ガントチャートで全員にタスク割り当て
・「イナズマ線」

ウォーターフォール
・はじめては弱い
・当初見積もりからぶれると、把握・調整が大変
・負荷高くなる、遅延?品質下げる・・・ことはできない

Rapid Release
・TFSをソースバージョン管理だけでなく
・タスク管理、工程管理も
 →スクラム開発を採用

■スクラム開発を採用
狙いは
・おおよそのスケジュール感はぶれない
・いち早く手が打てるように
・世界標準の開発経験を

ウォーターフォールの開発の流れ
・最初に全工程のタスクを決定
  PMが全体を見積もる
・事前に計画したスケジュールでタスク

スクラム
・バックログを決定
・タスクは週初めに、全員で見積もる
・週終わりにタスクが終わったか?確認

ウォーターフォールとスクラムの違い

TFSでスクラム開発はとても簡単
・定期的に意図を説明、慣れてもらう

TFSタスクボード、バーンダウンチャートでの確認

ルールを決めてスクラム開発にシフト
・なにをバックログ、タスクにするか
・リリースタイミングとブランチのルール
  ソースバージョン管理のルール

チームワークのためのコミュニケーション
・デイリースクラムを実施
・スプリント計画で全員で見積もる
・振り返りで改善する→時間を確保して、できるだけやりたい

・理解したところだけツールを使う

デプロイ
・バーンダウンするようになった
・ブレが小さくなった。見える化

見える化:知らないことには対応できない
メンバーのアラートに気づいて手を打てる
早く開発できるようになった

リリース管理を採用 Release Management

RM特徴は承認フローと配置の自動化
・ビルド定義
・リリースパス
・しシーステンプレート:リリースパス、配置処理
・リリース

複数のステージでワークフローを定義

配置をPowerShellでカスタマイズ

バージョン管理分岐に対応するには
・リリース用に分岐を作成する
  ビルド定義をリリース用に複製
・リリーステンプレートもリリース用に複製

速くリリースできるようになった
(上げる時間は変わらない)

問題
・TSSがサポートしていない部分
 ルールの明文化→教育十分:

リリース管理:範囲の見極めと承認フロー




<<クラウドへ向かうエンタープライズ開発者のための開発基盤入門>>
セッションの目的とゴール
Visual Studio Onlineを中心に

・アジャイル開発の価値提案
 可視化:アジャイル開発優位
 順応性:はじめは変わらないが、
 ビジネス価値:
 リスク:アジャイル→先送りしない

これからのALM
・ビルド、メジャー、ラーン
 ビジネスの仮説
 継続的デリバリー
・DevOps
 ALM+DevOps=モダンALM
・これからのエンタープライズ開発者の開発スタイル
  テスト/コードの作成
  ソースコントロールへのコミット
  サーバー側でのコードのコンパイル
  サーバー側でのテストの実行
  ソフトウェアパッケージの配置
  (あと1項目、メモ取れなかった)
・ALMとクラウド
 (すまん、ものすごい複雑な図で、メモすらとれん
  近くで、スマホで写真撮っている音が・・ ^^;)

・Visual Studio onlineによるクラウド上のALM

Visual Studio Onlineへのアクセス
・ブラウザからのアクセス
・作業項目の作成/変更について
  バックログの管理(Team Web Access)
  タスクボード
  チェックインポリシー

プロセステンプレート
  ・SCRUM
  ・CMMI
バージョン管理
  ・GIT
  ・TeamFoundation

バックログの調整
  バックログの入力
スプリント計画
  かんばん
スプリント続行
  バーンダウン

デモ
・バックログあたり
・ビルド&CI
・Azure Application Insight
  負荷テストできる(まだプレビュー)




あとでしらべる

Microsoft Architect forum2014 winter
この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« みんな道半ばで不安だらけだ... | トップ | 「IoTとは何なのか」一緒に考... »
最新の画像もっと見る

Weblog」カテゴリの最新記事