Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RICOH最終選考プレゼン資料

RICOH & JAVA Developer Challenge Plus 2013での、
Project 寿司(産業技術大学院大学)による、
発表資料

  • Login to see the comments

  • Be the first to like this

RICOH最終選考プレゼン資料

  1. 1. AjaConf 公立大学 産業技術大学院大学 産業技術研究科 チーム寿司
  2. 2. 突然ですが
  3. 3. 開発=大変
  4. 4. コンポーネント間統合 コードレビュー 機能設計 現状調査 単体テスト 統合テスト UI 設計 プログラミング 設計文書 要件定義 システムテスト テスト計画 導入 システム設計
  5. 5. 大変 !!
  6. 6. なんとか 出来た
  7. 7. あっ
  8. 8. コードレビュー大変 想像と違う 問題が見つかった テスト問題? この機能いらない プログラミングミス? 要件定義間違えた? テスト計画 見積もり間違えた 導入ミス?
  9. 9. どうする?
  10. 10. アジャイル開発
  11. 11. なにそれ?
  12. 12. アジャイルソフトウェア開発手法の多くは、反復 ( イテレーション ) と呼ばれる 短い期間単位を採用することで、リスクを最小化しようとしている。 1 つの反復の期間は、プロジェクトごとに異なるが、 1 週間から 4 週間くらいで あることが多い。アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、 1 つの反復 ( イテレーション ) で 1 機能を開発する(⇒反復型開発)。 この反復のサイクルを継続して行い、 1 つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に 1 つの小さな機能を追加する。 計画、要求分析、設計、実装 ( コーディング ) 、テスト、文書化といった、 ソフトウェアプロジェクトに要する全ての工程を、 1 つの反復内で行う。 アジャイル開発手法では、各反復が終了するごとに、機能追加された 新しいソフトウェア ( ビルド ) をリリースすることを目指す。 各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。 アジャイル開発では、たくさんの文書を書くことよりも、 プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。 ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、 1 か所の作業場所で仕事をする。 この場合の関係者には、少なくともプログラマと「顧客」が含まれる ( ここでの顧客とは開発対象のソフトウェアが何であるかを定義する人々である。 「顧客」は、時にはプロジェクト管理者であったり、ビジネスアナリストや本物の顧客である場合もある ) 。 この作業場所では、テスト担当者、ユーザインタフェース設計者、 テクニカルライタ、管理職も一緒に作業する場合がある。
  13. 13. × アジャイルソフトウェア開発手法の多くは、反復 ( イテレーション ) と呼ばれる 短い期間単位を採用することで、リスクを最小化しようとしている。 1 つの反復の期間は、プロジェクトごとに異なるが、 1 週間から 4 週間くらいで あることが多い。アジャイル開発手法においては、開発対象を多数の小さな機能に分割し、 1 つの反復 ( イテレーション ) で 1 機能を開発する(⇒反復型開発)。 この反復のサイクルを継続して行い、 1 つずつ機能を追加開発してゆくのである。 おのおのの反復は、小規模なソフトウェア開発プロジェクトに似ている。 各反復では、それまでに開発した成果物に 1 つの小さな機能を追加する。 計画、要求分析、設計、実装 ( コーディング ) 、テスト、文書化といった、 ソフトウェアプロジェクトに要する全ての工程を、 1 つの反復内で行う。 アジャイル開発手法では、各反復が終了するごとに、機能追加された 新しいソフトウェア ( ビルド ) をリリースすることを目指す。 各反復が終了するごとに、プロジェクトチームは、プロジェクトにおける優先度を評価し直す。 アジャイル開発では、たくさんの文書を書くことよりも、 プロジェクト関係者間で必要な時に即座に直接顔を合わせて意思疎通を行うべきであることを強調する。 ほとんどのアジャイル開発チームでは、ソフトウェア開発に必要な関係者全員が、 1 か所の作業場所で仕事をする。 この場合の関係者には、少なくともプログラマと「顧客」が含まれる ( ここでの顧客とは開発対象のソフトウェアが何であるかを定義する人々である。 「顧客」は、時にはプロジェクト管理者であったり、ビジネスアナリストや本物の顧客である場合もある ) 。 この作業場所では、テスト担当者、ユーザインタフェース設計者、 テクニカルライタ、管理職も一緒に作業する場合がある。
  14. 14. 長い
  15. 15. 端的に言うと
  16. 16. 短い 開発サイクル
  17. 17. 何度も回す
  18. 18. ここで大事なのは
  19. 19. 開発メンバーとの コミュニケーション
  20. 20. 従来は
  21. 21. コミュニケーション
  22. 22.
  23. 23. 対話
  24. 24. 実際は
  25. 25. 人が居る
  26. 26. × 人が居る
  27. 27. 人が居ない
  28. 28. ◯ 人が居ない
  29. 29. じゃあ
  30. 30. 続きは Web で
  31. 31. チャット
  32. 32.
  33. 33. ビデオ会議
  34. 34. 用いて
  35. 35. 開発を継続
  36. 36. そこで
  37. 37. 機能
  38. 38. 4つ
  39. 39. チャット
  40. 40. バックログ
  41. 41. 付箋
  42. 42. ビデオ会議
  43. 43. 特徴
  44. 44. 3つ
  45. 45. Web アプリ
  46. 46. 依存度低
  47. 47. いつでも どこでも だれでも
  48. 48. DEMO
  49. 49. システム概要
  50. 50. 利用技術
  51. 51. Play Flamework
  52. 52. Mongo DB
  53. 53. Nginx
  54. 54. HTML5
  55. 55. WEB SOCKET agaconf サーバー Ricoh サーバー DB DB Push Response 応答 Request 双方向通信で、 付箋や、グループ 情報等を 管理します。 Push agaconf クライアント UCS 接続要求
  56. 56. Architecture
  57. 57. ユースケース図
  58. 58. MongoDB コレクション定義
  59. 59. コレクショ ン名 論 id ID name 名前 コ レクショ ン名 型 備考 ObjectId group_member 論 id 名 ID 理 理 物 名 名 理 理 物 名 group 型 備考 ObjectId account の ID と 同 account_id アカウントID ObjectId 一 group_ id グループ ID ObjectId group の ID と 同一
  60. 60. コレクショ ン名 sticky_category 論 id ID name 名前 コレクショ ン名 型 備考 ObjectId sticky_items 論 名 型 id ID ObjectId detail 詳細 理 理 物 名 名 理 理 物 名 備考 sticky_category の ID と 同 付箋カテゴリID ObjectId 一 tanto_id 担当者 ID ObjectId account の ID と 同一 像 ID GridFS の ID と 同一 sticky_item_image_id 画 sticky_category_id ObjectId created_at 作成日 Date EmbeddedGro group_member グループメ ンバ情報 upMember 埋込情報
  61. 61. まとめ
  62. 62. アジャイル開発システム いつでも・どこでも・誰とで 作業の効率化
  63. 63. ご静聴 ありがとうございました

×