アジャイル開発・スパイラル開発のメリットを,リーン時代にまとめて振り返る (計画の立て方やテストの意義,デメリットの回避方法など)
時代はもうとっくにリーン開発にシフトして久しいわけだが,
その分だけ当然ながら,「ウォーターフォール」という死語も,過去の有害な遺物として遠ざかっていく事になる。
そして,ここに至るまでに,アジャイル開発が果たした役目は大きい。
アジャイルが少し落ち着いて,既に当たり前の方法論かつ常識になった今だからこそ,アジャイルについてちょっとまとめてみよう。
- (1)アジャイル開発の導入とプロジェクト開始について
- ウォーターフォールが,いかに時代遅れで役立たずのプロセスかを説明するために
- トップ企業でのアジャイル開発の導入事例
- アジャイル方法論の導入に対して,抵抗がある場合の乗り切り方
- (2)アジャイル開発の,具体的な発想法:
- 「最初から正しく決定できるわけがない」と認めて,わざと「決定を遅らせる」。または,「最初の決定に固執するのをやめる」。
- (3)アジャイル開発における作業の具体例
- アジャイル特有のラフなプロトタイピング,およびそれを使った高速なスパイラル開発モデル
- アジャイル開発での,自動テストやテストファーストの重要性
- (4)アジャイル開発での,ドキュメントや管理手法のポジション
- アジャイル開発での,進捗の管理方法
- アジャイル開発での,ドキュメントに対するバランスの取れた見方
- (5)アジャイル開発で陥りがちな罠や,知っておくべき情報
- アジャイル開発チームの立ち上げを成功させるための方法
- 更に詳しくアジャイル開発について知っておくとよい知識
(1)アジャイル開発の導入とプロジェクト開始について
ウォーターフォールが,いかに時代遅れで役立たずのプロセスかを説明するために:
ウォーターフォールじゃだめなのか(3) - miyaniyanの日記
http://d.hatena.ne.jp/miyaniyan/20101...
- ウォーターフォールが普及している理由は、ウォータフォールって、プロジェクトを「外から」管理するには非常に都合がいいから。
- 開発のことを何もわからない人たちが,成果物のページ数などで進捗を管理しやすい。ドキュメントの中身を読まなくて済むし評価しなくて済む
InfoQ: 「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへ
http://www.infoq.com/jp/articles/hira...
- 「ソフトウェア開発は,生産や製造の活動ではありません。」(Reves92)
- 「製造」では何度も何度も同じものを作り出すのに対して、ソフトウェアエンジニアたちは毎回異なったものを作り出します。
AJ2010_20100409_maegawasensei
http://www.slideshare.net/AgileJapan/...
- ウォーターフォールでは見た目の進捗は分かっても真の進捗は最後まで分からない。
- 85年国防総省がウォーターフォールを推奨。大半が失敗に。
- その結果を受けて94年に,反復型開発を推奨に切り替え。
- システム機能の7%はいつも使い,45%は全く使わない,という統計データ
F's Garage:正直、J2EEってやばくね?
http://www.milkstand.net/fsgarage/arc...
- WEBというのは更新してナンボなので、一々、jar単位で更新してたら面倒で仕方ない
- 更新は滅多にやらない「Webアプリケーション」があるとすれば,そういうものに対してはJ2EEが役に立つ(もちろんそんなアプリケーションは役に立たない)
- Javaのライトウェイト化の流れは「人々が我慢できなくなってる」ためか。
トップ企業でのアジャイル開発の導入事例:
InfoQ: アジャイルと緊縮財政
http://www.infoq.com/jp/news/2011/12/...
- ヨーロッパ経済危機の中で、英国はitコスト削減にアジャイルが役立つと判断
- 「最終システムは徐々にしかできてこないのです」
InfoQ: Business Analysis Body of KnowledgeへのAgile拡張が公開フィードバックのためにリリース
http://www.infoq.com/jp/news/2011/11/...
- babokがアジャイル対応
アジャイル開発手法でクラウドを作るHerokuのやり方とは − Publickey
http://www.publickey1.jp/blog/11/hero...
- マイクロソフトも,Herokuを買収したセールスフォース・ドットコムも,アジャイル開発手法でサービスを開発
クオリティエンジニアの役割とは「お客様の視点を提供すること」 〜 セールスフォース・ドットコムの作り方(後編) − Publickey
http://www.publickey1.jp/blog/11/post...
- セールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用
アジャイル方法論の導入に対して,抵抗がある場合の乗り切り方:
第5回 オープンソースにおける開発方法 | Think IT
http://thinkit.co.jp/article/924/1?pa...
- 「アジャイル」っていう言葉を毛嫌いして抵抗を示す人がいたら,かわりに「バザール方式」って言えばいい。
あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある − Publickey
http://www.publickey1.jp/blog/12/2_7....
- どういう意味でアジャイルを採用するのか認識を合わせる
- 「開発環境」と「チーム環境」の主な2部分に分割して議論。
- 前者は自動テストやテスト駆動の方法論。
- 後者はイテレーションや朝会。
- ゴールはビジネス価値や顧客満足
アジャイル手法は個人の作業にも適用可能か
http://www.infoq.com/jp/news/2013/08/...
- チームより前に,個人的にアジャイルプラクティスを始める
(2)アジャイル開発の,具体的な発想法:
「最初から正しく決定できるわけがない」と認めて,わざと「決定を遅らせる」。
または,「最初の決定に固執するのをやめる」。
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え − Publickey
http://www.publickey.jp/blog/09/post_...
- アーキテクチャをまず決めて,細かい決定はできるだけあとに先延ばし。
- ただし,ユーザインタラクションは早めに取り掛かったほうがよい。
- 優秀になるほどコードから離れていくのではなく優秀な人がコードを書くべき。
「リーン」と「アジャイル」の関係とは?:書籍でたどる「リーン」の本質 (1/4) - @IT
http://www.atmarkit.co.jp/ait/article...
- 「ムダをなくす」はリーン開発の中核的な価値観
- 「最初から正しく計画・決定すること」を否定し、「学習と改善」を前提。
- 「7つの原則」と「22の思考ツール」
マイクロソフトにおけるアジャイル開発はこんな風に進められている − Publickey
http://www.publickey1.jp/blog/10/post...
- Visual Studio 2008の開発のアジャイルな進め方:(最初の時点で設計されていた)コードをコンプリートさせるのではなく、(要件としての)フィーチャーをコンプリートさせる、という考え方にシフト
(3)アジャイル開発における作業の具体例
アジャイル特有のラフなプロトタイピング,およびそれを使った高速なスパイラル開発モデル:
ワイヤーフレーム: 開発プロジェクトを始めるためのすぐれた方法
http://www.infoq.com/jp/articles/wire...
- ステークホルダーからコメントをもらうのに一番よい方法:「何も言わずに、ただ見せる」
- スクリーンショットを使ったモックアップ系プロトタイプとの違いは,詳細を意図的になくすので,機能面にフォーカスできること
Agile UCD(アジャイルユーザー中心設計) - 神原典子の よりよい User Experience へのいざない Ψ(`∀´)Ψ - Site Home - MSDN Blogs
http://blogs.msdn.com/b/norokoro/arch...
- ユーザ中心設計=UCD,user centered design. プロトタイプを何回か作って設計にユーザを巻き込む
「爆速」というスローガンの裏の現場:ヤフーは、「リーン」にどう取り組んでいるか - @IT
http://www.atmarkit.co.jp/ait/article...
- リーン・スタートアップでいう「MVP(Minimum Viable Product:機能する最小限のプロダクト)」を短期間で提供
- 市場からのフィードバックを得て修正・改善するサイクルを高速に回していく
アジャイル開発での,自動テストやテストファーストの重要性:
特集:受け入れ検査の自動化手法の考察:Windowsアプリの受け入れテストを自動化しよう (1/5) - @IT
http://www.atmarkit.co.jp/ait/article...
- アジャイルだと検収や受け入れテストの回数が増えて顧客に負担,よって自動化すべき。
- 受け入れテスト=エンド・ユーザーが使うのと同じシチュエーションで,アプリやシステムをテスト=つまりシステムの検収
手作業のテストを強いられることによる悪影響
http://www.infoq.com/jp/news/2012/09/...
- 手作業のテストを強制するとモチベーションが無くなる。
- 「自動テストツールはスプーンとフォークと同じくらい役立つ」(=無い場合の恐ろしさを考えろってこと)
ソフトウェアテストの近未来を話そう(前編)〜テストと開発の融合が必要 JaSST'12 Tokyo − Publickey
http://www.publickey1.jp/blog/12/_jas...
- テスト技術そのものは進歩していない。
- バグを見つけるのではなく、予防の観点で、作らないようにする、作り込まないような開発プロセスを確立しないとだめ。
- 走りながらテストする
TDD.NET: TDD とは?
http://www.tdd-net.jp/whats-tdd.html
- テスト駆動開発とは何か,どういう手順で行うか,どういう思想かについて良くまとまっているページ
- 失敗するユニットテストを成功させるためにしか、 プロダクトコードを書いてはならない。など
テスト駆動開発の効果はどのくらいある? − Publickey
http://www.publickey.jp/blog/10/post_...
- TDDの効果:「時間は2割増えるが,バグ密度が半減から10分の1へ」
(4)アジャイル開発での,ドキュメントや管理手法のポジション
アジャイル開発での,進捗の管理方法:
第12回 バーンダウン・チャートで「終わるかどうか」を見える化する ITpro
http://itpro.nikkeibp.co.jp/article/C...
- 残時間に注目した進捗をプロット。残りゼロがゴール。
- 特徴は,途中で増えること。
- 見積もりのずれや誤予測・誤差・リスケなどの傾向がつかめるので,後に情報を生かしやすい
アジャイル開発の議論。アナロツグールとデジタルツール、エンタープライズアジャイルについて − Publickey
http://www.publickey1.jp/blog/12/post...
- バーンダウンチャートの使い方。
- 「全部でこれだけ必要、ここまで完成、残り時間はこれしかない」という話ができれば、上司は納得する。
- 成果より,現状の全うな進捗を見せる。
アジャイル開発での,ドキュメントに対するバランスの取れた見方:
Martin Fowler's Bliki in Japanese - アジャイルな引継ぎ
http://capsctrl.que.jp/kdmsnr/wiki/bl...
- アジャイル手法では、少量高品質なドキュメントを残す
- 引継ぎのためには,運用チームの人間をしばらく開発チームに入れる
- プロセスとか単なるテンプレートに従ったものではなく、必要に応じて書かれたドキュメントは非常に役に立つ
アジャイル開発において、技術と品質の重要性は不可欠だ(前編)。Agile Japan 2013 − Publickey
http://www.publickey1.jp/blog/13/agil...
- 「ソフトウェア開発の中心とはプロセスとドキュメントではなく、コードであり、人が一緒に働くことであり、プロダクトにフォーカスすること」。
- 決して,UMLだけ書いてオフショアに放り投げることではない
(5)アジャイル開発で陥りがちな罠や,知っておくべき情報
アジャイル開発チームの立ち上げを成功させるための方法:
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ − Publickey
http://www.publickey1.jp/blog/13/7_3....
- チームの自己組織化が閾値を超えるまでは、チームの外から「君の仕事の目的は何かね?」って聞く役割は必要
スクラムの先へ進む
http://www.infoq.com/jp/news/2012/09/...
- プロセス重視のスクラムから、納品して価値を届けるリーン開発にシフトしてゆく。
- 開発チームの組織成熟とともに変化する。XPは開発者の観点が大きすぎるきらいがある。
InfoQ: Frustration with the Role and Purpose of Architects on Software Projects
http://www.infoq.com/news/2012/03/fru...
- アジャイルなチームは,YAGNIと叫んでインクリメンタルに開発し過ぎる余り,アーキテクチャやアーキテクトの存在を軽視するケースがある。
- 既存アーキテクトの側もアジャイルを軽視するので,両者の調和が必要
InfoQ: Agile と Scrumの重大な欠陥を明らかにする
http://www.infoq.com/jp/news/2010/03/...
- 開発者優位である点。ステークホルダにビジネス上の価値を引き渡すことをもっと優先すべき
- 機能givenでソリューションを考え始めてしまうと,独創性や競争力がない
更に詳しくアジャイル開発について知っておくとよい知識:
InfoQ: The Most Influential People in Agile
http://www.infoq.com/news/2012/04/agi...
- すごいリスト。現時点での,アジャイル・コミュニティに最も影響力を持つ,世界のトップ20のエンジニア達の名前およびブログリンクの一覧表。
- マーチン・ファウラーやケント・ベックも当然含まれている。
論点ちがうよ、web屋さんたちぃ〜!! - フジイユウジ::ドットネット
http://fujii-yuji.net/2008/02/web-3.html
- 発注する時は、「やりたいこと」ありきで、予算が決まっていないことが多い
- テストファーストな会社はテスト人員がアサインされているから、テストしないより高くて当然
- 同じ要件でも数百〜数千万円くらい平気でズレる
関連する記事:
バッチで,コーディング規約を守らせよう (全ソースコードをチェックして,ルール違反を自動検出)
http://language-and-engineering.hatenablog.jp/entry/20101208/p1
Ruby on Railsのテストの書き方 (モデルの単体テストと,コントローラの機能テスト)
http://language-and-engineering.hatenablog.jp/entry/20091023/p1
JavaScriptの単体テストフレームワーク "simpleJsUnit" で,テスト駆動開発をしよう
http://language-and-engineering.hatenablog.jp/entry/20090413/p1
「実行可能ドキュメント」が満たすべき性質 − テスト自動化ツール「Excelenium」で使われている技術や手法
http://language-and-engineering.hatenablog.jp/entry/20101112/p1
今から5分で,開発中のAndroidアプリを単体テストしよう (JUnitで自動テストする方法)
http://language-and-engineering.hatenablog.jp/entry/20130121/UnitTestOfAndroi...