「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype | 転職type

転職・求人情報サイトのtype エンジニアtype スキル 「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業が行うべき最も重要なことである。良いプロダクトさえあれば、マネタイズやマーケティングの戦略もすべて後付けで立てられるからだ――。 Google会長のエリック・シュミット氏が著書『How Google Works』でこう述べるように、インターネットをベースにビジネスをする企業にとって、プロダクトを開発・発展させることこそがすべてである。ことさらスタートアップとなれば、開発・改善のスピードが大手と競争するための源泉となるだろう。 そんなスタートアップのエンジニアや、今後転職を考えるエンジニアを応援すべく、1

[mabots]

細かくローンチしていく方が良いと考えています。

[atsushifx]

SCRUMはスプリントが1ヶ月なのでスタートアップでは期間が長すぎると。リーン・スタートアップ前提で考えるならリリースというマイルストーンではなく継続的なリリースが必要と

[koyhoge]

開発技法もどんどん開発していく若い会社は頼もしいすなぁ。

[k-takahashi]

『頻繁にローンチするための体制』　『最初から「人員増」を前提』『将来外国人がチームに入っても』　『開発者だけに“閉じない”』『暗黙知をなくす』　『間違えるのは結局『ヒト』ですからね。できるだけ自動化』

[masaya-chonan]

記事では紹介されてないけど、他のスタートアップ(Sassor、repro、cyta.jp)のLTも面白かった。

[takc923]

“GitHub上でアンチパターンを指摘する際にも、「相手に対して敬意を欠くような書き方はNGだ」など細かい気配りを大事にしている。「こういう配慮がないと、チーム内に邪推が生まれたりするから」（田邊氏）だそう。”

[youko03]

"いますが、スタートアップの開発だとスクラムでも遅過ぎるくらいだと思っています。そのため、できるだけローンチを『一大事』にしないようにするのが何より重要です。一方、そんなスピード感の中でもき"

[suginoy]

おっ、煽りタイトルだ。

[babydaemons]

“チーム内／チーム間での情報共有に注力。現場には「暗黙知をなくす」、「事に向かう」、「HRT（謙虚と尊敬と信頼＝書籍『TeamGeek』より）」を徹底するようにしている”

[tak4hir0]

「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ - エンジニアtype

[luccafort]

あとで読む

[tesas]

「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業

[armadillo75]

「カジュアルにローンチできるような環境」いいですね。イテレーションは短くしてもいいと思います。瑣末なことですが、文中で言うローンチって、リリース（デプロイ）と言った方がいいかも。

[toa1121011]

カジュアルローンチ。「暗黙知をなくす」、「事に向かう」、「HRT（謙虚と尊敬と信頼＝書籍『TeamGeek』より）」を徹底する。Wrike(プロジェクト管理)。Ansible(構成管理)

[americanboss]

そもそもスクラムじゃ遅いって開発スピードでスクラムに必要な人数抱えるのは大所帯なんじゃないかってのもあるし、そのペースでいけるのは優秀なプレイヤーばかりという前提な気が。

[hideoman0330]

開発

[countzero00000]

気になる

[pattyhama]

Wrike プロジェクト管理ツール

[msuzuki047]

スクラム

[kasumani]

「スクラムでは遅過ぎる」との声も。Google主催『Startup Tech Night』で聞いた、少人数で高速開発を進めるコツ 「ユーザーを中心に考え」て、「すばらしいプロダクトを作る」ことこそが、インターネットの世紀を生きる企業