#NagoyaAgile 勉強会「ALMとは？開発完了で終わりじゃない、アプリケーションの一生を追え！」に行ってきました
TFSの存在を教えて頂き、運用について何度も助けて頂いた長沢さんこと、@tomohn さんが名古屋でALMについてお話されるという事で名古屋アジャイル勉強会に初めてお邪魔しました！正直、デブサミの時にお話頂いた内容がイマイチ理解できていなかったので今回の機会は大変助かりました。スタッフの皆様ありがとうございました。
今回の目的
- ALM（Application Lifecycle Management）についてビジネスとどう絡めて説明しているのか理解する
- 長沢さんにお会いしたかったｗ
Visual Studioプランニングポーカーは出荷判定NGで配布されないことにｗ もったいない！長沢さんも言ってたけど良い紙だ！欲しいなぁ。。
自分なりの理解でのまとめ
ビジネスは競合他社との競争に勝つため、生き残るためにシステムを強化しなくてはいけない。そのため。Agility(素早さ)が求められている。だけど、開発が素早い変化に追いつかず、アジャイルな開発が求められている。アジャイルな作り方の Framework として Scrum が存在している。そのScrumを保管するため、ALMを利用し報告と作業完了と同一の作業としてWork-in-Process(作業の切り替えに必要な事、作業以外の事)などの無駄を取り、ノウハウを蓄積する事で Agile な開発が効果を一番発揮するスクラッチ開発、新しいビジネスの開発への予測立てやすくする。ALMは管理をしやすくするためではなく、開発者が「開発」に専念するためのツールである。
感想
ディスカッションをしていて概念的で理解が難しい今回のお話でしたが、TFSを利用していたのでイメージがしやすかったです。透明性についての気づきとしてプロジェクトの進捗（量）の透明性は実績の入力をメンバーに依頼すれば作業コストはかかるけど管理できる。だけど、ソース（品質）の透明性は管理しにくいというか透明性を考えた事もなかった。レビューでの指摘事項で「品質が悪いかも」はやってきたけど。。
あと、スクラム認定マスターを取得したいと強く思った。会社からちゃんと研修として受けたい。
以下、長沢さんの発表でのメモ。
# は自分の心の声です。
- ALM Communities
- ALM != Tools
- ALM != 束縛と監視
- # 確かに強制されている感はあるかも
- ALM != 開発ライフサイクル
- ALM != 管理職が楽をする
- ALM はお客さんと開発者のためのもの
- ALM = 企業戦略（ビジネス）
- 統制
- アイデア→展開(deployment)→廃止（EOL）
- ビジネス開発
- ポートフォリオ（PPM）
- ライフサイクル長い。というか最大。
- 開発
- 新規は、業務ケース作成→展開まで
- 保守、拡張は最後まで
- ビジネス開発に参画できていない
- 運用
- 展開されてから廃止まで
- 開発だけではすまない。
- What's Business
- ビジネスの現状
- '90s
- 便利
- ビジネスの外
- '00s
- 有効
- ビジネスの一部
- '10s
- 不可欠
- ビジネスと融合
- 競合他社に対抗するため、ビジネスを変えていかなくてはいけない
- ビジネスにITは振り回される
- # ビジネスもＩＴに振り回されるよな。。
- 開発のアジリティ
- 昔はゆるやかな開発
- 価値提供まで長い時間がかかる
- 今は、
- 価値提供の単位は昔より小さいが、短い感覚
- What's AppDey
- COTS Commercial off-the-shelf
- 既製品のこと
- ERPなど
- 基礎体力、負けないために
- 他社実績があるものを入れる
- App Custom Application
- 勝つ、差別化、ビジネス強化
- 価値創造
- 前例がない
- ビジネスとアプリケーションの融合は、当然、Custom Application
- Agility
- ビジネスは変化を受け入れなければいけない
- 俊敏に順応
- 競合優位性
- 価値の最大化
- アプリケーションはビジネスに貢献しなくてはいけない
- Just-inTimeに提供
- Feedback Loop
- Agile
- ビジネスのAgilityに追いつく早い開発をしなくてはいけない
- Agility Framework
- Plan
- Do
- Management
- ナレッジを活かす
- ビジネスのための基礎体力づくりがALMに求められている
- 透明性
- 忙しい、暇
- 成功ノウハウの横展開
- # この辺はうまく理解できなかった
- the Rights thing
- # 正しく作る
- ビジネスアイデアを動くソフトウェア
- 過去の経験を活かす
- the Right way
- # 正しい方法で
- 変化への柔軟かつ確実な対応
- built Right
- #正しく作ること
- デリバリーの最適化
- 継続的デリバリー
- PEOPLE
- 経験、ナレッジ
- 不足→未成熟
- PROCESS
- プロセスがない無秩序
- TECHNOLOGY
- 行き詰まり
- ビジネスのスピードは早い
- 技術のサポートがなしでは、Business Needs を Value にできない事がある
- Traditional Planning
- 時間と価値がわかる→定義されたプロセス
- # バリューが最初に高いのは設計、しているから
- # 最後に価値が発生するイメージなんだけどな
- Agile Planning
- 時間と価値が不確実→経験的プロセス
- Reduce Waste
- 無駄を省く
- 技術負債
- 無駄な動き
- その代わり
- 価値の流れを得やすくしている
- Unnatural Flow
- お客さんからすると、フィードバック（バグ、Enhancement）を開発者がすぐにdeliveryしてくれるとおもっている
- Continuous Delivery
- # あの輪っかが。。絶対使うぞー
- この価値を提供するものを意識していかなくてはいけない
- この３つがビジネス価値をつくるために重要
- 透明性
- Value of Flow
- Reduce Waste
- ALMとは？
- 改善Framework
- 価値の最大化
- Scrum はビジネス価値を生むには最適
- Scrumが更に必要なこと
- 経験を蓄積しやすくすること
- 透明性を把握しやすくすること
- バーンダウンチャートなどがある
- → これをALMがサポートする
- コードの透明性も
- ビジネス要件の漏れの透明性も
- Continuous Feedback
- 開発と運用
- 継続的ディバリーの更に先にいくこと
- Traditional ALM
- プロセスごとに人が違っていた
- それぞれのプロセスをツールは別々で独立管理していた
- 要件
- 分析、設計
- 開発
- テスト
- 開発者は、それぞれのツールを見にいかないといけない
- バグ管理、ソース管理
- その結果、バグ、ソース、要件などの紐付けは頭の中でやっていた
- # 確かに、一時期各変更に運用バグ番号、要件番号をつけようとしてたな
- Agile ALM
- 一人で全てのプロセスをやらなくてはいけない。
- 情報Hubを用意
- 本業ではない、紐付けなどに時間をかけていた
- 技術的には可能になっている
- ALMは本業以外のことは全てツールでやる
- 本業に専念する。
- # 初めてTFSの話を伺った時も、開発者が本業に専念することがあるべき姿とお話していた
- Traditional ALM
- ツールの行き来する
- 開発者も管理者も
- Agile ALM
- 目的関心ごとに最適化
- チーム生産性向上思考
- 情報Hubによる強調作業
- 特定のプロセスに依存しない
- Work in Process が短くなる
- 終わった事を通知するだけ。
- 情報Hubを解して状況確認、アサイン、進捗確認ができる
- # 管理表を記載するのではなく、本来は相談すること、解決する事に注力したいよね。
- Natural Reporting
- # メモ忘れた
- 仕組みに任せていき、能力を引き出す
- # ALMが下支えという意味がわかった
- ALM is 勝ち得た予測可能性
- ノウハウを蓄積することで、不確実性を予測することが可能になっている
- まとめ
- ビジネス戦略としてのALM
- Agile Consensus をサポート
- 自然なソフトウェア開発のプラットフォームはもうある
- 自分のチームでのディスカッション
- 製品開発なので、ビジネスとの関わり合いのイメージがない
- ALMというツールを利用するにもツールの理解、習得、意識付けが必要であり人に依存する。
- 全員同じ方向を見ていないと難しい（長沢さん）
- ただ、利害関係者（ビジネス、マネージャー）が多いため同じ方向を見るのは難しい。（長沢さん）
- Value ☓ Time のグラフの曲がり方が理解できない
- 費用対効果で見ていただくといいらしい！（長沢さん）
- 透明性の把握は、少人数だとあまり必要ない
- ツールより重要なのは人ではないだろうか
- デスマーチは透明性が確保されていない。助けるに助けられない。
- 自分の話した話
- ビジネス要求にシステム開発が間に合わなかった
- 透明性はぎりぎり手伝っている
