Context Navigation

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

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

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
  現在、OpenPNEは基本的にチーム開発で開発を進めています。[[BR]]
  その理由としては、OpenPNE開発はバグ修正、ドキュメント、開発など仕事が多岐に渡り個人がバラバラに動くよりチームとして役割を決める方が開発の効率が上がるということが挙げられます。しかし、チーム開発をする上でいくつかの障壁もあります。[[BR]]
  中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れにくいという点があげれれます。開発者間での情報がスムーズに流れなければ、開発効率が落ちチーム開発をして開発を行うメリットは少なくなります。[[BR]]
  そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNEがどの様な流れ出開発されているかを紹介しながら、OpenPNEのチーム開発を見て行こうと思います。[[BR]]
+ 中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れにくいという点が挙げられます。開発者間での情報がスムーズに流れなければ、開発効率が落ちて、チーム開発で開発を行うメリットは少なくなります。[[BR]]
+ そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNEがどの様な流れで開発されているかを紹介しながら、OpenPNEのチーム開発を見て行こうと思います。[[BR]]
 …
  OpenPNEには、リリースガイドラインがあります。基本的に、このガイドラインに則ってOpenPNEの開発を進めています。
  OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のから3ヵ月ごとから6ヵ月ごとに変更になったことによってこのリリースガイドラインも大きく見直されました。[[BR]]
+ OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のからリリース期間が3ヵ月から6ヵ月に変更になったことによってこのリリースガイドラインも大きく見直されました。[[BR]]
  中でも大きく見直された部分は機能追加条件です。3ヶ月から6ヶ月になったことで、製品の信頼度は上がるが、新たな機能の追加まで期間が長くなるというデメリットも出てきました。そこで、この機能追加条件をリリースガイドラインに追加し、機能追加条件を満たしたものであれば、安定版にも機能が追加されるようにしました。この機能追加条件を導入したことによって、OpenPNE開発版のバージョンアップが3ヶ月から6ヶ月に変更になっても機能追加がされ常に新しいOpenPNEを使うことが出来る様になりました。
 …
   ==== リリーススケジュール ====
  * 原則として、月に一度リリースする
  * リリース日は基本的に第３水曜日とする
+ * リリース日は基本的に第3水曜日とする
  * 緊急のバグが見つかった場合は、上記日程に関係なく緊急リリースを行う
 …
 == チームと開発の流れ ==
 それでは、いよいよOpenPNE安定版のチームと開発の流れについて見ていきましょう。[[BR]]
 まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。[[BR]]
+まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を簡単に紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。[[BR]]
 …
+ ■■■■■■ここは最後に開発者紹介から抜粋する■■■■■■■■■■■
  {{{
  小川 倫平
  (画像)
+ 自己紹介
+ チームリーダ
  }}}
 …
  酒井 希和
  (画像)
  自己紹介
+ バグ収集、要望収集
  }}}
  === 開発の流れ ===
  それでは、OpenPNEの安定版がどのような流れで開発されリリースされているか基本的な流れを見ていきましょう。[[BR]]
+ 基本的には以下の様な流れで開発しています。しかし、この流れで常に開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。[[BR]]
+ それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのようにコミュニケーションをとりながら開発を進めているかを解説して頂きます。[[BR]]
+ 基本的には以下の様な流れで開発しています。しかし、常にこの流れで開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。[[BR]]
+ それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのように役割を分担しながら開発を進めているかを解説して頂きます。[[BR]]
 . バグ、要望収集(酒井)
 …
 . バグを発見
 . チケット作成
 . バグ報告者へお礼のコメント(ループが終われば7へいく)
+. バグ報告者へお礼のコメント
 . トピックで報告
  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/2.png,650)]]
  バグ収集はおよそこの様な流れで進んでいきます。[[BR]]
 …
  基本的にはOpenPNE.jp～OpenPNE公式SNS～の中でバグ収集や要望収集を行っています。[[BR]]
+ OpenPNE.jp～OpenPNE公式SNS～の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。ですので、以前バグがどのように収集されたか知りたい人はこちらを参考にしてみてください。[[BR]]
+ OpenPNE.jp～OpenPNE公式SNS～の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。[[BR]]
+ バグがどのように収集されたか詳しく知りたい人はこちらを参考にしてみてください。[[BR]]
  それでは、先ほどの流れ通り上から見ていきたいと思います。[[BR]]
+  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/3.png,650)]]
+ [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/3.png,650)]]
  {{{
  OpenPNE.jp～OpenPNE公式SNS～
 …
   [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/4.png,650)]]
   基本的に前回バグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。
+  基本的に前回のバグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。
   {{{
 …
   次に、集計する日記の数とトピックコメント数を計算します。[[BR]]
   これは、次のOpenPNE開発談義で報告するためです。[[BR]]
   ==== 日記・OpenPNE開発談義にて収集開始報告 ====
   次に、Skypeのオープンチャット「OpenPNE開発談義『雑談』」で収集開始を報告します。[[BR]]
   このOpenPNE開発談義『雑談』はOpenPNE開発者の雑談を行う場所です。[[BR]]
+  このOpenPNE開発談義『雑談』はOpenPNE開発者が雑談などOpenPNEの話をする場所です。[[BR]]
   仕様策定についての議論など、リアルタイム性が必要なコミュニケーションをこのチャットルームで行っています。Skypeといえば音声通話と言うイメージがありますが、ここでは音声通話機能は利用せず、テキストベースのチャットルーム機能を利用しています。Windows MACの最新Skypeはオープンチャットに対応しているので興味があればぜひ参加してみてください。
 …
   (Tracのスクリーンショット)
 Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理もできます。
+Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理も出来ます。
 現在OpenPNEプロジェクトにはTracを使っています。以前はwikiやCVSでバグやバージョンの管理を行っていました。しかし、現在はこのTracにすべての情報を集約してOpenPNEを管理しています。
 …
   チケット作成の詳しい情報はOpenPNEのチケット作成はOpenPNE開発のガイドライン(http://trac.openpne.jp/wiki/pne-guidelines)の「チケット作成ガイドライン」にまとめられていますのでこちらを参照してください。
+  ==== バグ報告者へお礼のコメント(ループが終われば7へいく) ====
+  {{{
+  OpenPNE開発のガイドライン
+  http://trac.openpne.jp/wiki/pne-guidelines
+  }}}
+  ==== バグ報告者へお礼のコメント ====
   このバグ報告者へお礼のコメントは私がバグ収集をしている中で大切にしているところです。確かに、バグを収集するだけでコメントはいらないという意見もあると思いますが、私は必要だと考えています。なぜなら、OpenPNEはコミュニティで作り上げていくもとだと考えているからです。
+  実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。ですので、OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからやっています。
+  実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。
+  OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからコメントを続けています。
 …
  そこは試行錯誤して収集していければいいと思っています。しかし、やはりコミュニティの中でOpenPNEをより良いものにしていきたいという軸があるのでその軸がぶれないようにしていきたいと考えています。[[BR]]
  以前は要望収集も日記では行っていませんでしたが、日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。[[BR]]
+ 以前は要望収集を日記では行っていませんでしたが、現在は日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。[[BR]]
 …
  手順としてはこのような流れでバグ再現を行います。[[BR]]
  バグはやはり危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。[[BR]]
+ バグは危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。[[BR]]
  [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/9.png,650)]]
 …
  === まとめ ===
  バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でコミュニティとコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。[[BR]]
+ バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でバグの報告者とコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。[[BR]]
  そして、バグ収集、バグ再現を効率よく進めてより良いOpnePNEを作り上げたいと思います。
 …
    「Submit changes」を押すと、誰から誰にこのチケットの担当が移ったのかがChange Historyとしてチケットに記入されます。[[BR]]
    今回は誰もチケットを担当していなかったのでnobodyとなっています。[[BR]]
+   誰も担当していないチケットはnobodyとなっています。[[BR]]
    また、このChange Historyが残ることで、以前は誰が担当しているのかなど分かるようになります。[[BR]]
    また、reassign toにユーザ名を入れたら自分以外にも他の人にチケットを担当してもらうことも出来ます。例えば、一度やって見たけど、分からなかったので他の出来る人に担当してもらうなどすることも可能です。[[BR]]
 …
   このバグはOpenPNE公式SNSからのバグ報告のようです。[[BR]]
   そして、そのバグをローカル環境で確かめます。[[BR]]
   今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者はローカル環境にVMwareを使う人もいます。[[BR]]
+  今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者の中にはローカル環境にVMwareを使う人もいます。[[BR]]
   バグを確認したらコーディングに入ります。[[BR]]
 …
   このソースコードの確認ではコードが正常に動作するかなど基本的な確認はもちろん、コードの設計やセキュリティ面での抜け漏れなども確認してもらっています。
   確認してソースに不具合があった場合などは確認中のkeywordsが削除され、またバグの修正をします。[[BR]]
+  確認してソースに不具合があった場合などは確認中のkeywordsが削除され、不具合を修正をします。[[BR]]
   そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入った後に動作テストされます。[[BR]]
-  その後、レポートにあるチケットが修正されたらリリースされます。
 …
   手嶋屋ではこのFreeMindを使ってマインドマップを作成しています。
   用途としては、何かアイデアを出すとき、考えをまとめるとき、会議の議事録など幅広くマインドマップを活用しています。
+  今後OpenPNEのテスト表もこのFreeMindを使ってつくることになるでしょう。
+  今後OpenPNEのテスト表もこのFreeMindを使って作ることになるでしょう。
   }}}
 …
   それでは実際に動作テストの方法を見てきましょう。[[BR]]
   ただ、動作テストはその動作テストによってそのテスト方法が違うので、今回はツールを紹介しながら動作テストの方法を解説していこうと思います。[[BR]]
+  動作テストによって使うツールはさまざまですが、私が多く使用しているのが、「Selenium IDE」「Web Developer」「User Agent Switcher」です。数多くあるツールの中から今回はOpenPNEの動作テストに良く使うこの3つのツールを紹介したいと思います。[[BR]]
+  この3つのツールはどれもFirefoxのアドオンです。[[BR]]
+  動作テストによって使うツールはさまざまですが、私が普段多く使用しているのが、「Selenium IDE」「Web Developer」「User Agent Switcher」です。数多くあるツールの中から今回はOpenPNEの動作テストに良く使うこの3つのツールを紹介したいと思います。[[BR]]
+  この3つのツールはどれもFirefoxのアドオンです。
 Selenium IDEは主に繰り返し処理を行うときに使っています。特にOpenPNEはページングの処理が日記、コミュニティ、管理画面などに多く使われています。このように繰り返しの処理の動作テストには、このSelenium IDEを使って自動化しています。[[BR]]
   [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/16.png)]]
   次に、Web Developerですが、これは主にフォームの値チェックやバリデーション関係のバグ再現で使用しています。OpenPNEには日記やコミュニティトピックなどフォーム入力が多くあります。そのようなフォーム入力のテストなどにはこのWeb Developerを使用しています。[[BR]]
 …
   [[Image(https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/17.png,650)]]
   最後にUser Agent Switcherですが、このUser Agent Switcherは携帯でのテストに使用します。[[BR]]
   このUser Agent Switcherは簡単にUser Agent名を変更することができます。しかし、携帯でのテストはこのUser Agent Switcherだけに頼ることなく、実機でのテストが必要な場合は実機でのテストもしています。[[BR]]
 …
  === チーム開発 ===
  現在OpenPNEではチーム開発をしていますが、開発をする上でいくつか大切にしているポイントがあります。
+ 現在OpenPNEではチーム開発をしていますが、開発をする上でいくつか大切にしていることがあります。
 …
  ==== 違う視点を大切にすること ====
  OpenPNEを開発する上で違う視点を大切にすることも大切だと考えています。[[BR]]
  特に、テストやバグ再現などの時は違う視点を大切にしています。[[BR]]
+ 特に、テストやバグ再現の時は違う視点を大切にしています。[[BR]]
  開発者とテスターの違いを考えてみましょう。[[BR]]
  開発者は開発する上で開発効率の良し悪しを常に考えています。いくつもの機能を修正する際に一箇所修正してあとは同じ箇所を一括で変換すれば他のファイルも適用されて正常に動作するだろうという風に考えます。[[BR]]
  しかし、テスターというのはそのような考え方であってはならないと考えています。[[BR]]
  常にどこかに穴がないか探りながら慎重に見て実際に検証する必要があります。すべてを信頼しきってしまうことは良くありません。[[BR]]
  また、開発者というのは同じ視点を持っている場合や、当たり前という共通意識があったりします。その当たりの視点を変えるという点でテスターは開発者ではない方が良いと考えています。[[BR]]
+ また、開発者というのは同じ視点を持っている場合や、当たり前という共通意識があったりします。その辺りの視点を変えるという点でテスターは開発者ではない方が良いと考えています。[[BR]]
  チーム開発をする上で人の役割分担は非常に重要なことであると考えています。[[BR]]
 …
  ペアプログラミングとは2人で一緒にプログラミングをすることです。ただし、一人がプログラムを書きもう一人はその書いているソースを見るという手法です。この2人の役割を変えながらソースコードを書いていきます。[[BR]]
  このペアプログラミングも違う視点を大切にしています。実際にコードを書いている人は自分がソースを書くことに集中しているのでソースの間違えに気づかないことが良くあります。[[BR]]
  そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、ソースの間違えにも気づきます。[[BR]]
+ そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、ソースの間違えにも気づくことが出来ます。[[BR]]
  この様に開発を進めることでソースコードの品質が高まります。[[BR]]