Q:

古い開発形態の改善

現在とある開発チームでWindows系のアプリのメンテ等を担当しているのですが昨今耳にするようなソフト開発形態と比べるとかなり前近代的な状態だと感じております。 
恥ずかしながら具体的には以下のような感じです。 
　コンパイラ：VS2012
　言語：C++(MFC)、アセンブラ
　ソースレビュー：しない
　バージョン管理ソフト：使わない
　テストコード：書かない
　バグ管理：Excel
開発が完了したソフトはWEBに掲載して顧客にダウンロードしてもらう形をとっています。 
なおソフトウェアの主な処理としては精密機器の制御や状態取得などです。 
現在の開発形態を改善することがミッションなのですが、とりあえず

Gitでのソース管理
コミットする前のチーム内でのソースレビュー
Redmineによるバグ管理

を段階的に行っていこうと考えております。 
ただ私はこれまで他のソフト開発の職場で働いたことがなく「普通はこうする」や「最近はこういう風に開発する」のような勘所がわからないため、この方向で良いのか、更にもっと良い方法があるのか不安です。 
以上を踏まえて質問ですが、

何か上記以外で改善できそうなポイントはありますでしょうか？ 
開発手法関連で色々調べているとDevOpsという言葉を頻繁に耳にしますが、開発完了したソフトは運用チームに運用されるようなものではなくそのままエンドユーザーの環境にインストールされるだけですのでDevOpsやそれに関連したツール（Jenkins, Kubernetes等）は私の開発チームには馴染まないと思っていますが、そういう理解で合ってますでしょうか？ 

アドバイスいただけると助かります。 

A:

漠然とした質問ではありますが、私も感ずることがあるので要所要所を回答します。 

上記以外で改善できそうなポイント

あなたの組織のものさしは、何でしょうか。 
まずはここを何でも良いので定義しましょう。それを改善する手法を考えます。 

ただ私はこれまで他のソフト開発の職場で働いたことがなく「普通はこうする」や「最近はこういう風に開発する」のような勘所がわからないため、この方向で良いのか、更にもっと良い方法があるのか不安です。 

不安があるということは、目的が不明確またはそれを達成できる裏付けが足りないということです。いざ説明しようにも説得力が欠けてしまいます。 
「普通」や「流行り」で通用するなら、とっくに「普通」で「流行り」の開発スタイルになっているはずです。 
ご自身の組織にどう良い事があるのかきちんと説明できないと、難しいと思ってください。 

開発手法関連で色々調べているとDevOpsという言葉を頻繁に耳にしますが、

DevOpsなどを採用するチームが、なぜそうしているのかを勉強すべきです。合わないだろうとお感じのとおり、全然別の目的だったりするのではないかと思います。 

ソースレビュー：しない
  バージョン管理ソフト：使わない
  テストコード：書かない
  バグ管理：Excel

これで仕事が回ってきた理由を分析しましょう。属人化とか色々なキーワードが出てくると思います。 
そのキーワードを改善する必要性があるか（マネージャーが喜んでくれるか）、改善するにはどういう手法があるのか、どう説得するか、1個ずつ組み上げていくのが現実的です。 
簡単なところでは、

課題管理システムを導入する　（脱Excel、共同作業しやすい！） 
バージョン管理ソフトで変更履歴の管理を任せる　（手作業で変更履歴残すの面倒だよね！間違えるよね！） 
上記2個で、課題に対する変更を紐付ける

これらだけから始めても良いと思います。