agile software development meets ruby 10 years after
TRANSCRIPT
Agile software development meets Ruby10 years after
Ruby x Agileに至る2015.02.25 (Wed)
品川フロントビル 会議室
Ruby Business Users Conference 2015
受託開発10年のいま
https://ja.wikipedia.org/wiki/%E5%A4%89%E8%BA%AB%E8%AD%9A#mediaviewer/File:Cadmus_teeth.jpg
(株) 永和システムマネジメント アジャイル事業部
Ruby x Agile グループ 伊藤 浩一 (@koic)
御礼
自己紹介
伊藤 浩一 (@koic)•2000年頃、オブジェクト指向プログラミングの学習言語として出会う
•好きなRuby256本シリーズは「極道編」と「無道編」
•XPに憧れて2004年より現職 (10周年) •現在、Railsをもちいた受託開発のプロジェクトのリーダーを務める
前史
10 years ago
2005.12.16
AWDwR写経会＠東京.ESM
http://kakutani.com/20051122.html#p01
Before Rails案件の素振り時代
http://kakutani.com/20051122.html#p01
JavaJavaJavaJava
http://kakutani.com/20051122.html#p01
JavaJavaJavaJava
社外の人(のちに同僚となる)
Before Rails案件の素振り時代
草の根運動からRubyの仕事と仲間が増え始めた
Ruby on Railsというホームラン
時は流れるhttp://ja.wikipedia.org/wiki/%E5%A4%A9%E3%81%AE%E5%B7%9D#mediaviewer/File:Milky_Way_from_Flickr.jpg
2014.12.17
Techの話
コミュニティ担当
@koic @moroプロジェクトリード職 プログラミング職
コミュニティ担当
@koic @moroプロジェクトリード職 プログラミング職
2015.02.25
いまここ
今日の話
Rubyを使った受託開発組織の現場開発のいま
http://www.ruby.or.jp/ja/news/20150127.html
ホームランを打った後
事例の話
•#1 受託開発とRuby •#2 Agileソフトウェア開発 •#3 Ruby x Agile
お品書き
#1•#1 受託開発とRuby •#2 Agileソフトウェア開発 •#3 Ruby x Agile
お品書き
プロジェクトB
プロジェクトC
プロジェクトA
.
.
.
私がいる世界
開発者 仕事
私がいる世界•特定の業務知識に寄らない •SES契約で、nヶ月をx人で受ける体制が多い
•一括請負もあるにはあるけど… •基盤となる技術はほとんどのプロジェクトがRuby/Rails
私が構築する世界•World Wide Webで実現する •Relational Databaseを中心としたデータの永続化
•プロジェクトごとのユーザーが頭に描いた世界
変化する プロジェクトと人と技術
技術基盤の変遷•Java→Ruby •CVS→SVN→Git •Trac→Redmine→Pivotal Tracker
•IRC→Idobata
プロジェクトに関わる人を横断する技術
プロジェクトに関わる人を横断する技術
Railsを中心に据えた開発
要員の変化を支える技術•DRY •プロジェクトごとにフレームワークの覚え直しが減った
•設定より規約 •テスティング, Pull Request, Continuous Integrationがどこに行っても当たり前になった開発の文化
•Rubyコミュニティの人たちと仕事する際の規約
環境を統一できなくなったもの
http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%99%E3%83%AB%E3%81%AE%E5%A1%94#mediaviewer/File:Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_(Vienna)_-_Google_Art_Project_-_edited.jpg
•ペアプログラミングと比較して、常時レビューの非同期化
•チーム単位での開発の透明性 •副作用としてどこまで進んでるか Pull Request ベースで確認できる (生煮えWIP上等文化)
ソーシャルコーディング
コードレビューへの影響•ペアプログラミングの低下とソーシャルコーディングの上昇
•直交するものなので掛け合わせると良さそう
私がいる世界•基本はプロジェクト専任 •業務特有の問題には踏み込みづらいが、Ruby/Rails/SQLなど横断する技術には比較してコメントしやすい
コードを書けば、他のプロジェクトメンバーの目に触れる機会がある
開発者としての楽しさ
『美しいコードを書けるからRubyを選んだ』
http://itpro.nikkeibp.co.jp/article/NEWS/20060620/241346/
Looks Good To Me
• PR は master に入る前の最後の機会 • master に入った後のコード読んでいますか？
• “永和のmasterには変なコードがない” by @akiinyo • https://speakerdeck.com/akiinyo/puroguraminguwei-jing-yan-nantebu-kunai-ritanzu#15
• LGTM画像にするhttps://f.cloud.github.com/assets/1606673/2307945/6ef72b40-a2b5-11e3-9708-9a7e6f7486a8.png
http://www.lgtm.in
• Looks Good To Me • レビューに楽しさを • ご利用は文化にご相談ください
• LGTM画像にするhttps://f.cloud.github.com/assets/1606673/2307945/6ef72b40-a2b5-11e3-9708-9a7e6f7486a8.png
プログラマーとユーザーと
プログラマー ユーザー
ソフトウェア (触媒であり成果)
受託開発 の楽しさ
“お客さんが目の前で喜んでいるんだぜ？”
ソフトウェアは 人が人のために 作るもの
―Kenji Hiranabe
感性重要
•Rubyをキメているとき •Pull RequestへのLGTM •顧客とのハイタッチ
われわれの受託開発を支えるもの
#2•#1 受託開発とRuby •#2 Agileソフトウェア開発 •#3 Ruby x Agile
お品書き
https://ja.wikipedia.org/wiki/Vモデル
インプットとアウトプットが繋がるVモデル
反復型開発における草モデル
つづきはこちら
feedback feedback feedback feedback feedback
継続的 デリバリー
見積りと 計画づくり
見積りと 計画づくり
“何かをプログラムする時、どの位かかるかを見積るということは完全に技術的な決定である”
エクストリームプログラミング実行計画15ページ
見積りは プログラマーの仕事
FAQ. どれくらいでできそうですか？
•Rubyでの実装を背景にした見積り •「○というgemを使えば」 •「あのあたりはdeviseを独自拡張していて (ry」
•類似を実装したときより大きいか、小さいか •類似例に詳しいメンバーがいれば解決が速くなる
•プロジェクトを横断した実装経験
見積り is 設計
言語は見積りを規定する
言語重要
環境重要
!開発環境の構築 レビュー マージ
デプロイ & デベロッパー テスト
カスタマー テスト
本番デプロイ リリースモニタリング
見積りと 計画づくり
!プログラミング
作ってテストしたらデプロイ
Goal
Start
継続的 デリバリー
•デプロイという普遍性のある流れと cap deploy というインタフェース
•rake deploy •lib/task/deploy.rake •Cap準拠のインタフェース •驚き最小限の法則
とあるオンプレ環境
•ビッグバン結合の恐怖 •顧客は何が出てくるか手に汗を握る
•イテレーションでできることを体験 •ユーザーが使っている機能の上に拡張したい機能の話できる
リリースして経験する
フィードバックを得続けることの重要性
#3•#1 受託開発とRuby •#2 Agileソフトウェア開発 •#3 Ruby x Agile
お品書き
プログラマー(現場)による開発手法
•コミュニケーション
•シンプルさ
•フィードバック
•勇気
•敬意
XPの5つの価値
https://speakerdeck.com/kakutani/agile-samurai-and-now?slide=16
Lightweight feedback stream
脳力の消費
少を重視
体験を俊敏に
プログラマー ユーザー
ソフトウェア (触媒であり成果)３.読み書きデプロイ
(プログラミング言語)４.使う (Webブラウザな
ど)
個人との対話を重視
1.対話する
ソフトウェア開発の至るところに存在する フィードバックをいちはやく得たい2.設計する、コードレビューする
人からの フィードバック
言語(環境)からの フィードバック
言語(環境)からの フィードバック
•Lightweight Languageとは「脳力」を少なく消費する
•「脳力」はプログラミング中に消費される仮想的なパワーである
•消費「脳力」の総和が少ないことももちろん重要だが瞬間最大消費「脳力」が大きすぎるのもよろしくない
『脳力』のおさらい
• irb (rails c) とテストコードの組み合わせ
•手軽な書き捨てを選択肢に入れたトライ&エラー
•環境の統一によりフロアに知見者がいれば聞いて終わる手早さ
•インターネットの情報量
手早くフィードバックを得られる環境
人からの フィードバック
•ユーザーと共有した見積りと計画をメンテナンスし続ける
•Pivotal Trackerのストーリー
•ユーザーとプログラマーで共有された、チームのベロシティに乗っ取った期待の共有
•「このフィードバックはどの程度のポイントか？いつにリリースできそうか？」
•リリース後の動きを見た余地を残して、一気に全部を作らない文化の形成
Embrace Change
プログラマーとユーザー間でフィードバックを繰り返しながら、狙え、かまえ、撃てで手に入れる
脳力の消費
少を重視
体験を俊敏に
プログラマー ユーザー
ソフトウェア (触媒であり成果)
Lightweight feedback stream
３.読み書きデプロイ (プログラミング言語)
４.使う (Webブラウザなど)
個人との対話を重視
1.対話する
５.フィードバックする2.設計する、コードレビューする
Problem
Us
右手にRuby
Us
Problem
左手にAgile
全体の調和http://ja.wikipedia.org/wiki/%E7%A2%81%E7%9B%A4#mediaviewer/File:Go_board.jpg
アジャイルな開発手法と実によく馴染む
自分たちのやり方を 自分たちで決めて作っていける(株)永和システムマネジメント
アジャイル事業部 事業部長 木下 史彦 氏
