「ウォーターフォール型の開発とアジャイル型の開発は正反対」ってどうよ

えっと、朝からとても「そだねー」と虹彩がなくなってしまうのですが。

 

PMBOKガイドでのアジャイルの記述の強化について、アジャイル開発を数多く手掛けている専門家に意見を聞いてみた。すると、「PMBOKのやり方でウォーターフォール型の開発を手掛けていたプロマネに、アジャイルは無理」と断言した。いわく、「ウォーターフォール型の開発とアジャイル型の開発は正反対だからだ」という。

 

tech.nikkeibp.co.jp

 

そういう(=プロマネとし柔軟性のない)方もおられるんですね…。そうおっしゃるなら仕方がないですね。ずっとウォーターフォール型のシステム開発で。

 

身の回りの範囲ですが、知り合いのプロマネと会話したときは、ウォーターフォール型のプロマネの経験があるからこそアジャイル開発ができるよね、という共通見解になりましたけど。

ウォーターフォール型とアジャイル開発の共通項

ざっくり書けばウォーターフォール型のシステム開発はこんな感じです。

 

f:id:fumisan:20180302075156p:plain

 

要件から機能仕様を決めて、コードを書いて、テストしてリリースです。それをプロジェクトの特性からもっと詳細に工程を分割したりするわけです。

 じゃあ、アジャイル開発はというと、

f:id:fumisan:20180302075200p:plain

スプリントの前にプロダクトバックログとかスプリントバックログで何をどう作るか決めて、スプリントの中ではパッと作るわけです。同じようにコードを書いて、テストをしますから、コーディングも機能検証もやります。ものづくりですから。一週間のタイムボックスの中でとかで。

 何を作るかという仕様を決めるという活動、実際に動くものを作るという活動、そして、作ろうとしたものが機能を備えているかを検証する活動は共通なのです。

#図にはPBLとかSBL決めは描いてませんけど。

やり方は違うけど本質は同じ

 プロジェクトの特性が違うからそれに見合う道具が違うんです。短期間なのに悠長にやってられないから機械でできることは(設定はするけれど)機械に任せて、エンジニアがやらなければならないことを集中してやるだけです。

 

 

 

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方