リーンスタートアップ とスクラム

リーンスタートアップ では素早く起業するためどのように進めれば良いかを唱えている。そのため方向転換とかできるようにアジャイル的な開発が適している。ここまでは納得できる。なので、スクラムはアジャイル開発プロセスの一つなので、リーンスタートアップ にあっているという論理もわかる。

でも本当にリーンスタートアップの開発をスクラムでやったほうがいいの？
一人の天才の下にサポーターを集めた外科医型でやるほうが開発は早いじゃないかな。少なくともMVPを作るまでは、
チームをスケールさせるにはもちろんスクラムのようなプロセスは役に立つと思うが

ウォータースクラムフォール

組織のアジャイル・DevOps度をアセスメントする質問に

Q 主要な開発方法論は何ですか？
　1.ウォーターホール
　2.ウォータースクラムフォール
　3.アジャイル

とあった。

ウォータースクラムフォール（Water-Scrum-Fall）ってはじめて聞いたので調べてみると

実用主義者が勝ったのか？Water-Scrum-Fallが一般的に

Water – 多くの場合はITとビジネスの間に行われる、前倒しのプロジェクト計画プロセスの定義
Scrum – 「Water」段階で最初に定められた計画全体を達成するための反復・進化型のアプローチ
Fall – 組織方針やインフラの制約によって定められる、制御された、頻繁でない本番リリースサイクル

日本だとエンタープライズアジャイルとか言っているに似ているような。

エンタープライズの領域は、いろいろ制約があるので、どこでもこうなるのかなと思った。

WebAPIのCSRF対策

Cookieベースの認証とかの場合にX-Requested-Withをつけるようなアイデアがあったのですが、
認証して利用するAPIだったらAuthorizationヘッダーをつけるようにすればそれでOKだよね。
Microsoft Graphもこのタイプ。

https://leastprivilege.com/2015/04/01/implicit-vs-explicit-authentication-in-browser-based-applications/

アジャイル＝スクラムで良かったんでしたっけ？

企業向けの開発でも最近アジャイルという言葉が良く出る。その際のキーワードの多くにスクラムが出ている。
スクラムマスター何人いるの？みたいな話もあり。アジャイル開発＝スクラム開発みたいになっている。
で実際にスクラムをやっているところもそれなりにあるみたいだけど、あまり上手くいっていない匂いがする。
理由はいろいろあるが、プロダクトオーナーが機能していないはかなり多いような気がする。あと、開発チームが受け身すぎ、責任とりたくないみたいな場合も多い。

アジャイルの反対の位置にはウォーターフォール（WF）があるので、WFからアジャイルへみたいな話が多いのだが、その間にはUPのような繰り返し開発がある。規模が大きく・作るものがきまっているような場合、こっちのほうが良いんじゃないかな

アジャイルは今はビジネス用語になって一人歩きしているので、アジャイルでやってと言われるケースがあるけど、やり方はスクラム一択ではないですよね。

くそストアドプロシージャ

ビジネスロジックを全てSQL Serverのストアドプロシージャで書いていてパフォーマンスがでなくて困っている話を聞いた。
どうも数千行のストアドで内容的にも分からないので、なかなか前に進まないらしい。
性能向上の第一歩は計測なのですが、その影響で性能が落ちるのが怖くて、本番計測も簡単ではないようです。

個人的にはストアドでビジネスロジックを書くこと自体受け入れ難い話なのですが、このような状況で対処するならどんな方法にするかなと

ここでの課題を並べると

・性能の計測が本番に適用できない
・パフォーマンスが出ない処理の特定方法が分からない
・でかいストアドに対する対処

性能の計測が本番に適用できない

これは性能測定をした場合の影響が小さければいいわけですが、どのくらいの影響がでるかが分からないレベルなんでしょうね
SQLプロファイラ（GUI）とかだと遅そうですが、その他にも選択肢はあります。以下の記事で様々な方法の比較があって、拡張イベントであれば10%程度遅くなりますが許容範囲のように見えます。

Measuring “Observer Overhead” of SQL Trace vs. Extended Events

トレースファイル：約20% 影響（遅くなる）
SQLプロファイル：約80％影響（遅くなる）
拡張イベント　　：約10% 影響（遅くなる）

パフォーマンスが出ない処理の特定方法が分からない

計測ができていてもその解析方法が分からないと前に進みません。特定のSQLであれば実行プランなどを見て改善できますが、問題になるSQL文やプロシージャを特定する必要があります。これらの絞り込みはSQL実行時間やCPUコスト、IOコスト、実行回数を調査することになります。

第4回 サーバートレースの解析方法

でかいストアドに対する対処

問題がわかってもストアドが複雑で単純には手を付けれない場合は、その複雑度を下げることを考えます。
リファクタリングが思いつきますが、ストアドのリファクタリングツールを探してみるといくつかあるようです。

SQL Enlightをみるとストアードプロシージャや関数としてT-SQLスクリプトをカプセル化するようなこともできるので、大きなストアドを機械的に分割しながら構造化して扱い易くします。

最後に

くそストアドプロシージャとの戦いはこれらの作業を繰り返して改善していくんでしょうね。
あと、データ分割して並列実行のアプローチ（ミニバッチ化）や、それをさらに小さくしてストリーム処理にしてしまうアイデアもありですね。

一番いいのは、くそストアドプロシージャに出逢わないことなんでしょうが

興味深いプラクティス

持続可能なソフトウェアとアジャイル

ガイドラインに書かれるのは、15行以上のメソッドを書かない、6行以上のコードを重複しない、自動テストのカバレッジとして90パーセントを維持するといった、ごく単純なことです。

将棋AIで学ぶディープラーニング

AlphaGoのディープラーニングの仕組みを詳しく説明してくれていてありがたい。

将棋AIで学ぶディープラーニング

将棋とかだと評価関数のパラメータ学習させるNNなんかを想像するけどCNNでやるんだね。
盤面や持ち駒の表現の仕方はこんな風にするんだと驚きました。勉強になります。
スパースなデータ表現をしてそれをCNNで特徴検出するのは案外よくやる手何ですかね。
強化学習のさせかたなんかも参考になる。