「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1
「米国におけるアジャイル・ソフトウェア開発の動向」 渡辺弘美＠JETRO/IPA NY
ニューヨークだより 2005 年 7 月.doc 「米国におけるアジャイル・ソフトウェア開発の動向」 渡辺弘美＠JETRO/IPA NY 1. 新たなソフトウェア開発手法 ― アジャイル・ソフトウェア開発 ソフトウェア開発の新たな手法として、アジャイル・プログラミングに注目が 集まっている。アジャイル開発を導入することによって、従来の開発よりも、早 く、安く、しかも品質の高いソフトウェアを開発することが狙いである。 『Agile and Iterative Development: A Manager’s Guide』の中で著者の Craig Larman はアジャイル開発を次のように定義している。 アジャイル開発 (agile development) 手法は、適応型の計画を行い、タイムボ ックスを適用しながら反復型・進化型の開発を行い、段階的に出荷するもの であり、そのほかにも「機敏性
10年のキャリアを生成する仕事の全体像 - 角谷HTML化計画(2012-11-08)
■1 10年のキャリアを生成する仕事の全体像 『達人プログラマー―システム開発の職人から名匠への道』 (このエントリは『100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊』に寄稿したkakutaniのパートの原稿の誤字を修正したものです。RubyWorld Conference 2012で松江に来ているので掲載しました) 「歯車の１つになった人間は、仕事を楽しくできない。仕事が楽しくなるのは、仕事の全体像が把握でき、全体の質に責任をもつ場合である」 このフレーズに出会ったのは、建築家クリストファー・アレグザンダーの『パターン・ランゲージ』を読んでいたときのこと。当時私は、江渡浩一郎氏の書籍『パターン、Wiki、XP』の草稿レビューに参加していた。私の役割は、書名にもある「エクストリーム・プログラミング」について、実践経験者からの視点を提供することだ。この得難い機会に何とか貢
海外でなぜアジャイル開発が普及しているのか？ IPAが分析と提言
海外ではなぜアジャイル型開発が普及しているのか、IPA（独立行政法人情報処理推進機構）が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 （非ウォーターフォール型開発の海外における普及要因編）」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
スクラムに関する無料の日本語資料のまとめ | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 スクラムを学習するにあたって参考になる【無料】の資料を以下にあげておきます。 僕がコーチングする際は上２つの資料については事前に読んでもらった上で、トレーニングを実施したりしてます。 スクラムガイドスクラムの父であるジェフ・サザーランド氏とケン・シュエイバー氏が書いた公式のルールブック。 これを読まないでスクラムをやるのはマズイです。 http://www.scrumguides.org/日本語版は、多くの本の翻訳をされている角さんが訳されてます塹壕よりScrumとXP昨年開催したScrum Gathering Tokyoで基調講演をされたヘンリック・クニベルグ氏によるScrumとXPの実践事例。 どういう問題がおきてどう改善したかも分かる。 http://www.infoq.com/jp/minibooks/scrum-xp-from-the-t
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
「アジャイル開発」で解決できることは何か〜アジャイルは「速い・安い」のファストフードではない | Social Change!
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
"許可を求めるな謝罪せよ。(Don't ask for permission, beg for forgiveness ) インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。" http://twitter.com/#!/hyoshiok/status/33183999060873216
積読・読書途中の本に関する雑感や、オンライン上の面白コンテンツ、そして世の中の不合理に対する暴言を脊髄反射的に記す。 yutakashino (柏野 雄太) another weblog: kashino.exblog.jp Archive “許可を求めるな謝罪せよ。(Don’t ask for permission, beg for forgiveness ) インターネットなんつーものはね、許可なんか求めていないクレージーな人たちによって作られてきたんだよ。それによって社会はすごくよくなったんだ。もし彼らが許可を求めていたら何も起こらなかった。そんな社会を我々は求めているのか。そーゆーことだと思う。許可を求めるな。謝罪せよ。” http://twitter.com/#!/hyoshiok/status/33183999060873216 この「許可を求めるな。謝罪せよ」というフレーズは
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
リーン・ソフトウェア開発と、アジャイルチームの先の話。組織のアジリティへ - kawaguti’s diary
４月にリーン・ソフトウェア開発の提唱者、メアリー・ポッペンディークさんと、パートナーでありソフトウェア技術者でもありプロ級の写真家でもあるトム・ポッペンディークさんの夫妻をお迎えして、(たぶん)日本初の有償研修をオーガナイズします(会社として)。 メアリー・ポッペンディーク「Leaders' Workshop (リーダーのためのワークショップ)」 4月9日〜10日 (同時通訳付き) 研修ハイライト => PDF リーン・ソフトウェア開発の「リーン」は、トヨタ自動車の生産方式を研究した北米の科学者がつけた名称です。リーンは贅肉(ムダ)が取れた状態をさすそうです。日本では工場における「ムダとり」の活動が有名です。メアリー・ポッペンディークさんは、トヨタ生産方式やその成立に大きな影響を及ぼしたデミング博士の手法を研究し、ソフトウェア開発の分野でそれを活かせるよう、３冊の本にまとめています。 リー
継続的インテグレーションアンチパターン
みなさんこんにちは。@ryuzeeです。 なんとなく書きためておいた継続的インテグレーションのアンチパターンをいくつか紹介します（結構ラフなメモ書き）。 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCIサーバのリソー
マルチタスクで仕事は遅くなる
新しいオーディエンスとしてアジャイル（またはスクラム）のストーリに参加した場合、もしメンバがチームの仕事にフルタイムで専念できたらチームはもっともっと良くなるという、巨大で厄介な障壁に悩まされることがある。よくあることだ。我々は特別な問題、特に危機的な状況を取り扱うため、 "専門家チーム" や "スワットチーム"として召集される。けれども我々の組織は、独立して業務を遂行することができるスキルを持った人の集まり、というモデルを好むようになり、メンバは複数のプロジェクトに同時にアサインされる。今では、多くのことをいっぺんに実行することがデファクトソリューションになってしまった。これが"乏しいリソース"を最も効率的な使う方法と考えられている。つまり、なんでもこなせるスペシャリストを、少人数（少したりないくらい）でチーム編成するのである。 アジャイルモデルはこれを覆した。 我々は一定時間それぞれの
「楽しく仕事する」がコンセプト--プロジェクト管理ツール「Backlog」開発のヌーラボ
アイコンや絵文字を利用でき、遊び心のあるデザインを採用するSaaS型プロジェクト管理ツール「Backlog」。これを開発するのは福岡発のベンチャー、ヌーラボだ。 ヌーラボの設立は2004年3月。当時福岡でプログラマーの派遣会社を通じて出会った現代表取締役の橋本正徳氏と現取締役の縣俊貴氏、田端辰輔氏の3人。彼らは仕事のかたわらでオープンソースソフトウェアのコミュニティに所属して福岡を中心に普及や啓蒙活動をしつつ、「Mobstar」というグループ名でWikiや掲示板、バグ管理ツールなどを公開していたという。そして、これまで開発に専念していた派遣での仕事に加えて、「顧客への提案からトータルで挑戦したい」という思いから、開発会社としてヌーラボを設立した。 同社は自社サイトで、「アジャイル開発のヌーラボ」をうたう。アジャイル開発とは、「イテレーション」と呼ぶ短期間で機能を開発していく比較的新しいソフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
グラス片手にアジャイル開発 第5回（前編） － イテレーション単位のアクティビティ