チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
デイリースタンドアップ／スクラムはスクラムマスタのためのものではない
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
朝会は文字通り朝にやれ - 勘と経験と読経
アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通例のような気がする。要は毎日プロジェクトメンバーが集まって、簡単に現在の状況や問題点を共有するショートミーティングをやるということ。時間を短く保つために立ってやるため、デイリー・スタンドアップ・ミーティングと呼ばれることもある。http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUpの解説がお薦め。 朝会が朝会じゃなくなってしまうとき 朝会はアジャイル開発のプラクティスの一つだけど、ツールや既存の開発プロセスとも親和性が高いので導入もしやすい。日本の会社社会ではもともと朝の訓示や連絡など
最適化した開発チームは3～10人で美しく回る
「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 今回の内容 ●課題：課題： チーム運営を改善する ●スクラムのプラクティススクラムのプラクティス チームのベスト人数は3～10人 あなたが所属する「チーム」はどんなチームですか？ チームのスタイルは千差万別です。メンバーがそれぞれ独立して仕事するチームもあれば、全員の作業状態を共有しているチームもあります。 良いチーム運営をするために、スクラムのプラクティスは有効です。スクラムの核心は、「コミュニケーションコストをなるべく上げず、有機的なチームを作ること」にあるからです。 チームミーティングの「人大杉」問題 毎週のチームミーティングで話す「内容」を思い出してください。 今週行ったことの報告 問題の共有 同
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
「Lean Startup」理論を実践するクックパッド、補完ツールも作成
「Lean Startup」の方法論を実践している企業がある。レシピ共有・検索サービスを提供するクックパッドだ。 全社員がリース氏の著書を入社前に読む クックパッドでは、新入社員に対してエリック・リース氏の「Lean Startup」を入社前に読むことを推奨している。もし入社前に読むことができなかったときには、入社後の2日を同書を読む時間にあてることができる。さらに、先輩社員が同社での活用方法をレクチャーしたり、全体会議で成果を報告したりというほどの入れ込みぶりだ。 同社の取り組みは、佐野陽光社長が「自分の言いたかったことが、うまくまとまっている」という理由から社員に薦めたことが発端。社長が普段から繰り返し話している内容に近いという理由もあり、社員の多くが「引き込まれるように」（石田忠司Happy Author部副部長）同書を読み込んだ。それだけでなく、新サービスの開発陣がその方法論を実践
クラウドの登場でDevOpsは変わっていく、メトリクス主導へ
昨日公開した記事「DevOpsとはどんなもので、何が議論されているのか（前編）」では、DevOpsの現状について、先週都内で開催されたDevOpsのイベントで行われた講演を紹介しました。 今回の記事は、同じイベントで行われたもう1つの講演の内容を紹介します。講演を行ったAlexis Lê-Quôc氏は、昨年米国で行われたイベント「DevOps Days Moutain View 2011」でパネリストを務め、DevOps Metrics and Measurementに関する世界的な第一人者。 Alexis氏は、先週日曜日に行われた東京マラソンに参加するために来日、それにあわせて講演をしていただきました。また、Alexis氏はDevOpsのためのツールDatadogの開発も行っており、講演の最後にはDatadogの紹介も行っています。 Webサイトの複雑化で全体像が見えなくなった Alex
GitHubへpull requestする際のベストプラクティス - hnwの日記
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
Flipping Out | code.flickr.com
Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day. This works well for bug fixes that we want to go out immediately, but presents a problem when we’re working on a new feature that takes several months to complete. How do we solve that problem? With flags and flippers! Feature Flags Fl
テストというのは、ソースコードの冗長化だと思う - きしだのHatena
テストというのは、基本的にはソースコードの冗長化だと思う。本来ならプロダクトコードだけ書けばよいところを、信頼性を高めるために複数の視点でのコードを追加する。 また、サーバーの冗長化で、２台構成を３台構成にするよりも、はるかに１台構成を２台にするのが難しいように、テストも、10本のテストを20本にするよりも、最初のテスト(プロダクトコードも含めると２本目のコード)を書くのが一番難しい。 テストがソースコードの冗長化であるなら、アクセスのないサイトでサーバーをクラスタリングするのが単なる金や設定時間の無駄であるように、長期的な信頼性の求められないプロダクトにテストを書くことも金の無駄だ。 アクセスが多いのにサーバー冗長化の金を払わない顧客に対してクラスタリング構成を構築する義理がないように、信頼性が求められるのにテストの金を払わず時間も確保しない顧客のためにテストを書いてやる必要もない。もち
Gitを使った分散開発管理15 – git-flowを使ってみる | DevelopersIO
git-flowを使ってブランチの管理 いままでGitについてのさまざまな機能をご紹介してきました。 まだまだほかにも機能があり自由なスタイルでソース管理できるGitですが、自由すぎてどうしようか迷うかもしれません。 今回ご紹介するものは、実際に開発を進めていく中での運用を補助するプラグイン、 git-flowについてご紹介します。 git-flowとは？ 「A successful Git branching model」※1 と呼ばれるGitのブランチモデルでの運用を補助するプラグインです。 このモデルにそったgit-flowのブランチモデルは下記のような特徴があります。 中央リポジトリとみなす、originを用意 originはmasterとdevelopのブランチを持つ masterはリリース用のブランチで、リリースしたらタグ付けする。（SVNでいう trunkとtag） deve
Gitを使った開発・運用フローの紹介
私の所属している会社では、2年程前にバージョン管理システムをSubversionからGitに移行し、現在まで開発フローを試行錯誤してきました。ようやく形になってきたということで、守秘義務に接触しない程度に紹介＆考察していきたいと思います。 形になってきたとはいえ、まだまだ試行錯誤中ですので色々なツッコミは大歓迎です。 現在の開発フローの俯瞰図# 現在の開発フローを俯瞰してみると大体下記図のような感じになっています。途中で図を書くのが面倒になった都合上、Jenkinsさんが１人しか居ませんが、実際はmasterブランチの他にreleaseブランチも監視してもらっています。 以降この図を元に話を進めていきたと思います。 Gitoriousを利用して自由に開発# GitoriousというGitHubに似たサービスがあります。このGitoriousはオープンソースとしても公開されていますので社内に
git-flow によるブランチの管理
今回は分散バージョン管理システムgitと共に用いる「ブランチモデル」について紹介していただきます。gitを使ってみて、その高機能さをどう使えば良いか悩まれた方は、ぜひ本稿をご一読ください。gitそのものの使い方については解説していませんので、その際には『 実用git 』などの書籍を参考にしてください。 git-flow は Vincent Driessen 氏によって書かれた A successful Git branching model (O-Show 氏による日本語訳) というブランチモデルを補助するための git 拡張です。 git-flow を利用する前には、まずこの文章を一読することをおすすめします。 その骨子については、 Voluntas 氏のブログ が参考になります。 git を使うメリットの 1 つは、そのブランチモデルです。しかし gitを使っていると、その高い柔軟性か
A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind
git-flow という git の運用を補助するプラグインを使ってみたので、その過程をメモしてみました。 そもそも git を採用理由なども書いていきたいと思います。 git を採用した理由 まず何よりも git を採用した理由ですが、日本語の本がたくさんある。Subversion のように気軽にブランチを切ったりマージが出来ない方法では「開発スピードにバージョン管理がついてこれない」という結論に至りました。 そこで svn から git へ以降の準備を進めています なぜ hg や bzr ではないのか git-svn を前々から使っていて rebase のありがたみや branch を気軽にきる運用になれていたからというのもありますが、なにより身近に詳しい人が多いというのが一番です。 Tower や GitX という素敵な GUI があるのも魅力の一つですね。 A successful
Gitの運用ルール、フローを考えてみた
徐々にGitに移行しつつあるのですが、複数人数（チーム）でGitを使った場合の運用ルール、ワークフローというものを考えてみました。 Git使い始めということもあり、不備は多々あると思います。アイディア等あれば是非教えて下さい！ 原則 masterで作業しない。ブランチを作って作業する。 ブランチでは1機能もしくは1バグのみ作業する。 ワークフロー 準備 ローカルのmasterに移動する $ git checkout master ローカルのmasterをリモートと同期する $ git pull origin/master masterから、作業用のブランチを作成する。 $ git checkout -b branchname master ブランチ名は担当者名と作業名をスラッシュで結合したものとする。 例： taro/featurename, taro/bugname コーディング コード
githubを会社で導入してみて感じたこと - モノノフ日記
会社で利用するソースコードのバージョン管理システムをgithubに移行しつつあります。 gitは以前から個人で利用していたのでブランチ管理のメリットや気の利いたマージなどはもう知っていたのですが githubで同時に複数人で開発をする、という状況は初めてだったので感じたことを残しておきます。 導入 まず当然なのですが開発スピードは上がってます。 これはgithubというよりgitの分散リポジトリの仕組みが大きいです。svnでsvk使うと効率が良いのと同じことです。 そこで問題になるのが各開発者のリポジトリ間をどうやってマージさせていくのか、って所なんですが masterからリリース用のブランチを切ってそこにpull requestを投げて他の開発者に確認してもらってからマージする、という流れで今は運用しています。 投げられた側が確認してマージをコミットするので責任は一蓮托生としてます。 人
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
うまく回っている会社と回ってない開発会社の職能相関図を図解してみた
http://tech-gym.com/2011/08/git/467.html