【備忘録】 アジャイル開発基礎
うぃろぅです。
なんだか久しぶりになってしまったe-ラーニング備忘録、続けていきます。
来週当たりからiOSアプリのプロジェクトに携わることになりそうなため今週で最後かも。
今日のテーマ
アジャイル開発 基礎編
アジャイル開発の歴史
- 2000年ごろ~
ソフト開発現場でブーム
2001年に「アジャイルソフトウェア開発宣言」がまとめられた - 2010年ごろ~
クラ独活サービスの隆盛とともに再注目
開発技術の進化により環境が急速に整備され、期待が高まった
まずはこれを読もう。
最近のキーワード
- UX
ユーザーエクスペリエンス。良いユーザー体験のためフィードバックが重要。 - リーンスタートアップ
小さく作ったものを育てていく。最初のハードルを下げることが重要。 - DevOps
Development Operation の略。開発しながら運用していく。
某社のアジャイル開発の取り組み
社名を出していいのかわからないのでぼかす。
歴史のお勉強。私が所属している会社ではないため「そうですか」という感想。
アジャイル開発とは
設計・製造・テストを細分化することによって短いスパンでのリリースを継続してサービスを育てていく開発手法。
twitterでいえば
- つぶやく
- フォロー
- 画像添付
- 動画添付
- ライブ放送
のように優先順位をつけ、絶対に必要な機能を作った後で順次追加機能をリリースすることを続けていく。上記はただの例のためフィクション。
(フィードバック)・設計・開発・テスト・リリースの1サイクルを「スプリント」「イテレーション」と呼ぶことがある。
ユーザー部門と開発者が協調することが重要。そのため、「お客様の声」は大事な資産となる。同じ部署内でも連絡は密に。
アジャイル開発手法
- リーンソフトウェア
考えかた。先述。 - XP
- スクラム
キーワードはこの3つ。順に見ていく。
リーンソフトウェア開発
コスト・納期を固定してスコープを可変にする
「この期間でこのコストならここまでなら作れます」ということ。ログインとツイートはできるけど検索はまだ実装しないよ、とかそういうこと。
7つの原則
- ムダをなくす
価値を見る目を育てる必要がある - 品質を作りこむ
開発しながらテストして品質を高める。レッツTDD。 - 知識を作り出す
自分たちのプロセスを改善していく。暗黙知を作り出そう。 - 決定を遅らせる
正確な情報を得てから本採用をしよう。 - 速く提供する
速く出して速くフィードバックを得ると素早く次に移れる。 - 人を尊重する
それはそう。 - 全体を最適化する
全体で見て整合性を図る。「図る」なのか「とる」なのかちょっとわかっていない。日本語難しすぎやしないか。
7つのムダ
- 在庫のムダ
リリースしていない作業(在庫)に意味はない。 - 作りすぎのムダ
余計な機能を作ってもどうせ使わない。 - 加工そのもののムダ
再学習のムダ。知識や経験をプロセスに組み込むべき。 - 運搬のムダ
引継ぎのムダ。伝わりやすい手法、ドキュメントを模索するべき。 - 動作のムダ
タスク切り替えのムダ。マルチタスク、できねえよなあ。 - 手持ちのムダ
遅れのムダ。ボールはすぐ投げよう。 - 不良を作るムダ
読んで字のごとく。どんどんテストしよう。
スクラム
「共通のゴールに到達するためにチームが一体となって働く」という方法論。
- プロダクトオーナー
- スクラムマスター
- 開発メンバー
のチームで構成されている。
5分でわかるシリーズ。5分ではわからなかった。つらい。
こうも「スクラム」という単語を見るとラグビーワールドカップを観たくなる。
そういえば今度携わることになりそうなプロジェクト、ラグビーワールドカップに間に合わせたいらしい。あと3ヶ月もなくない…??
準備計画
準備が大事。1ヶ月程度とって認識をあわせる、ということが重要となる。走り出したら止まらねぇからよ…。
- インセプションデッキ開発
プロジェクトの全体像を伝えるためのドキュメント一式のこと。バトルが始まったりはしない。認識のズレによってはバトルがあるかもしれないが、これはそれを防ぐためのもの。
テンプレート例。上手く活用しよう。
XP
eXtreme Programming の略。ライブはエクストリームスポーツなので似たようなものかも。違うか。
めっちゃわかりやすくまとまってる…。
価値を実現するためにプラクティスを実践する、ということを念頭に置いておく事が大事。決してプラクティスのためのプラクティスではない。ペアプロとか楽しいんだけどね。
CI
継続的インテグレーション(continuous integration)のこと。
サーバ上で毎日 / 毎時 / 毎分自動コンパイルして自動テストすること、と捉えておけばよい。
品質を担保するためにはコミットするには自動テストを通してからでなければいけない、ということだと思う。
SubversionとかJenkinsという言葉が出てきたのでこの講義が作られた時代の背景を感じられる。趣があるなあ。
FAQ
Q: ドキュメントは作らないの?
A: ムダなドキュメントは作らないが、必要なものに絞って作る
Q: 早く安くできるの?
A: 部分的に見ればそうかもしれないが、全機能を実装するとなると時間はかかり、コストもかかる
Q: 小規模開発向きなの?
A: 3~9人のチームを複数構成して開発する例もあるため、一概にそうとは言えない
Q: プロトタイプ開発と違うの?
A: プロトタイプはイメージをつかむためのものであるため、品質が全く違う
Q: 品質確保はどうするの?
A: 自動テストと手動テストを組み合わせることによって担保している
Q: 見積もりや契約はどうなっているの?
A: 準委任がやりやすい(請負がありえないわけではない)
Q: 追加要件が増えすぎたらどうするの?
A: 優先順位をつけて管理し、順次対応していく
Q: どんな要件が向いているの?
A: シンプルかつ変化する可能性が高い要件の場合に適している
まとめ
ウォーターフォールとの手法の違いを理解することが第一歩。
あとは上層部に納得してもらえる説明をすること
私の会社は多分まだまだウォーターフォールだよ。
ではまた。
