アート・オブ・アジャイル デベロップメント 社内読書会＃３−１ - noire722 の日記
長い章ので数日に分けて追記していきます。 XPを理解する XPには要件・設計・テストという段階的なフェーズがない。 ※１ チームのオンサイト顧客がプロジェクトの方向性を管理する。 設計とコーディングはTDDで行う。 ※２ ペアプロを行う。 ※３ バージョン管理システム、自動ビルド＆テストツールを導入する。 各イテレーションの終わりにソフトウェアを導入（リリース）する。 所感＆補足 ※１ たとえばプロジェクトの納期が１年だとするとウォーターフォールは１年全体に計画・分析・設計・開発・テスト・導入を割り当てる。XPでは１〜３ヶ月の短いイテレーションの中でそれら全てをほぼ同時に行い、繰り返す。大事なのはXPが要件・設計・テストを軽視しているわけではないということ。大事だという認識があるから常に行う。（それは要件を把握している顧客がチームにいるから可能になる？） ※２ TDDで書くテストと品質テス
アート・オブ・アジャイル デベロップメント 社内読書会＃２ - noire722 の日記
４つの価値 コミュニケーション (プロセスやツールより人と人との交流を重視) シンプルさ (包括的なドキュメントよりも動作するソフトフェアを重視) フィードバック (契約上の交渉よりも顧客との協調を重視) 勇気 (計画に従うことよりも変化に適応することを重視) １２の原則（プラクティス） ①顧客の満足度を最優先 ②いつでも要件の変更を受け入れる ③動くソフトウェアの納品を頻繁に行う ④顧客と開発者が日々ともに働く ⑤リーダーをサポートし、信頼する ⑥直接話し合って情報交換する ⑦実働するソフトウェアが進捗状況の尺度 ⑧持続できるペースを保つ ⑨高度な技術と優れた設計 ⑩やらなくていいことはしない ⑪自己管理能力のあるチーム ⑫定期的にプロジェクトを見直し調整する 所感 らしいです、としか現状では言えないですが・・・ ひとつわかることはリリースを数週間単位で頻繁に行うことによって機能追加や仕
アート・オブ・アジャイル デベロップメント 社内読書会＃２ - noire722 の日記
４つの価値 コミュニケーション (プロセスやツールより人と人との交流を重視) シンプルさ (包括的なドキュメントよりも動作するソフトフェアを重視) フィードバック (契約上の交渉よりも顧客との協調を重視) 勇気 (計画に従うことよりも変化に適応することを重視) １２の原則（プラクティス） ①顧客の満足度を最優先 ②いつでも要件の変更を受け入れる ③動くソフトウェアの納品を頻繁に行う ④顧客と開発者が日々ともに働く ⑤リーダーをサポートし、信頼する ⑥直接話し合って情報交換する ⑦実働するソフトウェアが進捗状況の尺度 ⑧持続できるペースを保つ ⑨高度な技術と優れた設計 ⑩やらなくていいことはしない ⑪自己管理能力のあるチーム ⑫定期的にプロジェクトを見直し調整する 所感 らしいです、としか現状では言えないですが・・・ ひとつわかることはリリースを数週間単位で頻繁に行うことによって機能追加や仕
アートオブアジャイルデベロップメント第２章 - shokosブログ
第２章アジャイルになる方法 ・自分専用の手法を作ってはいけない ＊＊要約＊＊ アジャイル手法は、バージョン管理やペアプロなどのプラクティスと呼ばれる要素からできている。 まだアジャイルにふれていない人は、１から独自にプラクティスを組み合わせてアジャイル手法で開発するのではなく、既存の実績のあるアジャイル手法から初めて、状況に応じて繰り返し改良していくのがよい。 ＊＊感想＊＊ プラクティスってどんなものがあげられているんだろうと思ったら、想像していたよりもたくさんありました。 ただ、普段やっているこれってプラクティスだったのか、 という発見もたくさんありました。 例えば「イテレーション計画」「リファクタリング」「バージョン管理」などなど。 わたしがチームに加わってちょっとたってから導入された、「バーンダウンチャート」もきっとプラクティスに入ります。 そうやって改良されての今の状態なんだと思い
アート・オブ・アジャイル デベロップメント 社内読書会＃１ - noire722 の日記
アート・オブ・アジャイル デベロップメント社内勉強会を今日から始めました。 日々、要約をまとめていこうと思います。 わかりやすくするために自分の言葉に直しているため、間違っている点があれば指摘していただけると嬉しいです。 アジャイルソフトウェア開発 -wikipedia なぜアジャイルなのか？ アジャイル開発を行うと生産性が上がったという統計がある。 ただし生産性を上げるためにアジャイル開発を導入するのではない。(※むしろ下がることもある) 導入するかどうかの決め手は「アジャイル開発がプロジェクトに成功をもたらすかどうか」 成功を理解する 古典的定義 成功した：納期通りに予算内で仕様通りに全ての機能を実装した 苦戦した：予算や納期をオーバーしたりしたがとにかく完成した 失敗した：開発の途中でプロジェクトが中止になった しかし、以下のケースも事実としてある。 一銭も儲からなくてもプロジェクト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
