by shigemk2

当面は技術的なことしか書かない

あたりまえのアジャイルと、その先の世界 #devmi

404 Not Found

前置き

アジャイル開発がソフトウェア開発の現場であたりまえになりつつあります。
なぜ、アジャイル開発が求められているのかを理解すると共に、ソフトウェア開発者として本当に必要な技術や知識、ツールについて語ります。
Scrum、リーンスタートアップ、ログ解析、GitHub、テスト駆動開発継続的インテグレーション、インフラの自動化、などといったキーワードを元にした、ソフトウェ開発の現場で求められる仕組み作りやスキルなどについて考察します。

$ curl http://cui-about.me/hirocaster

アジャイルをどうしたらいいんだろうか?
(あんまりアジャイルで開発している人は会場でも少なかったお)

業種にもよるが「開発はアジャイルじゃないとだめだ」って人が相当数いる

Agile is not Waterfall
とりあえずこれ以上でもこれ以下でもない。
このセッションでは「俺のアジャイルはこうだ!」という話はしない

どうして多くの開発者がアジャイルを渇望しているのか

2013年になって、振り返ってほしい変化

もうガラケー持ってる人はいないし
パッケージのソフトウェアを買うよりもその場で購入している人が多い

フォードの人

If I had asked people what they wanted, they would have said faster horses.

10年かそこらでものすごい変化で、顧客も開発者も変化しなければ「捨てられる」
かといって新しい技術を追いかけ続けても生き残れるわけではない

開発期間
1-x年単位 → 3-6ヶ月
(1年以上かけて開発するプロジェクトは殆どない)

今の時代は要件定義もないし。

10年くらい前
HTML Perl PHP Apache SQL CGI MySQL PostgreSQL Linux Shell


HTML5 JapaScript jQuery CSS3 Python ORM xSGI WAF
puppet/chef Apache CDN CI/Deploy could
Nginx

昔と比べてびっくりするほど「知っておくべき技術」増えてきている

PowerUpなのか?人間の許容範囲を越えていないか?
これはどうやって乗り越えるべきなのか?

たぶん開発者だけではなく経営者も、ひどい変化に苦しんでいる

重要なのは、

変化に備える

こと。

開発開始と開発終了時とで、市場もターゲットもガラっと変わってしまっていることがある。
そのために、スピードのある開発(≒アジャイル開発)が必要になる

ソフトウェア開発→役立つプロセスを選び、成果物を顧客の要望に合わせて調整する

Agile Software Development
アジャイル開発にはいくつもの手法が存在するが、どれが良いかは自分で選んでって欲しい


大前提 ソフトウェア開発は複雑である
複雑な構造と複雑な変化に対応できる機敏な開発を行う必要があるお

開発手法 Scrum スプリントの繰り返し→スプリントゴール→スプリットバックログ→スプリントの繰り返し
1-4週間をベースに、プロセスを反復していく

スクラムガイド

スクラムの概要

  • 軽量
  • 理解が容易
  • 習得は非常に困難(ココ重要)

アジャイル手法のカバー範囲
リーン →経営者部門
Scrum →部門
XP →開発チーム
TDD →プログラマ

ノンプログラマでも分かりやすいので、なんかノンプログラマの間でも人気

経験

スクラムは経験主義
実際の経験に基づいて、反復して次に生かし、製品出荷可能な状態まで積み上げていく
→効果的にやるためには、経験が必要である。
→なので、いきなりやろうって言っても「ゼロスタート」になるため、最初はつらいし、失敗するだろう。

スクラムは薄いフレームワークなので、開発チームが別途ルールを決める必要がある
失敗を恐れないこと。

エピソードたち
サムライ・エピソード - 達人出版会

スキル

スクラムはXPの外側にあるので、具体的に「プログラマーはどうしたらよいのか?」が
あんまり書かれていない

反復的継続的に開発するのは、経験とスキルがないと無理です。

必要なスキル

バージョン管理システム 何をおいてもまず
言語そのものの知識 言語の知識がないと、読めなかったりうまく書けなかったりするので…
オブジェクト設計 オブジェクト設計が出来る人間は殆どいない。なぜなら真面目に学んだことがないから。これが理解できないと、フレームワークも理解できないし、学べば学ぶほど辛くなっていく。
TDD (テストコードを中心に開発してく手法) テストを自動化しているので、エンバグも見つけやすい
CI コミットしたらテストしよーよって話。 JenkinsとかTravisとかCapistrano これは途中からではなく、最初から構築すること。
実装パターン

フレームワーク フレームワークを使うなら、フレームワークの知識が必須であるし、それが出来ないなら、使わないほうがよいよね
デザインパターン
リファクタリング
自動化 一日も何回もデプロイするなら、自動化は必須。

for you

アジャイル開発をやるときは、コーチがいたほうが絶対によい(金はかかるが、正直いないとやっていられないし、半年以上はかかる)
コーチによって態度が違う

反復的な経験が必要であるなら、勉強、学びは重要
ただし、全てに詳しくなる必要はない(というか、無理)ので、互いが補完できるように棲み分けをやるとよい
(Aさんは言語に詳しい、Bさんはパターンに詳しい)

GitHubはマストです
GitHub本 | Doorkeeper

Next?

これらの技術は、「使えて当たり前」になる

→feedback loop
アジャイルはbuildのみに焦点をあてている
今後はmeasureの部分に焦点が当たっていくはず

measurementできる機能を求められている

hadoop

treasure data
kissmetrics
mixpanel

などのものをより便利に作れる人間

Analysis
データをより便利に見るためには、データを解析できる能力が必要。
どういうデータが必要なのか、エンジニアが提言することになるかもしれない

From

  • User / Customer
  • Data / Action

統計能力はあったほうがよい
planning priorityを決められる人

そういうエンジニアがいてくれるといいんじゃないかな

リーンが今後どんどん来てるので、リーンで舵取り出来ればよいのではなかろうか。



データサイエンティストになっていくの?
正直、クライアントがデータやデータアナリシス能力を持っているとは思えないが、
それでもデータアナリストが必要だし、データを集めるツールを作るために、開発者の能力が必要。
というか、そもそもデータを集めてない会社が多い。