[wip]楽しく仕事をするために試行錯誤しているGitHubの使いかた | DevelopersIO
丹内です。入社してそろそろ3ヶ月になります。 先日のAWS Summitの社内報告会で発表を行いました。 ※上記スライドに示された意見はわたし個人のものであり、所属する組織を代表するものではありません。 この発表の最初と最後のGitHubの方が発表した内容の試行錯誤メモブログです。 tl;dr リモートの人と受託開発をスクラムで進めるにあたり、コミュニケーションをGitHubに集約する試行錯誤中です。 先日のAWS Summit 2015 Tokyoで聴講した「働き方もOSSのようにすることで楽しくなる」という旨の発表に感銘を受け、実務で試みています。 ZenHubとSlackを併用しながら進めています。良い方法や改善点があったら是非指摘してください。 前提 今回は、ソフトウェアの受託開発を想定します。 開発者3,4人が、同じリポジトリで、Railsアプリを開発するとします。 リモートワー
![[wip]楽しく仕事をするために試行錯誤しているGitHubの使いかた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/32b74aa314e14e830f2a8901dc1ebf0425618408/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F11%2FGitHub-Mark-400.png)
ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか？ | Social Change!
「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積
日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
続きを書きました → 伝えなければ伝わらないという当たり前の話 ソフトウェア開発に関する相談を受ける中で、どうもソフトウェアというものの特性について誤解をされているな、という思いを持つことがあります。 そうした場合、聞いてみるとプログラミングの経験が無かったり、殆どプログラミングには携わったことがないという方が多いです。 ソフトウェアを開発しようとするならば、ソフトウェアという特性をよく知った上で、プロジェクトは運営した方が良いし、うまくいくはずです。そしてソフトウェアならではの特徴を知るのに、プログラミングの経験はとても重要です。 この記事では、プログラミング経験の無い方が陥ってしまいがちな、ソフトウェア開発にまつわる誤解について考えてみました。 Harry Potter is Ready for Divination / weekbeforenext 誤解：既にあるソフトウェアを流用し
状態遷移表を使用したテスト手法【前編】
状態遷移表による設計手法について解説。今回は「状態遷移表を使用したテスト手法」の【前編】として、ホワイトボックステストとブラックボックステストについて詳しく解説する。 はじめに 組み込みソフトウェアが抱える一番の課題は「設計品質の向上」です。本連載の主役「状態遷移表」であれば、“イベント”と“状態”の全ての組み合わせを捉えることができるため、「モレ」「ヌケ」のない品質の良い設計が可能です――。ということで、これまで状態遷移表設計手法について詳しく解説してきました。具体的には、“要求分析モデル”“設計モデル”“状態遷移表からの実装”などのテーマを中心に、その設計手法を見てきました。 ご存じの通り、組み込みソフトウェア開発において、“手戻り作業”は非常にコストが掛かり、とても非効率なものです。そのため、前工程で不具合要因をきちんと抑えることが重要です。ただし、不具合が前工程で抑えられたからとい
Git & GitHub & kintone でウルトラハッピー！ - Cybozu Inside Out | サイボウズエンジニアのブログ
６歳と３歳の娘がいる山本泰宇（@ymmt2005）です。こんにちは。 いきなりですが、悔しいです。なにがって、@DQNEO さんが最近書かれた記事「必殺！Github導入に向けて上司を説得する時に使える資料まとめ」に載り損ねてしまったからです。 サイボウズでも Git と GitHub Enterprise を導入しています。導入や運用の助けになる資料やツールを作ったりして、とても便利なのでいずれ公開したいなと思っていたんです。忙しさにかまけて後回しにしていたら、出遅れ企業にグルーピングされてしまうなんて（涙） 出遅れてしまった以上、なにかプラスアルファをお見せするしか名誉挽回の方法はありません。何も失っていないんじゃないかというツッコミはよしてください。こうなったら恥も外聞もなく Subversion 時代の恥ずかしい過去をさらけ出し、もちろん資料も出して、さらにノウハウを詰め込んだツー
ユーザーのつぶやき(要望)はなぜ1時間で本番リリースできたのか - give IT a try
はじめに 昨日の朝、Twitter上でこんなやりとりがありました。 youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— yoh nakamura (@yohhatu) October 31, 2012 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は分かっても「年」までは表示されていないので、ちょっと困った #youRoom— Ryutaro YOSHIBA (@ryuzee) October 31, 2012 やりましょう。 RT @ryuzee: 困ってないで@kuranukiさんに要望を伝えれば… RT @yohhatu: youRoomをメモ代わりとして使うこともあるんだけど、書いた月日は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub（後編）。GitHub Kaigi 2014
ソフトウェア開発の実際