ユニコーン企業のひみつ
「ユニコーン企業のひみつ」という本を読んだ。 本旨は、成功したスタートアップ企業、所謂ユニコーンの開発手法や組織は、エンタープライズ系開発を主としている企業とは違うものですよ、という話である。 そしてそれらの企業が具体的にどういうやり方で彼らのプロダクトを開発しているのかを書いている。 ちなみにタイトルにユニコーン企業とあるけれど、別にユニコーン（評価額10億ドル以上の未上場企業）に限った話ではなく小さなスタートアップからGoogleのような既に上場して随分経っている巨大企業まで共通した話だと思う。著者もとくに区別しているわけではなく単にSpotifyで働いた経験から書いたからそのようなタイトルにしたというだけみたいだ（Spotifyもすでに上場しているので厳密にはユニコーンではない）。まあスタートアップは立ち上げのタイミングでは組織も何もないので、タイトルにあるユニコーンというのは、一応
なぜアジャイル開発はうまくいかないのか 〜 Don’t just do agile. Be agile. | Social Change!
私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私
TiDD初心者によく聞かれる質問part1～チケットが放置されがちです #tidd - プログラマの思索
チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。 最初の質問について、自分なりに考えたことをメモ。 【元ネタ】 チケット駆動開発を導入しても変わらないこと - Basic まずは箇条書きより始めよ - Basic デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002 【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。 チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。 チケットが放置されがちな状況
見積りとコミットメントは分けよう
多くの組織における根本的かつ共通の問題は、見積りとコミットメント（約束）が同一のものとして扱われていることである。 ある開発チーム（アジャイルか否かに関係なく）は、顧客が望むもの一式を納品するのに、利用可能なリソースを踏まえて7か月かかるだろうと見積もった。 チームメンバーはこの見積りをマネージャに提出したが、マネージャは見積りを部長に、部長は顧客に知らせてしまった。 そして、いくつかのケースにおいては、その見積りが、チームの「伸縮可能なゴール」を奪ってしまうことになる。 ここでの問題は、チームの7か月という見積りが合っているか間違っているか、ではない。 問題は見積りがコミットメント（約束）に変化してしまったことだ。 「我々は7か月かかると見積もりました」という言葉は「我々は7か月以内に終わらせます」という言葉に（誤って）変換されてしまう。 見積りもコミットメントも重要だけれども、それらは
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
Martin Fowler's Bliki in Japanese - ペンディングHEAD
http://martinfowler.com/bliki/PendingHead.html 2007/4/26 諸君、私は継続的インテグレーションが大好きだ。 シンプルなプラクティスが開発チームに甚大な影響を与えるのが好きだ。 だがあらゆるプラクティスがそうであるように、欠陥^H^H^H^Hカイゼンの余地がある。 Paul Duvall（まもなく出版される継続的インテグレーション本の著者）がこの点について指摘していた。 コミットビルドが失敗すると、チーム全体に影響し、それが修正されるまでスピードが落ちてしまう。 ThoughtWorksで継続的インテグレーションを始めた頃、 そのやり方について心配していたことがあった。 ThoughtWorks 2000のスタイル（訳注：2000年頃のやり方）と C3プロジェクトで使っていたスタイルが違っていたからだ。 ThoughtWorks 2000
連載 Web 2.0時代のソフトウエア開発手法---目次：ITpro
Web2.0とは何かを定義するのは難しいが，大きな流れとしてテクノロジからビジネスへと多くのエンジニアが視点を移していることは間違いないだろう。言語，設計，コンパイラ，ライブラリ，といった要素技術から，SOA（Service Oriented Architecture）の視点，例えばGoogle APIをどのように使ってサービスをミックスし，新しいビジネス価値を提供できるか，というサービスの視点がより時代に合ったものになっていると思う。エンジニアがビジネス・モデルに関心を示し，ビジネスの言葉で技術を語るようになってきているのだ。さらに，アジャイル開発の考え方が浸透し，「ビジネス価値（Business Value）」を開発の最優先とする考え方が広まっているという背景もある。 この連載では，このような時代におけるソフトウエア製品開発にはどういった視点が必要か，また，その開発はどのような手法によ
スクラムは現実解 (arclamp.jp アークランプ)
アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebや本で探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠（土日を含む30日間）を基準とする。 チームは少人数（7人前後）で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで
- XFD TOP
アイディアの箇条書き、XFD 導入奮闘日記、何でもお待ちしています！ こんなネタ持ってるよ！という方、editors at ObjectClub.jp までご連絡ください。 なお、貴社名掲載の可否、掲載するお名前（ペンネーム、匿名可）を一緒にご連絡ください。 プロジェクトステータスやメトリクスは、目に見えにくい。見えないからこそ難しい。そんな悩みを解決してくれるのが、XFD(eXtreme Feedback Device)です。目に見えて、楽しい、ユニークな装置。目に付いて、絶対見落とさないような装置を指します。安上がりならなおよろし。 XFD に関する文献：Pragmatic Project Automation 元チーム角谷XFD担当 芦沢嘉典 さん ・XFDコレクション 2004年冬(PDF 284KB) ＜2004年オブジェクト倶楽部クリスマスイベント ライトニングトークス発表資料
2004-11-14
ホワイトボードは個々人の持ち物というよりどちらかというとチームの持ち物という意識です。ホワイトボードをメンバーの人数分用意するような感覚です A3のホワイトボードは結構安いです(1000円くらい。リーダー談) ホワイトボード用のペンですが、細いペンは書き込みやすく、太いペンは気分が乗ります(元相棒談)。状況に応じて使い分けます 日本酒とカニ味噌はキラーコンボ。やばいやばい。 八重洲に行ったものの、OOSC第2版は見つからず。残念です。 読書会の中でUMLモデリングツールなど開発ツール関係の話題になったとき、ホワイトボードを使うテクニックのことを少し話しました。具体的には、A3サイズのホワイトボードを大体一人一枚くらいの枚数使用し、保存したいときにはコピー機でコピーしてしまうというテクニックです。あえて、強力なテクニックだと言っておきます。 ホワイトボードを使おうとするときに、書かれている内
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レトロスペクティブ（ふりかえり）の失敗とその回避方法
http://www.arclamp.jp/blog/archives/000556.html