読者です 読者をやめる 読者になる 読者になる

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

デブサミ2011 で 17-B-1 に出た時のメモです。嘘書いてあるかもしれません。

[梅田]
MIJS = Made In Japan Software Consosium

[小野]
ジョエル・テストを各社持ち寄って討議

[梅田]
各社のノウハウを取りまとめ『実践アジャイル開発手法』

[萩原]
アクセラの事例
〜09:00 出社
9:15〜9:45 朝会 スタンドアップミーティング
1. 進捗の報告(問題があれば相談)
2. 今日やるべきタスクの確認
3. タスクへのメンバのアサイン
10:00〜 開発(ペアプロ)
Redmine
1. 仕様書と一緒にテストケースを抜き出す
2. 以下の手順にてテスト&実装
正常系もしくは異常系テストを1つ作成
テスト失敗確認
テストが成功するようにソースを修正
テスト成功確認
リファクタリング
3. 全てのテストが終わるまで2を繰り返す
4. カバレッジ率を確認する。100%でない場合はなぜか確認
18:00〜 退社
残業は、ペアの片方が帰りたいと言ったら終わり

[小野]
ペアプロを徹底してやった。
今はゆるやか。
一人で集中してやった方がいいこともある。アルゴリズムを考えるとか。
コミット前にレビューは絶対行う。

[梅田]
ペアプロは速度が半分?

[萩原]
工数的には若干損
ただし技術者を育てるには良い

[小野]
PCで遊んでしまう誘惑
ペアプロは仕事しかしないから早く終わる

[小林]
ペアプロはやってない
上から設計が降りてくる
設計者を開発者の横に座らせてる。1日の半分くらい

[梅田]
なかなかうまくいかない

[萩原]
特にルールはない
当初は新入社員同士をペアにしちゃったり、アクの強いもの同士だと口論が始まったり

[梅田]
ナビゲータとドライバの交代ルールは?

[萩原]
仕様書を先に作る
設計をした人間がナビゲータをやる

[梅田]
TDD100%で工数増えない?

[萩原]
最初は効果があるか疑問だった
完全に動いて仕様変更機能追加がない場合はやらなくてもいいと思う
実際はそんなことないのでテスト自動化が必要

[小野]
テストファーストはやってる部分とやってない部分がある
パッケージ製品は納品して終わりじゃなくて、ソースコードのライフサイクルが長い
テスト自動化は絶対必要
プロトタイプフェーズを長くとるのでテストファーストはしない
手触りとか仕様を確認する時にテストは要らない
使い分けてる

[梅田]
CIは?

[小林]
はじめはCIはできてなかった
コミットされたらビルド&テストが自動的に実行される
フィードバックが速い
チームの一体感が出てきた
デモ環境を作ったりバックアップ環境を作るのにも応用できる

[会場]
ペアプロがむずかしい。若手が遠慮してしまう。一方的に教えることになってしまったり。
テストは昔やってたけど今はやってないとか。
単にエラーが出ないことしか確認してないとか。

[萩原]
ペアプロはあわないメンバーはいる。ペアの組み方に気をつけてる。

[小野]
プログラマーとしてのリテラシーと、ペアプログラマーとしてのリテラシーは別
ペアプロは同時に人とも向き合う
ペアプロ初心者の集団がいっせいにやるとアレルギー反応で、うちには無理だってことになる
成功例をみせないといけない
段階的にやるのが良い
テストも同じ。

[梅田]
トップがあるというのも大事
アクセラは社長がやりたいから教えてって言って、ペアプロやってるうちの会社に訪ねてきた

[萩原]
ショック療法
まずいとわかってるけど、そのままやらせて、やっぱり通らない。
その時に徹底的に考えさせる
テストが大事というのを身につかせる

[会場]
ペアプロやるにあたって工夫することは

[萩原]
キーボード&マウスを2つ使ってる。邪道。
ナビゲータがすぐどうすればいいかと示せるように
モニタもペアで並べたけどあまり意味なかった。

[小野]
その日のペアが決まってるわけではない
ちょっとペアやりたい時にバランスボールを転がしてくる
特に工夫してない

[会場]
ペアプロの相性(ききとれませんでした)

[萩原]
うちでは特にやってない
とりあえずペアを組んで顔色みたり、朝会の進捗みたり