ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Changes between Version 9 and Version 10 of pne-book-9-4


Ignore:
Timestamp:
Mar 6, 2008, 4:36:43 PM (15 years ago)
Author:
imoto
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • pne-book-9-4

    v9 v10  
    77 現在、OpenPNEは基本的にチーム開発で開発を進めています。[[BR]]
    88 その理由としては、OpenPNE開発はバグ修正、ドキュメント、開発など仕事が多岐に渡り個人がバラバラに動くよりチームとして役割を決める方が開発の効率が上がるということが挙げられます。しかし、チーム開発をする上でいくつかの障壁もあります。[[BR]]
    9  中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れにくいという点があげれれます。開発者間での情報がスムーズに流れなければ、開発効率が落ちチーム開発をして開発を行うメリットは少なくなります。[[BR]]
    10  そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNEがどの様な流れ開発されているかを紹介しながら、OpenPNEのチーム開発を見て行こうと思います。[[BR]]
     9 中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れにくいという点が挙げられます。開発者間での情報がスムーズに流れなければ、開発効率が落ちて、チーム開発で開発を行うメリットは少なくなります。[[BR]]
     10 そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNEがどの様な流れ開発されているかを紹介しながら、OpenPNEのチーム開発を見て行こうと思います。[[BR]]
    1111
    1212
     
    3030 OpenPNEには、リリースガイドラインがあります。基本的に、このガイドラインに則ってOpenPNEの開発を進めています。
    3131
    32  OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のから3ヵ月ごとから6ヵ月ごとに変更になったことによってこのリリースガイドラインも大きく見直されました。[[BR]]
     32 OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のからリリース期間が3ヵ月から6ヵ月に変更になったことによってこのリリースガイドラインも大きく見直されました。[[BR]]
    3333 中でも大きく見直された部分は機能追加条件です。3ヶ月から6ヶ月になったことで、製品の信頼度は上がるが、新たな機能の追加まで期間が長くなるというデメリットも出てきました。そこで、この機能追加条件をリリースガイドラインに追加し、機能追加条件を満たしたものであれば、安定版にも機能が追加されるようにしました。この機能追加条件を導入したことによって、OpenPNE開発版のバージョンアップが3ヶ月から6ヶ月に変更になっても機能追加がされ常に新しいOpenPNEを使うことが出来る様になりました。
    3434
     
    3939  ==== リリーススケジュール ====
    4040 * 原則として、月に一度リリースする
    41  * リリース日は基本的に第水曜日とする
     41 * リリース日は基本的に第3水曜日とする
    4242 * 緊急のバグが見つかった場合は、上記日程に関係なく緊急リリースを行う
    4343
     
    5959== チームと開発の流れ ==
    6060それでは、いよいよOpenPNE安定版のチームと開発の流れについて見ていきましょう。[[BR]]
    61 まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。[[BR]]
     61まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を簡単に紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。[[BR]]
    6262
    6363
     
    6666 
    6767 
     68 ■■■■■■ここは最後に開発者紹介から抜粋する■■■■■■■■■■■
    6869 {{{
    6970 小川 倫平
    7071 (画像)
    71  自己紹介
     72 チームリーダ
     73 
     74 
    7275 }}}
    7376 
     
    8184 酒井 希和
    8285 (画像)
    83  自己紹介
     86 バグ収集、要望収集
    8487 }}}
    8588 
    8689 === 開発の流れ ===
    8790 それでは、OpenPNEの安定版がどのような流れで開発されリリースされているか基本的な流れを見ていきましょう。[[BR]]
    88  基本的には以下の様な流れで開発しています。しかし、この流れで常に開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。[[BR]]
    89  それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのようにコミュニケーションをとりながら開発を進めているかを解説して頂きます。[[BR]]
    90 
     91 基本的には以下の様な流れで開発しています。しかし、常にこの流れで開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。[[BR]]
     92 それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのように役割を分担しながら開発を進めているかを解説して頂きます。[[BR]]
    9193
    9294 1. バグ、要望収集(酒井)
     
    109111 1. バグを発見
    110112 1. チケット作成
    111  1. バグ報告者へお礼のコメント(ループが終われば7へいく)
     113 1. バグ報告者へお礼のコメント
    112114 1. トピックで報告
    113115 
    114116 [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/2.png,650)]]
    115  
     117
    116118
    117119 バグ収集はおよそこの様な流れで進んでいきます。[[BR]]
     
    125127 
    126128 基本的にはOpenPNE.jp~OpenPNE公式SNS~の中でバグ収集や要望収集を行っています。[[BR]]
    127  OpenPNE.jp~OpenPNE公式SNS~の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。ですので、以前バグがどのように収集されたか知りたい人はこちらを参考にしてみてください。[[BR]]
     129 OpenPNE.jp~OpenPNE公式SNS~の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。[[BR]]
     130 バグがどのように収集されたか詳しく知りたい人はこちらを参考にしてみてください。[[BR]]
    128131 
    129132 それでは、先ほどの流れ通り上から見ていきたいと思います。[[BR]]
    130133 
    131134 
    132   [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/3.png,650)]]
     135 [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/3.png,650)]]
     136 
    133137 {{{
    134138 OpenPNE.jp~OpenPNE公式SNS~
     
    145149  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/4.png,650)]]
    146150 
    147   基本的に前回バグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。
     151  基本的に前回バグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。
    148152 
    149153  {{{
     
    164168  次に、集計する日記の数とトピックコメント数を計算します。[[BR]]
    165169  これは、次のOpenPNE開発談義で報告するためです。[[BR]]
    166 
    167 
     170 
     171 
    168172  ==== 日記・OpenPNE開発談義にて収集開始報告 ====
    169173  次に、Skypeのオープンチャット「OpenPNE開発談義『雑談』」で収集開始を報告します。[[BR]]
    170   このOpenPNE開発談義『雑談』はOpenPNE開発者の雑談を行う場所です。[[BR]]
     174  このOpenPNE開発談義『雑談』はOpenPNE開発者が雑談などOpenPNEの話をする場所です。[[BR]]
    171175  仕様策定についての議論など、リアルタイム性が必要なコミュニケーションをこのチャットルームで行っています。Skypeといえば音声通話と言うイメージがありますが、ここでは音声通話機能は利用せず、テキストベースのチャットルーム機能を利用しています。Windows MACの最新Skypeはオープンチャットに対応しているので興味があればぜひ参加してみてください。
    172176 
     
    221225  (Tracのスクリーンショット)
    222226 
    223 Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理もできます。
     227Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理も出来ます。
    224228 
    225229現在OpenPNEプロジェクトにはTracを使っています。以前はwikiやCVSでバグやバージョンの管理を行っていました。しかし、現在はこのTracにすべての情報を集約してOpenPNEを管理しています。
     
    264268  チケット作成の詳しい情報はOpenPNEのチケット作成はOpenPNE開発のガイドライン(http://trac.openpne.jp/wiki/pne-guidelines)の「チケット作成ガイドライン」にまとめられていますのでこちらを参照してください。
    265269 
    266  
    267   ==== バグ報告者へお礼のコメント(ループが終われば7へいく) ====
     270  {{{
     271  OpenPNE開発のガイドライン
     272  http://trac.openpne.jp/wiki/pne-guidelines
     273   
     274  }}}
     275 
     276 
     277  ==== バグ報告者へお礼のコメント ====
    268278 
    269279  このバグ報告者へお礼のコメントは私がバグ収集をしている中で大切にしているところです。確かに、バグを収集するだけでコメントはいらないという意見もあると思いますが、私は必要だと考えています。なぜなら、OpenPNEはコミュニティで作り上げていくもとだと考えているからです。
    270280 
    271   実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。ですので、OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからやっています。
     281  実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。
     282  OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからコメントを続けています。
    272283
    273284
     
    302313 そこは試行錯誤して収集していければいいと思っています。しかし、やはりコミュニティの中でOpenPNEをより良いものにしていきたいという軸があるのでその軸がぶれないようにしていきたいと考えています。[[BR]]
    303314 
    304  以前は要望収集も日記では行っていませんでしたが、日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。[[BR]]
     315 以前は要望収集を日記では行っていませんでしたが、現在は日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。[[BR]]
    305316
    306317
     
    317328 
    318329 手順としてはこのような流れでバグ再現を行います。[[BR]]
    319  バグはやはり危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。[[BR]]
     330 バグは危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。[[BR]]
    320331 
    321332 [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/9.png,650)]]
     
    335346
    336347 === まとめ ===
    337  バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でコミュニティとコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。[[BR]]
     348 バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でバグの報告者とコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。[[BR]]
    338349 そして、バグ収集、バグ再現を効率よく進めてより良いOpnePNEを作り上げたいと思います。
    339350 
     
    392403   
    393404   「Submit changes」を押すと、誰から誰にこのチケットの担当が移ったのかがChange Historyとしてチケットに記入されます。[[BR]]
    394    今回は誰もチケットを担当していなかったのでnobodyとなっています。[[BR]]
     405   誰も担当していないチケットはnobodyとなっています。[[BR]]
    395406   また、このChange Historyが残ることで、以前は誰が担当しているのかなど分かるようになります。[[BR]]
    396407   また、reassign toにユーザ名を入れたら自分以外にも他の人にチケットを担当してもらうことも出来ます。例えば、一度やって見たけど、分からなかったので他の出来る人に担当してもらうなどすることも可能です。[[BR]]
     
    407418  このバグはOpenPNE公式SNSからのバグ報告のようです。[[BR]]
    408419  そして、そのバグをローカル環境で確かめます。[[BR]]
    409   今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者はローカル環境にVMwareを使う人もいます。[[BR]]
     420  今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者の中にはローカル環境にVMwareを使う人もいます。[[BR]]
    410421
    411422  バグを確認したらコーディングに入ります。[[BR]]
     
    477488  このソースコードの確認ではコードが正常に動作するかなど基本的な確認はもちろん、コードの設計やセキュリティ面での抜け漏れなども確認してもらっています。 
    478489 
    479   確認してソースに不具合があった場合などは確認中のkeywordsが削除され、またバグの修正をします。[[BR]]
     490  確認してソースに不具合があった場合などは確認中のkeywordsが削除され、不具合を修正をします。[[BR]]
    480491 
    481492  そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入った後に動作テストされます。[[BR]]
    482   その後、レポートにあるチケットが修正されたらリリースされます。
    483493 
    484494 
     
    572582  手嶋屋ではこのFreeMindを使ってマインドマップを作成しています。
    573583  用途としては、何かアイデアを出すとき、考えをまとめるとき、会議の議事録など幅広くマインドマップを活用しています。
    574   今後OpenPNEのテスト表もこのFreeMindを使ってつくることになるでしょう。
    575  
     584  今後OpenPNEのテスト表もこのFreeMindを使って作ることになるでしょう。
    576585 
    577586  }}}
     
    583592  それでは実際に動作テストの方法を見てきましょう。[[BR]]
    584593  ただ、動作テストはその動作テストによってそのテスト方法が違うので、今回はツールを紹介しながら動作テストの方法を解説していこうと思います。[[BR]]
    585   動作テストによって使うツールはさまざまですが、私が多く使用しているのが、「Selenium IDE」「Web Developer」「User Agent Switcher」です。数多くあるツールの中から今回はOpenPNEの動作テストに良く使うこの3つのツールを紹介したいと思います。[[BR]]
    586   この3つのツールはどれもFirefoxのアドオンです。[[BR]]
     594  動作テストによって使うツールはさまざまですが、私が普段多く使用しているのが、「Selenium IDE」「Web Developer」「User Agent Switcher」です。数多くあるツールの中から今回はOpenPNEの動作テストに良く使うこの3つのツールを紹介したいと思います。[[BR]]
     595  この3つのツールはどれもFirefoxのアドオンです。
     596 
    587597Selenium IDEは主に繰り返し処理を行うときに使っています。特にOpenPNEはページングの処理が日記、コミュニティ、管理画面などに多く使われています。このように繰り返しの処理の動作テストには、このSelenium IDEを使って自動化しています。[[BR]]
    588598
    589599  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/16.png)]]
     600
    590601
    591602  次に、Web Developerですが、これは主にフォームの値チェックやバリデーション関係のバグ再現で使用しています。OpenPNEには日記やコミュニティトピックなどフォーム入力が多くあります。そのようなフォーム入力のテストなどにはこのWeb Developerを使用しています。[[BR]]
     
    595606  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/17.png,650)]]
    596607 
     608 
    597609  最後にUser Agent Switcherですが、このUser Agent Switcherは携帯でのテストに使用します。[[BR]]
    598610  このUser Agent Switcherは簡単にUser Agent名を変更することができます。しかし、携帯でのテストはこのUser Agent Switcherだけに頼ることなく、実機でのテストが必要な場合は実機でのテストもしています。[[BR]]
     
    654666
    655667 === チーム開発 ===
    656  現在OpenPNEではチーム開発をしていますが、開発をする上でいくつか大切にしているポイントがあります。
     668 現在OpenPNEではチーム開発をしていますが、開発をする上でいくつか大切にしていることがあります。
    657669 
    658670 
     
    675687 ==== 違う視点を大切にすること ====
    676688 OpenPNEを開発する上で違う視点を大切にすることも大切だと考えています。[[BR]]
    677  特に、テストやバグ再現などの時は違う視点を大切にしています。[[BR]]
     689 特に、テストやバグ再現の時は違う視点を大切にしています。[[BR]]
    678690 開発者とテスターの違いを考えてみましょう。[[BR]]
    679691 開発者は開発する上で開発効率の良し悪しを常に考えています。いくつもの機能を修正する際に一箇所修正してあとは同じ箇所を一括で変換すれば他のファイルも適用されて正常に動作するだろうという風に考えます。[[BR]]
    680692 しかし、テスターというのはそのような考え方であってはならないと考えています。[[BR]]
    681693 常にどこかに穴がないか探りながら慎重に見て実際に検証する必要があります。すべてを信頼しきってしまうことは良くありません。[[BR]]
    682  また、開発者というのは同じ視点を持っている場合や、当たり前という共通意識があったりします。その当たりの視点を変えるという点でテスターは開発者ではない方が良いと考えています。[[BR]]
     694 また、開発者というのは同じ視点を持っている場合や、当たり前という共通意識があったりします。そのりの視点を変えるという点でテスターは開発者ではない方が良いと考えています。[[BR]]
    683695 チーム開発をする上で人の役割分担は非常に重要なことであると考えています。[[BR]]
    684696 
     
    686698 ペアプログラミングとは2人で一緒にプログラミングをすることです。ただし、一人がプログラムを書きもう一人はその書いているソースを見るという手法です。この2人の役割を変えながらソースコードを書いていきます。[[BR]]
    687699 このペアプログラミングも違う視点を大切にしています。実際にコードを書いている人は自分がソースを書くことに集中しているのでソースの間違えに気づかないことが良くあります。[[BR]]
    688  そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、ソースの間違えにも気づます。[[BR]]
     700 そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、ソースの間違えにも気づくことが出来ます。[[BR]]
    689701 この様に開発を進めることでソースコードの品質が高まります。[[BR]]
    690702