DevelopersSummit2011(1日目) #devsumi
2011年デブサミ、1日目のメモ。
http://codezine.jp/devsumi/2011/
17-B-1 エンタープライズパッケージ開発の今
エンタープライズでもアジャイル開発プラクティス使っていますよ。というおはなし。
ジョエルテスト
出来ているから良いというわけではないがジョエルテストは実施すべき。
- ソース管理システムを使っているか？
- １オペレーションでビルドを行えるか？
- 毎日ビルドを行うか？
- 障害票データベースを持っているか？
- 新しいコードを書くまえにバグを修正するか？
- 更新可能なスケジュール表を持っているか？
- 仕様書を持っているか？
- プログラマは静かな労働環境にあるか？
- 買える範囲で一番良い開発ツールを使っているか？
- テスト担当者はいるか？
- プログラマを採用するときにコードを書かせるか？
- 「廊下での使い勝手テスト」を行っているか？
以下引用
ジョエルテスト
アジャイル開発プラクティス
ペアプロの鉄則
ペアプロの難しいところと解決策
このセションから起こすアクション
- チーム内にペアプロを適用してみる
- 1ディスプレイ、ペアキーボード、ペアマウスで導入する
17-C-2 クラウド上でのエンタープライズアプリケーション開発
以下のクラウドシステムを使い実装してみる
- Google App Engine
- Windows Azure
- Amazon Web Service
- Force.com(裏側がOracle)
エンタープライズシステムとクラウド
- どのようなデータがコンシステンシーが必要なのかという視点が重要である
Google App Engine
ロック制御、トランザクションを本当に実装すべきか？
は頭を柔らかく考えればよい。
アプリケーションで実装できる場合も多い。
Force.com
MVCモデルを基本としている
Amazon Web Service
- Amazon SimpleDB
まとめ
NoSQLベースでも工夫次第でエンタープライズアプリケーションは構築可能
このセッションから起こすアクション
親会社のIDCチームによるサーバ管理以外に子会社ごとのサーバ管理(クラウドだったり仮想化だったり)を提案してみる。
17-B-3 チケット駆動開発〜タスクマネジメントシステムからAgile開発へ〜
@sakaba37 氏
Redmineによるタスクマネジメントシステム実践技法の書籍の著者。
TiDD
チケット駆動開発 BTSでExtreme Programmingを改善する
No Ticket, No Commit!
TiDDとは
チケットはXPでいうタスクカードのようなもの。
TicketFirst
TiDDの運用サイクル
- PLがバージョンを作成する
- チケット作成
- チケット解決
- バージョンのリリース(タグ発行)
- バージョン振り返り
- 改善要望・障害発生
チケットの親子関係で要件管理
- 親チケット
- ストーリーカード
- 子チケット
- タスクカード
リリースブランチとタスクブランチ
メインラインでメインの開発、
リリースブランチで品質改善のための開発、
タスクブランチで特定目的の開発
まとめ
- TicketFirst
- No Ticket, No Commit
- 並行開発
- 忘れた
ツールがサポートすれば行動が変わって、
行動が変われば考え方が変わって、
考え方が変わると人もチームも変わる。
このセッションから起こすアクション
要望からタスクへのプロセスは以下のように実施したい
要望→ストーリー(Wiki)→チケット
立ち話や何気ない会話で意思決定したことはWikiに残そう
