本セミナーはアプリケーションアーキテクト入門者用セミナーでした。
しかし、アジャイルの実現方法やALMの考え方など学ぶことが多かった。
以下メモ
○クラウド時代のアプリケーション ライフサイクルを考える
日本マイクロソフト株式会社 板倉真由美
・ALM：複雑で可視化しにくいアプリケーション・ソフトウェアの製造工程を標準化し共通するにより納期や品質の管理を可能にし、生産性を向上させることが目的
歴史は4，50年。職人芸ではなく誰でも近いレベルにしたい。
・アジャイル開発はクイックにユーザーの要求を以下に達成するか。
・クラウドを東証一部上場起動4000社のうちIaaSを導入済と回答したのは19.4％。2013年から8.3％
・新しいアプリの80％はクラウド上で開発されると予想している。
・クラウドのメリット
災害対策のデータバックアップ
フレキシブルな開発・テスト環境
モダンアプリケーション勤番
既存インフラ拡張
マルチOSサポート
基盤セキュリティ向上
・クラウド時代のALM
12か月でAzureの環境は大きく機能追加・向上した。
・クラウドでインフラをビジネスの変化に素早く対応
しかし、アプリケーションは早くなっていない。
・デイバリーサイクルは3週間で、3か月で新製品を提供する。
開発が早くなっただけでなく、開発のサイクルを回すことが大事。
・ビジネス要求をタイムリーに反映できるITがビジネスの差ベル化を推進するため、アプリケーションのスピードが求められる。
・DEVOPS：日々の業務、問題への視点、期間のプレッシャーの評価軸で考えても評価の仕方が違うため、目的が同じでもなかなか手を組むことができなかった。
・共通のゴールを持ち、お互いが見ることができ、追跡ができる成果物を共有し、なんでも自動でできるように必要。
・DEVPOSを実現するために人ではなく極力テクノロジーで解決する。
・テストの自動化は3回以上やると効果がある。
・ツールでは自動化できない部分は人で解決が必要。
例：課題の抽出、問題判別等
・Docker：非常に軽量。開発環境で成功したものをスイッチするだけで本番化できるようになるのが理想。
○TFS スクラム開発とリリース管理を使えば Rapid Release を行える!
～ Online Service Gate® クラウド サービスの開発事例
ソフトバンクテクノロジー株式会社 古賀 慎一 様
・Rapid Release：早くリリースすること
・Online Service Gate：クラウドサービス利用をするためのセキュリティゲートウェイ
・Office365と連携している。Office365が3か月でバージョンアップしているため、ついていかないといけない。
モバイルファースト、IoT
・今まではウォーターフォール
MS Projectでガントチャート、イナズマ線で進捗管理していた。
・ウォーターフォールは、
すでにやったことがある開発には強いが、初めてには弱い
見積もりから大きくぶれる
スピードを上げるにはマネージャにもメンバーにも負荷がかかる
・TFS、ソースバージョン管理だけだったが＋タスク管理、工程管理にした。
Microsoftが世界標準で提供しているので。
・スクラム開発を導入。
狙いは、多少の手戻り・未経験開発でもスケジュール・調整を簡単に、開発サイクル早くしたい、メンバー・マネージャの負荷を下げたい
・スクラムでは、バックログでやることを決める。おおよその見積もりをする。
週の初めにやるタスクを決めて全員で見積もり、週の最後に進捗確認。
1週間で大きく遅延が発生しているタスクは大きな問題が発生している。
全員で見積もるので、見積もりの精度が高い。
・TFSを使いながらスクラム開発を導入
最初はソース管理のみ
ウォーターフォールでタスク管理を導入しTFSに慣れてもらう
徐々にスクラムに切り替えていく
デイリーミーティング、見積もりポーカー
・タスクボード・バーンダウンでの確認で進捗・達成感を感じてもらう。
・毎週リリースルールにすると運用担当に無理が出る。
運用現場を状況を理解しながら、ルールを設定する。
・チームワークのためのコミュニケーション
デイリーミーティング：終わっていないタスクの問題に対応
・スクリプト計画で全員見積もる
全員で同時に見積もり結果を提示。違う場合に理由を認識する。
週次で振り返り・改善する。
・TFSの基本的な使い方から外れなければ、基本的な枠積みが崩れないように利用する。
特に目的・使い方を理解してない機能は利用しない。理解したものから利用していく。
・デプロイ・テストの課題。
最初は進捗の遅れなどが出たが、慣れてくるとバーンダウンするようになった。
見える化することでアラートに気が付き、全員が納得して対応ができる。
・早く開発して早くリリースするには、開発が早くなってもリリースする運用で遅くなってします。
・TFSでソースコードをビルドし、ビルドされたものはRelease Management Agentで配置する。開発者は承認フローを作るだけ。
・事前にビルド定義(どのソースコードをどこに出力する)、リリースパス(どういうワークフロー)、リリーステンプレート(リリースパスの設定と配置処理内容の決定)
・パッケージバージョンの確認→ステージング環境にデプロイ(PowerShellでAzureStagingに配置)→スワップでして動作確認する(スワップはPowerShellで、検証は自動)
・ダブルチェックに開発エンジニア複数名数時間アサインする必要がなくなった。
・開発・検証環境に何度でも同じリリースができるようになった。
・古典的アジャイル推進派・抵抗勢力がいる。
アジャイルは一部の天才しかできない・ドキュメントを作らない：等の誤解がある。
・ツールを使い慣れるまで時間がかかる。
・全員参加は時間かかりすぎでは？
・スクラム未経験者にはロードマップやWBSがないと進捗が分からない。
・CMMIテンプレートでは最初の見積もり時間実績時間がある。
スクラムテンプレートでは残り時間のみしか入力できない。
・ルールの明文化・意図の共有
TFSはすぐ使えるが教育には時間を十分にかけないとなんとなくやってしまう人が増えてしまう。
・どこまでやるか見極めが必要。
マニュアルとすべてやろうとすると疲弊する。無理をしないでやれることだけやること。
・リリース管理で理想的な承認フローはできない。
ちゃんと上長や運用を巻き込むこと。
0 件のコメント:
コメントを投稿