宣言の理解
from Manifesto for Agile Software Development
.4.
Responding to change over following a plan
より重きを置くのは、変化への応答
from Principles behind the Agile Manifesto
.1.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
ソフトウェアによる価値提供→顧客満足
.2.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
「要件の変化を歓迎する、たとえ開発後期であっても。顧客の競合優位性を高めるために、アジャイルプロセスは変化を駆動力とする。」
.3.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
CI/CDで当たり前の時代。浸透し切ったし、期間はもっと短い感じ
.7.
Working software is the primary measure of progress.
動くソフトウェアが第一の評価指標
.10.
Simplicity--the art of maximizing the amount of work not done--is essential.
日本語訳あんまり納得いってない (Twitterに対訳書いた)
解釈
Px: Principle x
Mx: Manifest x
変化
要件の変化を力とする (P2)。
変化を前提としないとこの文言は出てこない (稀な変化を重視するのは合理的でない)。
要件は環境の変化で変わる。要件は実装してみて明確になる。要件は運用してみて価値が分かる。要件は変わる。
要件が明確化することで変化した場合、明確化した要件に合わせればよい良いものが出来る。
実装して要件が不要なものだと判明したら、要件を取り下げればより良いものが出来る。
俊敏な変化は柔軟な強さの秘訣。
c.f. 変化ヲ抱擁セヨ
https://mobile.twitter.com/hiranabe/status/315435868057919488
http://objectclub.jp/community/XP-jp/xp_relate/xp-intro
要件
要件は道具。
要件を満たすことそのものは最優先ではない。最優先は価値提供→顧客満足 (P1)。
動かしたソフトウェア (P7) が顧客を満足させるか否かが最重要事項。
じゃあ道具たる要件の定義とは何か。
=> 明文化された、ソフトウェアに求められる要素。
要件=顧客満足に繋がり、明文化された、ソフトウェアに求められる要素。
でもリストアップしたものが要件か否か (顧客満足を生むか) は検証=運用しないとわからない。
=> “要件仮説”
仮説なんだから間違ってて当然。間違ってたら変えるのが当然。
仮説なんだから理解が深まったらより具体化して当然。具体化できるから仮説変えるのが当然。
なんかこう、requirementsって言われると、満たすべきもの・満たしたらOKって意味合いが凄い。
仮説に過ぎないんだから仮説って言ったほうがいいと思う。
software requirements for customer satisfaction
requirement hypothesis
仮説検証
c.f. 古典的な受託開発
要件を満たすことへ対価をもらうモデル.
要件が曖昧だと対価が曖昧になっちゃうので、要件はバッチリ決める必要がある。
要件仮説のはずなのに仮説を動かせなくなるため、仮説が間違ってたら悲惨なことに。
仮説を動かすためには対価を動かす必要があり、やれ契約変更だなんだと揉めるので、仮説なのに仮説を動かさないインセンティブが働いちゃう.
対価が曖昧: 「情シス: これくらいの修正は要件内でしょ」「ベンダー: いや、要件に無いもの足すのは新規見積もりを…」「いやいや」
c.f. コミットメント
