Download as PDF, PPTX
![RSpec
describe Array, "when empty" do
before do
@empty_array = []
end
it "should be empty" do
@empty_array.should be_empty
end
end
編注: 現在の RSpec ではコマンド名が spec から rspecになっています http://jp.rubyist.net/magazine/?0021-Rspec](https://image.slidesharecdn.com/scenes-of-software-development-120113163822-phpapp01/75/slide-44-2048.jpg)
More Related Content
![[ESM_CM セミナー]小さく作って大いに役立つスマートフォンアプリ(CYCLONE)公開用](https://cdn.slidesharecdn.com/ss_thumbnails/withesmsmartphoneapplicationandcyclonecodename1000-111207215903-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
ソフトウェア開発の現場風景
- 1. オブジェクト指向勉強会 2012.01.13 (Fri) 20号館5階 名古屋工業大学 コミュニケーションルーム ソフトウェア開発の 現場風景 (株) 永和システムマネジメント サービスプロバイディング事業部 アジャイルグループ 伊藤 浩一
- 2.
- 4. 永和システムマネジメント サービスプロバイディング事業部について 私たちは「お客さまに価値を提供し続けるシステム」を 構築します。お客様の環境やビジネスの変化に適応する システムを、お客さまと一緒に育てていきます。 私たちは、ソフトウェア開発のプロフェッショナルと しての誠実な態度と、アジャイル開発のアプローチを通 じてこれを達成します。そして、そのための手段として オブジェクト指向スクリプト言語Rubyが有効だと信じ て行動しています。 不明確か つ不安定 な要求 要求 R Δ (t) システム S(t) Δ t R(t) チーム(t) S(t) Copyright (c) 2011 Eiwa System Management, Inc.
- 5. 私たちのミッション 投資効果のある、 ちゃんと動くソフトウェアを、 期待される期間内に提供し、 それを維持・変更し続けられるベンダであり、 ソフトウェアは、人が人のために作っている というシステム開発を実現します。 Copyright (c) 2011 Eiwa System Management, Inc.
- 6. Ruby x Agileの実績 10 c-team.jp 8 6 人数 4 2 decoblog.ne.jp 0 0 6 12 18 24 30 期間 (月) Copyright (c) 2011 Eiwa System Management, Inc.
- 7. 適用分野 R&D 17% BtoCサービス 業務システム 52% 31% Copyright (c) 2011 Eiwa System Management, Inc.
- 8. 社員の活動 書籍 コミュニティ オブラブ 日本XPユーザグループ 日本Rubyの会 Asakusa.rb Copyright (c) 2011 Eiwa System Management, Inc.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26. サービス インフラ提供 業務 ○○に 期待 ご近所さん
- 27. サービス インフラ提供 業務 ○○に 期待 利害関係別
- 28. サービス インフラ提供 業務 ○○に 期待 ここ 話の中心
- 29. 本編における少人数開発 • 同一場所の開発体制2∼4人 • 顧客や他社ベンダーなどを含め ると見た目以上の要員が関わる • 東京都心が中心だが、プロジェ クトによって中部、北陸、海外 に分散してのリモート開発
- 30.
- 31.
- 32. 現場の活動例 プログラミング 朝会 15% 10% 10:00 5% 25% 40% ディスカッション 夕会 5% 18:00 昼休 午後 夕会 その他 朝会 午前
- 33.
- 34.
- 35. 朝会 • デイリースタンドアップ • 2人∼4人で5分∼10分くらい • 昨日の行ったこと、今日行うこ と、そして、問題点を共有する • ありのままを、正直に伝える
- 36.
- 37. 問題が出ない!? • 本当に問題はないの？ • プロジェクトは本質的に火事 • メンバーは仕事中ぼやいていな いか？ • あなたにとって小さな問題が チームにとって大きな問題かも
- 38.
- 39. あなたならどちらを選ぶ？ プログラマーがコードリーディングしている時 •A)年末の冬休みに緊急障害が発生し、真夜 中に１メソッド２０００行のCodeの解読 に頭を痛め「ひゃはー！これはひどい、 Codeだぜ！」と思った瞬間 •B)自分よりできる奴が書いたコードを読ん で「あ！こんな記述できるんだ。こりゃ Coolだぜ!」と思った瞬間 http://patterns00-haru01.heroku.com/#57
- 40.
- 41.
- 42.
- 43.
- 44. RSpec describe Array, "whenempty" do before do @empty_array = [] end it "should be empty" do @empty_array.should be_empty end end 編注: 現在の RSpec ではコマンド名が spec から rspecになっています http://jp.rubyist.net/magazine/?0021-Rspec
- 45.
- 46.
- 47.
- 48.
- 49.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58. 何を話しているの？ • 困った時はメンバーに相談 • 仕様の理解の意識合わせ •設計方針の議論 • 利用技術の相談
- 59.
- 60.
- 61.
- 62. 問題の見える化 •触媒 (PC、壁、ホワイトボード) を使って問 題を見える化する その作 いま考えて きみ、 りだと○○の時の振 いる設計を書き出し That s You! きちんとお互いのイ る舞いが足りなくな てみると、こんな感じ メージが合った状態で いですか なのね 話してる？ You vs Me Problem vs Us
- 63. Problem vs Us •個人についてではなく問題に対 して意見をする •You vs Me ではなく、 Problem vs Us の形にする
- 64.
- 65.
- 66. 情報伝達の重要性 •ステークホルダーがいっぱい • 壮大な伝言ゲーム • 正しい情報を正しく伝える •間違った情報に対して正しく 作ってしまうと、顧客が欲しい ものを提供できない
- 67.
- 68. 情報の同期は頻繁に 信頼関係の低下▶ ズレはどこまでも 時間経過 勘違い、忘れた、欲しい物の 内容や優先順が変わった、連絡がな いとそもそも何を考えしてるのか 分からず不安 早めにズレを修正 時間の経過▶
- 69. 相手に分かる言葉で • 文章に不安があれば、メンバー 間でのレビューは有効な手段 • 大きな質疑はキャッチボールで •伝える事柄と伝える方法は車 の両輪だと考えること と達人 プログラマーにもあるよ
- 70.
- 71.
- 72. イテレーション (1週間) の流れ ふりかえりやバックログの優先度 付けなどはお客さまにご協力いた 要求 だきながら進めていきます。 ふりかえり KPT 次の ベロシティ バックログ イテレーションへ 機能 仕様の確認 タスク バグ 見積り プログラミング 内部リリース TDD データ移行 スパイク CI ドキュメント 環境構築 性能 受入テストを ジョーカー 受入テストを 書く する リリース可能な 完了基準 Ship It! ソフトウェア Copyright (c) 2011 Eiwa System Management, Inc.
- 73.
- 74. 開発打ち合わせ •デモとフィードバック これらは一例 • 要望のヒアリング • 作業の完了条件を共有する • 問題点、課題点の共有 • 全体スケジュールの確認
- 75.
- 76.
- 77.
- 78.
- 79.
- 80. Pivotal Tracker www.pivotaltracker.com
- 81.
- 82.
- 83. Problem vs Us •個々での気づきや問題を共有 •原則チーム全員が参加する • 反省会ではなくふりかえり • 過去から学んで、いまの状況を 確認して、次への改善行動に繋 げる
- 84.
- 86.
- 87.
- 88.
- 89.
- 90.
- 91.
- 92. 人に注目する •同僚 • プロジェクトメンバー • コミュニティ •プロダクトやサービスの製作者 • 興味ある技術発信をしている人
- 93.
- 94. 外部発信 •Web日記 • 勉強会 • 執筆 •ソフトウェアの公開、パッチ • コミュニティ
- 95.
- 96.
- 97. 情報発信 • アウトプットを出すことで整理 できる • パブリックな職務経歴書 • 誰(どんな人)と仕事をしたいか • 仕事をしたいと思われるか 中の人の顔が見える組織
- 98.
- 99.
- 100.
- 101.
- 102. 現場技術の一部 •Linux まだまだあるぞ！ • ソースコードの読み書き • 文書の読み書き • 見積りと計画作り • (D)SCM、テスト、自動化
- 103.
- 104.
- 105. 名著が語る重要なこと 達人プログラマー David Thomas, Andrew Hunt 1.自らの技術に関心を持つこと 2.あなたの仕事について考えること！ アジャイルサムライ Jonathan Rasmusson 1.君は学ぶことが心から好きだ 2.君はソフトウェアのことを大切に思っている
- 106. 予習復習研究はこちら 達人プログラマー David Thomas, Andrew Hunt http://www.amazon.co.jp/dp/4894712741 アジャイルサムライ Jonathan Rasmusson 西村直人, 角谷信太郎(監訳) 近藤修平, 角掛拓未(訳) http://www.amazon.co.jp/dp/4274068560 受託開発の極意 岡島 幸男 http://www.amazon.co.jp/dp/4774134538
- 107.