Open
9

Agileでのソフトウェア開発

GitLabの管理方法

進捗管理

要求の管理

  • エピック

    • Epic機能を利用して、複数のFeature(User Story)を取りまとめている。(Support multiple, automated Iteration Cadences)
    • エピックの中にはマイルストーンが異なる(リリースタイミングが異なる)Feature(User Story)が入っている
  • Feature

    • 個別のIssueが対応する(Match existing users to Epics)
    • IssueにはProblem to SolveProposed Solutionで要求事項と解決方法が記載されている(大抵のケース)

アジャイルの目的

背景

プロジェクト型からプロダクト型への変化

  • プロジェクトマネジメントとProductManagementの違い

    • プロジェクトにおける最大のリスクは終了しないこと、プロダクトは終了すること
  • 様々な競合製品や競合サービスのある中から、「目まぐるしく変化する市場環境や顧客ニーズに答えていく」という要求に応える必要がある

  • これによって、ソフトウェア開発の前提がプロジェクト型からプロダクト型へ変化していく

  • こうした前提の変化に従来の計画駆動型の開発は限界を迎え、アジャイルが導入された

不確実性の

Cynefinの5つの分類

多くのソフトウェア開発のプロジェクトや活動は複雑系に分類される。そして、複雑系はアジャイル開発と反復型開発の領域である。プロジェクトの大部分が複雑系に含まれる場合、実際にうまくいくアプローチには実験が組み込まれていなければならず、問題を完全に定義するには調査が必要となる。
More Effective Agile “ソフトウェアリーダー”になるための28の道標

複雑系に分類される問題が増えれば増えるほど、アジャイルを導入する効果が

プロジェクト管理の基本

ユーザ目線で見た価値で要求を管理、チームのパフォーマンスを計測する

ユーザーストーリーの活用

ユーザ目線で見た価値で要求を管理するという点で、アジャイルのプラクティスとしてユーザストーリーを活用する

ベロシティによるチームの生産性の計測

チームがユーザ目線で見た価値をどの程度提供することができているのかベロシティという指標で計測、管理する。

ふりかえり

レトロスペクティブのテーマ

  • プロセスとプラクティス
  • コミュニケーション
  • 環境
  • 作業の成果
  • ツール

品質管理の考え方

不確実な状況や不確実な問題に対して柔軟で臨機応変に対応できる組織を作ることがアジャイルの考え方。

これを品質面で考えると「まだ見つかっていない欠陥ができるだけ少ない状態」こそが柔軟に動くために必要

欠陥の挿入

  • 欠陥は開発チームが作業をすればするほど紛れ込む
  • 挿入されてからまだ見つかっていない欠陥(潜在的な欠陥)が多ければ多いほど、後からバグフィックス
    等追加で必要な対応が発生し、予算とスケジュールに更なる不確実性をもたらす(予測不可能なスケジュールの変更や対応費用の増加が発生し、臨機応変に対応できる状態から離れていく)
  • また単純に欠陥は挿入されてから検出/除去するまでの時間が短ければ短いほど、効率的に対応できる
  • 上記より欠陥が挿入されてから即座に修正されるプロジェクトの方が効率的と考えられる

潜在的な欠陥を最小限に抑えるプラクティス

以下のプラクティスを組み込む。

  • ユニットテスト
  • ペアプログラミング
  • 静的解析
  • コードレビュー
  • 継続的インテグレーション

完成の定義の活用

完成の定義を活用することでQA作業をあらゆる作業と結びつけることが可能となり、それにより潜在的な欠陥を減らすことができる。

以下はMore Effective Agileより転載した完成の定義の例だが、開発を伴う作業にこれらの定義を適用すれば(またはCI等で自動でチェックするようにすれば)、検出、対処が可能な欠陥を増やすことができる。

  • コードレビューを通過している
  • 静的コード解析を通過している
  • ユニットテストがエラーなしで完了している
  • ユニットテストによるステートメントカバレッジが70%以上である
  • システムテストと結合テストが完了している
  • 自動化した非機能テストがエラーなしで完了している
  • ビルドした時にエラーや警告が出ていない
  • パブリックAPIが全て文書化されている

DevSecOps

これはセキュリティに関しても同じことが言える?
DevSecOpsでよく聞く「シフトレフト」(セキュリティを左に)もセキュリティに関する保証を開発プロセスの中に組み込むことで、欠陥の検出をできるだけ早くするという点では同じこと?


Shift Left: The Rise of DevSecOps

参考資料

テスト戦略

以下はテスティングピラミッドというもので、それぞれのテストについて上に行くほどコストが高く、下に行くほどサイズが小さいことを示しており、自動テストの割合をこれぐらいにすると効率的なテストが行えるというプラクティスを示している。

もちろん、すべてのプロジェクト、すべてのシステムで同じ割合が最適なわけではなく、プロジェクトによっては全く逆の割合が効率的ということもありうるが、どういった種類のテストをどのぐらい実施するかという戦略を考える上で参考となる。

また、同様の概念にGoogleが利用しているテストサイズがあり、以下の表の通り実行時間や外部依存性の利用に応じてテストサイズをSmall, Medium, Largeに分類している。

Feature Small Medium Large
Network access No localhost only Yes
Database No Yes Yes
File system access No Yes Yes
Use external systems No Discouraged Yes
Multiple threads No Yes Yes
Sleep statements No Yes Yes
System properties No Yes Yes
Time limit (seconds) 60 300 900+

Googleのテストサイズはテストの種類だけでなく、開発フローの中でどのタイミングでどのテストを実行するかという戦略を考える上で参考となる。

例えば、実行に時間のかからないSmallテストはプッシュの度に実行して開発者ができるだけ素早くフィードバックを得られるようにし、比較的実行に時間のかかるMediumはマージされるときに実行など、実行時間に応じて開発フローの中に効率的にテストを組み込むことができる。

プロジェクトへの適用

前述のテスティングピラミッドやテストサイズの考えを参考にプロジェクトの性質や言語ごとにどのようなテスト戦略を立てる。

また、テスティングピラミッドには含まれていなかったが、マニュアル(人手)でのテストが必要な部分ももちろんあるので、開発フローや継続的インテグレーションの検討と合わせてどのタイミングでどういったテストを実施すれば効率的かを考慮して決定する。

自動テストの意味

QAプロセスの効率性を挙げ、人為的なミスを減らせる

問題は、これらのテストが反復的な作業であるということです。先ほどの簡単な例でも「対象の項目をクリックして」、結果を「確認する」プロセスが何度も繰り返されていますね。このような反復作業を毎回手動で行うと、アプリケーションが複雑になるほど、テストに対するコストが増大します。テストコストが増加することでテストが疎かになり、最終的にはアプリケーションの品質低下につながることがあります。またコードを変更する度に、関連機能をテストする必要があるため、その負担からコードの改善を妨げ、コードの品質を低下させることもあります。

このように、繰り返し実行されるテスト作業をコードで作成して自動化すると、テストに対するコストが減り、テスト漏れや誤った検証などのミスを防止することができます。また、コード修正の不安がなくなり、積極的にリファクタリングができるようになります。これはすなわち、コードの品質向上につながります。

フロントエンド

開発フローの作成

基本的な方針

  • まだ見つかっていない欠陥ができるだけ少ない状態を保つ
  • 開発の生産性は担保できるようにする

後者についてはいくら品質面が担保できていていも、例えば毎回コミットやPushの度に30分以上時間がかかってしまっては生産性が大きく損なわれてしまう。

そのため、実際に開発のワークフロー(CIの構築を含む)を作るときには単に品質面だけでなく、生産性とのバランスを考える必要がある。

ここで重要になってくるのがテスティングピラミッドの考え方で、基本的にサイズが大きくなるほどテストの実行に時間がかかる。時間がかかるテストを毎回実行していては生産性が損なわれるため、後回しにするなどの考慮が必要になる。

上記から考えると、開発フローの構築にあたっては

  • プロジェクトや技術的な特質を加味した上で適切なチェックを適切なタイミングで実施し、適切なフィードバックを返す

ことが必要になると考える。

適切なチェックとは

適切なタイミングとは

適切なフィードバックとは

コードレビューまでに実施(Push時 or ローカルコミット前など)

  • 静的解析
  • 自動テスト(単体、結合)
  • コード品質
  • セキュアコーディング

マージ後(コードレビュー後)に実施

基本的にテストの対象はデプロイ後のリソース。
ステージング環境等にデプロイ後、システム全体の挙動に問題がないか確認する。
目的としては以下2点。

  • 欠陥が挿入されてから検知するまでの間を短くするため
  • より実際の環境(本番環境)に近い状態での検証を行うため

実例

実際に使用できる機能

フロントエンド(JavaScript(React))

テストの種類

SAST: Static Application Security Testing(静的セキュリティ検査)
ソースコード自体を解析・検査して脆弱性を見つけ出すもの
動くコードになる前の段階から使用できる
DAST: Dynamic Application Security Testing(動的セキュリティ検査)
動いているアプリケーションに対して様々な入力を与え、その結果をもとに脆弱性の有無を判断する
ブラックボックステストなので網羅性には欠ける
IAST: Interactive Application Security Testing
SASTとDASTの双方のメリットを兼ね合わせた手法
まずDASTで検査を行い、疑わしい部分をSASTで解析する

バックエンド(Python)

  • flake8
  • black
  • radon
    • Cyclomatic Complexityなどのコードの品質に関するメトリクスを測定する

参考資料

Pythonコードの安全を保つSAST(静的解析)ツール ~Bandit, Pyt~

計測

  • チームの生産性を上げたい、ソフトウェアの品質を上げたい、顧客満足度を上げたいといった改善を行おうとするとき、まずは計測対象の値と測定方法を考え、何かしらのアクションを取り、効果を検証するのが基本的な流れ(測定できないと改善したか把握できない)
  • ただし、データ分析等の文脈でもよく語られることだが、クオリテイティブ(定性的、Quantitative/定量的の逆)な側面も無視するべきではない

計測対象

  • 作業の量
    • ストーリーポイントを使って計測
    • チームのパフォーマンスとしてベロシティを計測
    • チームによっては進行中のプロジェクトに対して作業が追加されるペースを表すスコープベロシティも計測する
  • 作業の品質
    • 手戻り率を計測する
      • 手戻りに投入する作業と新しい開発に投入する作業の割合を示す
      • ストーリーを新しい作業か手戻り作業に分類することで、全体のストーリーポイントの総量から手戻りのストーリーポイントの総量で計算できる
      • 手戻り作業にストーリーポイント割り当てないという方法を取ることもできる

参考資料

ログインするとコメントできます