===========================
エキPy読書会 12 (2011/6/7)
===========================

:日時: 2011/6/7 19:00 - 22:00
:範囲: 第9章(p247～): ライフサイクルの管理

エキスパートPythonプログラミングの読書会12回目。

開発モデルやBTSについて.

会場の様子
===========
今回からアスキーメディアワークスさん引っ越し先(飯田橋)で開催しました。

.. figure:: images/12-1.jpg

   プロジェクターが壁全面ですごい！

.. figure:: images/12-2.jpg

   会議室も広いですね

.. figure:: images/12-3.jpg

   アメニティースペースにはガンダム...?

.. figure:: images/12-4.jpg

   ドリンクとフードの自販機。Suica対応。フードはファミリーマートロゴ入りでした。

.. figure:: images/12-5.jpg

   ドリンク安い！

.. figure:: images/12-6.jpg

   読書会終了後の様子。お疲れ様でした！



読書会中に使用したTracの環境構築手順(buildout編)
==================================================

.. code-block:: bash

    $ python bootstrap.py -d init
    $ vi buildout.cfg

buildout.cfg の編集

.. code-block:: ini

    [buildout]
    parts = trac

    [trac]
    recipe = zc.recipe.egg
    eggs = trac

環境構築

.. code-block:: bash

    $ bin/buildout
    $ bin/trac-admin epp initenv
    $ bin/trac-admin epp
    Trac [epp]> permission list
    ...
    Trac [epp]> permission add anonymous TRAC_ADMIN
    Trac [epp]> [Ctrl+D]

    $ bin/tracd

.. warning::

    誰でも(anonymousでも)管理権限まで使えるように設定し、80番ポートで起動。
    これはデモ用に行った内容なので、実際の運用に際しては書籍を参考に
    適切な設定を行うこと。

ブラウザで http://localhost/epp/ にアクセス



質疑応答（覚えてる範囲）
========================

* Q: チケットのサイズはどれくらいが適切?
    * A: チームメンバーの能力をみて代表者がタスクを作っていく、それぞれのメンバーができるボリュームで割り振る
         しみずかわさんの感覚だと、1チケットで大きくても2日ぐらいのボリューム

* Q: 粒度がチケット1種類のものよりチケットとサブチケットという2種類の粒度の構成の方が良い?
    * A: 必要に応じて使い分ける

* Q: チケットを上げる人の範囲はどう設定する? 開発者、評価者、営業 (←ユーザのとこで発生) あたり?
    * A: 開発チームの運用次第、要件レベルとバグレポートを一緒にすると、一元管理のメリットはあるが、チケットの粒度は異なるというデメリットがある、
         チケットを上げるのを誰という特定はしない方が良い、チケットはレビューする必要がある
         たかのりさん: 上げないよりもどんどん上げてもらう作戦を取る

* Q: 開発が進んでいくにつれ発生する大量のチケットの中に、重要なチケットを埋没させないためには?
    * A: 優先度付けをしっかりしましょう、優先度を決めるのはチケットを作る人が主観で決めて良いけど、レビューされて変更しても良い
         たかのりさん: 優先度を上げるのは自由にやれば良い、重要度に気付かないのを避ける目的

* Q: チケットレビューってみんな何をしているの?
    * A: しみずかわさんは毎日やる、1日に10数個作って、毎日10数個クローズする感覚
         開発スタイル次第だけど、週に1回だと遅い気がする、各メンバーの進捗を見る感じでレビューしてる

* Q: チケットの分類ってどうしているの?
    * A: 機能開発、バグ、その他とか、デフォルトの項目もある

* Q: チケットと案件やドキュメントなどの紐付けをする場合があると思うが、どんなふうに運用しているの?
    * A: 質問の意図が分からない、チケットにドキュメントのリンクを書く、changelog にチケット番号は入れる

* Q: イタリアでよく使われている開発モデルや BTS に興味があります。
    * A: こみやさん調査してきて！

* Q: trac 使いなので redmine とか他ののいいところ教えてください
    * A: てらださん: bitbucket ならバックアップとってくれるし、クローズなリポジトリももてる、クラウド的なところが良い、設定が楽、拡張性は低い
         くまがいさん: Bugzilla、申請を受け付けたり、コメントが時系列で証拠として残る、後で編集できないのが良い
         もりもとさん: マルチプロジェクトを管理したり、チケットの親子関係を作るなら Mantis も良いよ
         redmine は良い評判が多い、困るのはインストール以外では聞かない
         Backlog はアジャイル系の開発で人気になってる？タスク管理で使ってる？
         ポスト Trac としては、おだぎりさんのシャーリーの開発が待ち遠しい

* Q: アジャイル開発って現場で使えるの？
    * A: 要件を含めた大きな枠組みでお客さんを巻き込めるかが課題、開発スタイルとしてもイテレーションをまわすというやり方は有効だと思う

* Q: アジャイル開発って何？
    * A: 大雑把なイメージは、開発期間を決めて、それを何回かのイテレーションで区切って、その単位ごとに反復開発するやり方
         いろんなやり方があると思うが、共通する概念はタイムボックスの期間を基本的に変えないかなぁ

* Q: OSS 開発はアジャイル？
    * A: チケットベースの開発スタイルだけど、アジャイルじゃない気がする、チケットの規模感とかは考えない


参考
======

* ATND: http://atnd.org/events/16163
* Togetter: http://togetter.com/li/145691