Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
せみやしん @shin_semiya 上層部からの「次はアジャイルでやってよ」という声で始まる 上層部のアジャイルの理解は「早い、安い、うまい」という理解 「アジャイルだから設計できてなくてもいいんでしょう?」 「アジャイルだから仕様変更何回してもいいんでしょう?」 最後にお約束の「ただし納期と仕様はマストだから」 せみやしん @shin_semiya 基本的に形から入る。 イテレーションという短い単位で区切る。一週間単位が多い。 なぜ一週間なのか、とかそういう話はしない。 かんばんというものも取り入れる。 かんばんつくる目的って何?とか考えない。 新しいプラクティスを入れないところは今まで通りやる。 せみやしん @shin_semiya 例えばタスク管理はエクセルシートで行う。 それってほかの作業と食い合わせ悪くね?という話をするのは反逆である。 また、当初に決めた作業を基本的に最後まで
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)agilelean はじめに Kent Beck氏がスタートアップのイベントに登壇し、素晴らしい講演をしたビデオを友人のタイムラインから見つけました。Startup Lessons Learnd: Kent Beck talks beyond agile programming アジャイルマニュフェストは10年が経過して、誰かの為にソフトウェアを作っていた時代から、スタートアップの時代に移行し、内容が一部古くなっていました。ところがこの講演でKentBeck氏は、それに対する素晴らしい回答をしてくれています。この内容が2010に行われているとは驚きです。 今回、このビデオを未熟なりにディクテーションして、適当ですが、日本語訳を作ってみました。本人に承認を取るつも
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
連載目次 2000年代初期に開発手法として確立された「テスト駆動開発」(Test Driven Development、以下「TDD」)は、その後10年もの間で普及が進み、今や珍しくない開発スタイルの1つとなっています。国内でも「アジャイルアカデミー」「TDD Boot Camp」などによる推進・普及活動が各地で活発化し、認知が広がってきました。 なおTDDは誕生からこれまでの間に、さまざまな工夫や実践上のノウハウが提唱されてきました。またTDDの普及に影響を受け、他のさまざまな「テストファースト」手法も台頭してきています。 本稿では、そうしたTDDの発展や、振る舞い駆動開発(Behavior Driven Development、以下「BDD」)など他のテストファースト手法への展開についても解説します。 ※編集部注:ソフトウェアの「テスト」そのものの概要や種類について知りたい方は記事「J
LEGOブロックを使った街づくりでアジャイル開発の実践を学ぶ半日のコースを見学してみた。効果のほどは? 「新しい街を作るんだから、当然家も作ってもらえるものと思っていました……」「えっ!? 仕様に書いてありせんよね?」。 「動物園って、何があれば動物園ですか? 何を作ればいいですか?」「うーん、ゾウがあればいいです」「えっ? それだけですか?」 依頼側と依頼される側のすれ違い――。開発プロジェクトでビジネス側と開発側の行き違いを経験したことがある人であれば脇の下に嫌な汗をかきそうな会話が次々と飛び出す。 子どもの頃に誰もが遊んだであろうブロックを使って街づくりをする。そんな一風変わった題材で、アジャイル開発の方法論「スクラム」を、体験を通して学ぶというワークショップをのぞいてみた。
先ごろ出版された「リーン開発の現場:カンバンによる大規模プロジェクトの運営」(ヘンリック・クニバーグ著/オーム社/2013年10月)は、アジャイル開発手法を実践事例の視点から解説した力作である。スクラム、カンバン、XPなどの手法に言及しているが、中でも「リーン開発」を正面から取り上げているのが大きな特徴となっている。 本書ではリーン開発現場の写真、会話をふんだんに使って事例解説がなされていたり、まさに現場でプロジェクトに立ち向かっているマネージャ、エンジニアたちによって訳されていたりと、実に臨場感あふれる仕上がりとなっている。ちなみに著者のヘンリック・クニバーグ氏は私の長年の友人であり、本書、日本語訳巻末の解説も私が担当した(詳細はこちらで紹介している/参考リンク:「リーン開発の現場」紹介ページ)。 ただ「リーン」という言葉は、米国で注目を集めた経営書「リーンスタートアップ」で広く知られる
「爆速」をスローガンにスピード感のある事業運営を目指すヤフー。同社のソフトウェア開発の現場ではどういう取り組みが進められているのか。これを同社CMO室の河合太郎氏が講演で話した。 ヤフーでは、「爆速」を社内のスローガンとして、「リーン・スタートアップ」 を実践しているという。同社CMO(Chief Mobile Officer)室の河合太郎氏は10月28日に開催された「IBM Innovate 2013」で、これについて講演した。 どんな企業でも、新規事業の企画書には必ずといっていいほど市場や売り上げ予測の数字が入れられる。「それは全部ウソです」と河合氏は話した。誰も将来の予測などできない、これを認めることが出発点だという。そしてリーン・スタートアップとは、あいまいなものを確かなものにする作業であり、これは組織の大小を問わず必要だと話した。 製品やサービスを完成させてから世に問うこれまでの
本企画はWeb開発企業『クレイ』におけるアジャイルソフトウェア開発の経験を漫画「ブラックジャックによろしく」の名シーンを挿絵に紹介するドキュメンタリーです。 はじめまして、認定スクラムマスターの吉岡と申します。私は2011年にWeb開発企業『クレイ』に入社して以来、開発プロセスの改善に取り組んできました。クレイはエンジニア5人とプロジェクトマネージャ2人でWeb開発を請け負っており、プロジェクトの規模としては2~3カ月で完了する短いものが主流でした。 入社当時はエンジニアそれぞれのToDo管理はしていたものの、要件の解釈で行き違いがあったり、担当者以外に開発の状況が見えないなどの問題がありました。
2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方
米国ダラスで今年8月に行われたアジャイル開発のイベント「Agile2012」には、日本からも多数の参加者がありました。そのAgile2012に参加したアジャイル活動家の方々が集まった座談会「Agile Conference Retrospective」が開催されました。 座談会ではAgile2012を振り返りつつ、日本でのアジャイル開発の現状や今後についての議論が繰り広げられました。 写真左から、松元健氏(株式会社バンダイナムコスタジオ コーポレート本部プロジェクトマネジメント課 スクラムマスター)。経営企画に近いところで、会社のスクラムマスター的役割。 上田佳典氏(NECビッグローブ株式会社 サービス開発本部)。アジャイルの考え方を全社に展開中。 伊藤宏幸氏。全社に対してスクラムの導入やアジャイル開発の教育などをしている。 藤原大氏(楽天株式会社 開発ユニット アジャイルグループ グルー
アジャイル開発を導入する方法はさまざまなところで語られてきましたが、その多くはチームのメンバーがプログラマーであることを前提としていました。しかし最近のアプリケーションではユーザー体験が重視されてきており、それを設計するUXデザイナーが開発チームに参加するようになってきています。 InfoQの記事「能力と考え方の変更がアジャイル導入を助ける」は、UXデザイナーがアジャイル開発に参加したときに経験する不安やその解決法の参考になる内容です。許可を得て、以下に転載します。 能力と考え方の変更がアジャイル導入を助ける (作者 Ben Linders、翻訳者 徳武 聡、投稿日 2012年12月10日) アジャイルを導入するとき、仕事や役割に対する心配にどのように対処すればいいだろうか。どうすれば製品開発に専門性を活かすことができるだろう。デザイナーがその能力を用いてアジャイルで価値を提供する方法につ
こんにちは、だんだんブログ勘を取り戻していきたい和田です。このエントリは TDD Advent Calendar 2013 の 11 日目のエントリです。このエントリでは、最近行ったテスト駆動開発関連の講演や寄稿に関して、この機会にまとめておきたいと思います。 DevLOVE 現場甲子園 まず 11/9 にDevLOVE現場甲子園2013にて「テストを書く文化を育てる戦略と戦術」というタイトルで短い講演をさせて頂きました。DevLOVE 甲子園は楽天第2タワー大広間の四隅で最大四つの講演が同時に行われるという意欲的なイベントで、話す方も気合い(と声量)が必要な場でした。 この講演では、開発者が自動テストを書く文化が無かった組織に自動テストの文化を育てる際の姿勢、心がけについて短い時間でまとめました。そのときの講演資料がこちらです(ライセンスは CC BY です)。 テストを書く文化を育てる
開発担当者と運用担当者が一緒に協力し、迅速に開発、リリース、フィードバックを回すことでビジネスを成功に導いていくという「DevOps」。もともとはFlickrやFacebookなどコンシューマ向けのオンラインサービス企業から登場した考え方ですが、いまではIBMなど企業向けのソフトウェア開発でもDevOpsを用いるベンダが登場してきています。 そのDevOpsで重要なのが、開発も運用も誰もが協力し合うというカルチャーを作り上げていくこと。Webサイト Agile Web Development&Operationsの記事「DevOps Anti-Patterns」では、これをやるとDevOpsが失敗するというアンチパターンを3つ挙げています。 3つのDevOpsアンチパターン アンチパターン1:コミットが“完了”/Committed is “Done” メンバー全員がタスクを終了させるとはど
プロジェクトリーダーに必要な6つの能力。スクラムの生みの親が語る、絶えざるイノベーションの創造(前編) スクラムは、アジャイル開発における方法論の中でもっとも普及している方法論の1つです。スクラムという用語を用い、その考え方を最初に提唱したのは、1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。それが1990年代半ばにジェフ・サザーランド(Jeff Sutherland)氏らによってアジャイル開発の方法論としてのスクラム(アジャイルスクラム)になったわけです。 野中氏は知識創造理論によって知られており、ウォールストリートジャーナルによる、「もっとも影響力のある思想家リスト」の20位にランクされています。 1月15日に都内で
日本でのアジャイル開発は、おもに開発現場の人たちが自分たちの課題を解決するために、現場で受け入れられ広がってきましたが、一方で最近ではリクルートや楽天、NTTデータなど、組織としてトップダウンでの導入も先進的な取り組みとして始まっています。 しかしまだ「現場としてはアジャイル開発に興味があるが、上司や取引先の理解がなかなか得られない」と思っているエンジニアや、「アジャイル開発に興味はあるが、開発者ではないので技術的なことはよく分からない」という情報部門のマネージャなど、アジャイル開発に興味があっても踏み出せない方は多いのではないでしょうか。 本書「アジャイル開発とスクラム」は、これまで多かったエンジニア向けにアジャイル開発の実践方法を解説したものではありません。エンジニアではない、上司や経営陣、取引先といったステークホルダーにアジャイル開発を理解してもらうために使える本です。 そのため、ア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く