数年前、私は親relativeに会いに行きました。 私の貧しい従兄弟(そして彼は保険会社のCEOでした)が「アジャイルの特効薬」を販売しましたが、うまくいきませんでした。
これはすべてナンセンスです! 私たちは完全に異なるすべてを始めました。 コンサルタントを招待しました。 専任のプロジェクトマネージャーを採用しました。 うまくいきませんでした! 何も変わっていません。 誰も何に対しても責任を負いません。 言い訳だけを聞きます。そのとき何を答えたか覚えていませんが、今日はどう答えるか知っています。 私は一言でアジャイルに言及せずにいくつかの図面をスケッチしました。 私はいとこにいくつかの基本的な概念を説明する必要があります...
Alconostに翻訳
1.プロセス効率
まず、開発期間(アイデアが登場してからその実装が顧客に届くまでの経過時間)を見ると、ほとんどの時間が「待機」に費やされていることがわかります。 15%の効率 (実際の時間/開発時間)は正常です。 奇妙に聞こえますか? しかし、わかりやすいように見えるものを詳しく見てみましょう。時間のごく一部が実際に作業を行うために費やされています。 最高の企業の場合、この数値は40%に達します。 一般に、開発を高速化するには、「待機」時間を短縮する必要があります。
2.計画外の作業とマルチタスク
リソースの75%が計画外の仕事に行き、タスクを切り替えるときの一般的なこと。 チームは、これがまさに起こることだとさえ気付かないかもしれません。 これは文字通り「オーバーヘッド」であり、タスクアカウンティングシステムで追跡されることさえありません。 ほとんどの場合、チームはこの状況について不満を述べます(ひどく迷惑だからです)が、これらの不満を長い間無視すると、人々は悲観的な現実を当たり前のように思ってしまいます。
そして、これを社内の「結合されたサービス」の1つと考えてみましょう。チームは、既存の製品の問題を解決する(または新しいインフラストラクチャを展開する)と同時に、「プロジェクト」に取り組んでいます。 突然、ボトルネックがあります。
道徳。 計画外の作業の原因を検討し、「複合サービス」を提供することの経済的影響を計算します。 これらのサービスは明らかに理にかなっていますが、多くの場合、費用のかかる事前計画を要求します。
3.小、中、大
このような興味深いトリックがあります。プロジェクトの大、中、小の「作業要素」を達成するための期限をスケジュールに基づいて作成し、1つ上のレベルに進み、クライアントにとって(タスクではなく)実際の価値に焦点を当てます。 多くの組織では、作業の「量」が完了までの時間枠を決定しないことに気付くでしょう。 これは、他の多くの状況(依存関係、計画外の作業、多くの未完成の作業など)がタスクの期間に影響するためです。
4.商業的利益の実現
私が「配送リスク」と呼んでいるものを減らすために多くの努力が費やされています-これは注文時にプロジェクトを作成するときであり、クライアントは完成品の配送の事実に対して支払います。 SaaS(サービスとしてのソフトウェア)の場合、仕事が終わった後ではなく、私たちに支払われます-商業的利益は時間とともに増加します。 私はこれを「商業的利益のリスク」と呼んでいます(仕事が商業的に価値がないリスク)。
大規模な組織では、多くの場合、アジャイル開発の方法論を実装していますが、商業的利益の期待される増加を見ていません。 その理由は、開発はもちろん高速ですが、1)製品に関する正しい決定を下し、2)商業的利益をもたらすものの実装に取り組むことには影響しないからです。 アジャイル手法の全体的な感覚は、リスクの低減です。 プロジェクトの作業に関して、リスクは、スケジュールどおりに作業を実行し、指定された機能を提供することによって決定されます。 製品に関する同じリスクは次のように表されます。「このことは機能しません!」したがって、顧客は、商業的利益がない場合、特定の機能を「受け入れる」ことに同意できません。
多くの企業は、左に示すモデルを使用しています。 一部のモデルは右側にあります。 そして、作業の結果が悪臭を放つものである場合、彼らはシステムにより多くの作業を押し込もうとしますが、それは悪化するだけです。
5.手に負えない複雑さ
そして最後の1つ。 使い慣れたわかりやすい参照関数を使用して、製品開発システムに渡します。 複雑さの管理、リファクタリング、自動化の方法を使用しない場合、プロジェクト開発の年ごとに、開発チームが変更されていない場合でも、この機能を実装するのにより多くの時間がかかります。 確かに、以前は3日間かかっていたものに1か月半費やすことができるという事実に直面しています。
アジャイル
それでは、「アジャイル開発」について話しましょう。 アジャイル手法は、継続的な改善の触媒として機能しない場合は役に立ちません。同じことがスクラム手法とSAFeフレームワークにも当てはまります。 事実は、2週間ごとに「スプリント」を使用したり、「ユーザーストーリー」を記録したり、デモバージョンをリリースしたりすることが原因であるという事実です。 そして、上記は比較的小さな貢献をしていると私は主張することができます(これは、リスクを徐々に減らすという考えに着くと明らかになります)。
柔軟な開発方法論に従うことは、次のことに多くのお金と労力を費やすことを意味します。
- 本当に重要なことを行う(商業的利益)。 少ないこと。
- 自動化、ツールキットの展開、展開パイプライン、機能フラグなど(DevOps)。
- 管理文化を変える。
- 資金調達イニシアチブの改訂。 目標と目的に基づいた段階的な資金調達への移行、および資金調達プロジェクトの拒否。
- 複雑さの管理のためのリソースの割り当て(プロジェクトアーキテクチャの定期的なリファクタリングと改訂)。
- バリューストリームの分布とサービスエコシステムとしての会社へのアプローチ。
- 「複合サービス」の新しい理解。
「銀の弾丸」はありません-あなたは働く必要があります。 そして、そうでないと言う人に注意してください。
翻訳者について
この記事はAlconostによって翻訳されました。
Alconostは、 ゲーム 、 アプリケーション、およびサイトを68言語でローカライズしています。 ネイティブ言語の翻訳者、言語テスト、APIを備えたクラウドプラットフォーム、継続的なローカリゼーション、24時間365日のプロジェクトマネージャー、あらゆる形式の文字列リソース。
また、Google PlayとApp Storeの販売、画像、広告、教育、ティーザー、エクスプライナー、予告編のサイト向けに、 広告および教育用ビデオを作成しています。
詳細: https : //alconost.com