DevelopersSummit2011(1日目) #devsumi

Development

2011年デブサミ、1日目のメモ。
http://codezine.jp/devsumi/2011/

17-B-1 エンタープライズパッケージ開発の今

エンタープライズでもアジャイル開発プラクティス使っていますよ。というおはなし。

ジョエルテスト

出来ているから良いというわけではないがジョエルテストは実施すべき。

  • ソース管理システムを使っているか？
  • １オペレーションでビルドを行えるか？
  • 毎日ビルドを行うか？
  • 障害票データベースを持っているか？
  • 新しいコードを書くまえにバグを修正するか？
  • 更新可能なスケジュール表を持っているか？
  • 仕様書を持っているか？
  • プログラマは静かな労働環境にあるか？
  • 買える範囲で一番良い開発ツールを使っているか？
  • テスト担当者はいるか？
  • プログラマを採用するときにコードを書かせるか？
  • 「廊下での使い勝手テスト」を行っているか？

以下引用
ジョエルテスト


アジャイル開発プラクティス
  • 9:00出社
  • 9:15〜9:45朝会
    • 朝会は起立して議論の無駄を無くして話す
    • 1.進捗の報告
    • 2.今日やるべきタスクの確認
    • 3.タスクへのメンバアサイン
  • 10:00〜ペアプロ
    • ナビゲーター、ドライバーで役割分担
    • 1つのテーブルに向かう
    • 開発のフロー
      • 仕様書と一緒にテストケースを抜き出す
      • 正常系＆異常系のテストを1つ作成
      • テスト失敗確認
      • テストが成功するようにソースを修正
      • テスト成功確認
      • リファクタリング
ペアプロの鉄則
  • 定時過ぎて片方が「帰りたい」と発言したらみんな帰宅すること。
  • 必ずしもペアで実施する必要はなし
  • 例えばアルゴリズムを考える時や複雑な設計を行うとき
  • コミットするときには必ずペアで実施する
  • 大きな声で言う必要は無いが遊ぶ誘惑を抑制できる！
ペアプロの難しいところと解決策
  • 難しいところ
    • 若手とベテランの技術差がある
    • 若手がベテランに遠慮する
    • ベテランとベテランは口論になる時がある
  • 解決策
このセションから起こすアクション
  • チーム内にペアプロを適用してみる
  • 1ディスプレイ、ペアキーボード、ペアマウスで導入する

17-C-2 クラウド上でのエンタープライズアプリケーション開発

以下のクラウドシステムを使い実装してみる

エンタープライズシステムとクラウド
  • どのようなデータがコンシステンシーが必要なのかという視点が重要である
課題の要件

極力RDBMSを使わないようにする

Windows Azure

Azure Storage読み取り一貫性制御

  • ダーティリードは行われない
Google App Engine

ロック制御、トランザクションを本当に実装すべきか？
は頭を柔らかく考えればよい。
アプリケーションで実装できる場合も多い。

Force.com

MVCモデルを基本としている

Amazon Web Service
  • Amazon SimpleDB
まとめ

NoSQLベースでも工夫次第でエンタープライズアプリケーションは構築可能

このセッションから起こすアクション

親会社のIDCチームによるサーバ管理以外に子会社ごとのサーバ管理(クラウドだったり仮想化だったり)を提案してみる。


17-B-3 チケット駆動開発〜タスクマネジメントシステムからAgile開発へ〜

Redmineによるタスクマネジメント実践技法

@ 氏
Redmineによるタスクマネジメントシステム実践技法の書籍の著者。

チケット駆動開発の注目点
  • 小規模かつ高機能なソフトウェアの開発
  • オープン化に伴う環境の流動化
  • ユーザ要求の不安定化

に対応できる。

TiDD

チケット駆動開発 BTSでExtreme Programmingを改善する
No Ticket, No Commit!

TiDDによる課題の解決
  • ワークフロー型
    • 手順漏れの削減
  • オープン型
    • 作業漏れの削減

EclipseとBTSのプラグインがあるらしい

TiDDとは

チケットはXPでいうタスクカードのようなもの。
TicketFirst

TiDDの運用サイクル
  1. PLがバージョンを作成する
  2. チケット作成
  3. チケット解決
  4. バージョンのリリース(タグ発行)
  5. バージョン振り返り
  6. 改善要望・障害発生
チケットの親子関係で要件管理
  • 親チケット
    • ストーリーカード
  • 子チケット
    • タスクカード
リリースブランチとタスクブランチ

メインラインでメインの開発、
リリースブランチで品質改善のための開発、
タスクブランチで特定目的の開発

まとめ
  • TicketFirst
  • No Ticket, No Commit
  • 並行開発
  • 忘れた

ツールがサポートすれば行動が変わって、
行動が変われば考え方が変わって、
考え方が変わると人もチームも変わる。

このセッションから起こすアクション

要望からタスクへのプロセスは以下のように実施したい
要望→ストーリー(Wiki)→チケット

立ち話や何気ない会話で意思決定したことはWikiに残そう


17-B-4 チケット駆動開発大決戦 JIRA vs Redmine vs Trac〜ユーザが語る、なぜ私はこのツールを使うのか

ハッシュタグ
#itsjp

小川さんは業務系Webシステム開発に従事

日本におけるチケット管理の状況

だいたい以下に分類できると思う

ガントチャートの弊害

ガントチャートのビューからしかリスクが分析できない

Trac
  • trac-hacksというサイトに数百のプラグインがあって便利
  • 使い方の教育は重要
  • 定期的な棚卸は重要
Redmine
  • ロードマップで進捗率と残タスクが一目瞭然
JIRA
  • Office製品連携が出来る
  • ドッグフーディング（自ら使う）
  • オープンソースプロジェクトはJIRAを無償で使える
  • 「それJIRAっといて」
Excel
  • プロジェクト管理には使いにくい
このセッションから起こすアクション

BinaryはSVN管理したい。それとチケットを紐付けたい。
でもSVNを管理している部署から「それ容量逼迫するからやめて」と言われている。

チケット駆動開発の経験をブログに書く。