Wagileということばがある

Wagile
Google Translater →ワガイル
Bing Translater →ワジャイル

先週の記事で、ミニウォーターフォールについてしらべていたところ、Wagileという言葉を見つけました。Agileを称したウォーターフォールという意味のようです。

Wagileの語がある記事を抄訳してみました。

[あなたのチームは本当にアジャイルなのか、それともミニウォーターフォールなのか]
Is your team really Agile or mini Waterfall? 
Apr 26, 2016

自信をもってアジャイルしてます！という人たちは本当にアジャイルしているのか、じつはウォーターフォールなのか、それともWagileなのか。

ウォーターフォール；
単純なプロジェクトや、要件がわかっていて大幅な変更のない、重要な不明点がほとんどない場合に適している＊

アジャイル
反復的かつ漸進的に開発し、自己組織的なクロスファンクショナルチームがコラボレーションすることで、要件や解決方法を進化させながら進める。

ミニウォーターフォール
アジャイル的なプラクティスを採用しただけではアジャイルにはならない
リリース前に、全機能を統合してのテスト、業務に使う環境に配布するためのイテレーションが必要な場合はアジャイルの考え方に沿っていない。
そういうことをしなければならないのは、本質がアジャイルではなくウォーターフォールだからであり、せいぜいミニウォーターフォールまたは「Wagile」と呼ばれるようなものだ。

[スプリントは2週間のウォーターフォールではない！]
解決策を提示している記事も抄訳してみました。

A Sprint is Not a 2-Week Waterfall!
よくあるスクラムの質問の1つに次がある。
「どうすればスプリントを改善できますか？テストの時間が足りないのです。」
答えは簡単、スプリントをミニウォーターフォールにするのを止めることだ。テストはコーディング後に行うと考えているからテスト時間が足りなくなる。

例えば。4つほどユーザーストーリー（プログラムで実現すること）があるとして、４つそれぞれについてだれがどのストーリーを担当するか決める。その後、各自コーディングする、最後にテスターがテストする。

これだと、チームとして協力していない。一人で働いている。最後にテストするから最後になってリスクが顕在化する。しかし直している時間はない。
結局、古い習慣を短い時間でやっているだけだ。

これにはリーンが救いとなる。
もう少し健全なスプリントとしてはこういう形もありえる。
　２つほどのストーリーに、それぞれ複数の人が取り組む
　→ある人はテストし、テスト対象のストーリーをある人が開発する。
　　その中身は、ストーリー担当とデータ設計者がペアで設計し、
　　平行して、ある人は受け入れ検証の自動化を行うというもの

そのためのリーンの概念
　シングルピースフロー：
　　開始から終了をできるだけ早くする。
　　人が仕事を待つより、仕事が人を待っている状態にするのがよい。
　　それを実現するためのコンセプトとして次の３つを挙げる
　　・いっぺんにあつかうサイズを小さくする
　　　＝単位時間あたりに仕上げられる量を増やす
　　・並行作業を少なくすうｒ（WIP)＝ある道路を車４台が同時に走る
　　　より、２台のほうが事故が少ない
　　・群れ（徒党ではなく、なんとなく群れているのでもなく、魚群のよう
　　　な統制されたかのような動きがあるわけでもない、うじゃうじゃと
　　　群がっている感じの群れ）
　　　密接に協力する。ストーリーやタスクは個人のものではない。
　　　ペアプログラミングで協力、開発者とテスターが協力して適切な
　　　テストケースとテストコードを作る。群れで開発する。

どうやってウォーターフォールから脱却する？
　・共に働く。誰もが製品についてできるだけ多くのことを知るように、
　　頻繁にスイッチをオフにする（一つの役割やストーリーにのめりこませ
　　ない）
　・一度に最小数のストーリーに取り組む
　・1つのストーリーが終了するまで、新しいストーリーを開始しない。
　・スプリント開始後２～3日でで最初のストーリーを完成させることを
　　目指してください。
　・「進行中」（未完了）がたまってきたことリマインダーにして
　　デイリースクラムを行う

[反復開発が間違っていくーミニウォーターフォールというアンチパターン]
どんな理由でウォーターフォールが混ぜるな危険なのか記載のあるものも訳してみました、

Iterative Development Gone Wrong - The Mini-Waterfall Anti-Pattern
mar 18 2007

反復して行っていたとしてもウォーターフォールの要素を入れてはいけない
理由：
・テストの段階でようやくバグや結果が見つかる。直したり、スコープを
　調整したりする余地はなくなっている
・UAT（本当に使うユーザによる受け入れテスト）・統合テストにも
　テスト駆動を適用する。成果物を大きな塊にまとめてから統合テスト
　しなくてすむようににするためには、結局は、テストと品質管理を先に
　やらないといけなくなる

【雑感】
・「納期厳守」
こちらにあるソフトウェア管理の鉄の三角形の図が分かりやすいのですが、ウォーターフォールはスコープ=何をつくるか、を決めて、納期と予算を調整しますが、日本では原則、いったん決めたら厳守となります。要件定義前＝スコープが未確定なうちに決まったりします。
対してアジャイルは、予算か納期を決めて、どこまでの範囲を作るかで調整するものです。（納期がないこともあるようですし、ギリギリを攻めないこともあって、厳格な納期設定にならないので納期を固定化しないように見えるものも含まれているかもしれませんが)。

・「テストは前」
現在の、SIerやメーカーに一括受託する契約の慣習にのっとりながらアジャイルしようとした場合、ウォーターフォールを細分化したい発想はわからなくはないです。

ですが、テストを後にするのは破たんします（実体験）。
テストを後でやろうとすると、いろいろ弊害が起こって、テストコードを必ず書くという文化を作るのは難しくなると思っています。（前回テストプログラムと書きましたが、動くもののニュアンス強めがプログラム、書くもののニュアンス強めがコードと思っていただければと思います）

テストコードがあれば要件追加・変更時にそれをテスト・コードに反映して実行すれば、修正のないところは既存コードを実行するだけで確認ができる（そのためのテストコードでもある）のですが、手動実行で検証すると、全部手動で検証することになります。
また、テストを必ず書かないので、テストコードを書くことを前提とした見積もりが書けない、書いても精度も上がらない…



【小ネタ】
＊前記事の白書では、「高い品質と安定性が求められる大規模システムにおいては、引き続きアジャイル開発よりもウォーターフォール開発が適しているという見方がある。」とありますが、アジャイルサイドからは見方が異なります。またWindows（５千万行ともいわれる）のような品質と安定性が求められる大規模システムもアジャイルで作られています。

・昔は、大規模システムといえば、日本の民間企業であれば金融機関の勘定系などが挙げられていましたが、Googleなどは桁が違うようです。
（s銀行：Google＝2億行：20億行。後者はDevOpsなので更新量はこの比ではない）

・プロジェクトの三角形
Microsoftからプロジェクト管理の書籍はなんどか出ていますが、Webサイトにも記事があります。プロジェクト管理の世界だけでなく、政治関係でも鉄の三角形という言葉があるそうです

今回はここまで
(2020/02/09)