Phacility - HomePhabricator is a set of tools for developing software. It includes applications for code review, repository hosting, bug tracking, project management, and more.
私、スクラムを分かってませんでした 〜Jim Coplien氏のScrum Master 研修を受けて 1〜 - エンジニア的なネタを毎週書くブログ
社内で、Jim Coplien氏による、2日間のスクラムマスターの研修を受けさせてもらう機会をいただきました。先週のJavaOneに続いて、会社からすごいお金と時間を出してもらってるなぁ…自分。 なかなかショッキングな内容も多く、整理するのに時間がかかりましたが、まとめと、今後のアクションを書いていきたいと思います。 用語：PBIとSBI 初めに今回覚えた用語を二つ。PBIはProduct Backlog Item, SBIはSprint Backlog Itemの略です。 概念的にはすでに馴染みのあるものですが、PBI、SBIという呼称は今回始めて知りました。 私は「スクラム」を理解していなかった さて、本題です。研修の一番冒頭で、Jimから、スクラムのたった一つの約束が紹介されました。 "It promises only that the team will work on the m
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
＠ITイベントカレンダー
平素よりイベントカレンダー＋ログをご利用いただき、誠にありがとうございます。 イベントカレンダー＋ログは「IT・製造業・ビジネス関係のイベント（セミナー・展示会・勉強会・コンテスト・Webイベントなど）を開催する企業・コミュニティが登録したイベント情報のポータルサイト」として約7年間運営をしてきました。これまでサービスを続けることができたのは、イベントカレンダー＋ログのコンセプトに共感をいただき、適切なイベント情報をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、イベント情報の入手方法の多様化やイベント紹介サービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年6月30日（火）15:00をもちましてイベントカレンダー＋ログのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知ら
Microsoft Team Foundation Service 入門
プログラミング生放送勉強会 第22回＠松山での発表資料。 http://pronama.jp/22Read less
YAPC::Asia 2013 / Github によりバザールモデルへ - naoyaのはてなダイアリー
ブログを書くまでが YAPC、ということなので、書きます。 初日「モダンPerlリファクタリング」 自分は20分枠で 「モダンPerlリファクタリング」という題で話しました。スライドは以下で公開してます。 https://speakerdeck.com/naoya/modanperlrihuakutaringu-number-yapcasia 今回、思いの他 CI やテストに関する発表が他に多くてそれらに比べると基礎的な内容に終始しちゃいましたが と @t_wada 御大よりお褒めに与ったので個人的には満足です。 リファクタリングはテストさえ書ければその半分以上は終わったことになる、ただしテストはテストを書くことそのものが主目的になりすぎないように。そして書いたテストはとにかく計算機を利用して頻繁に実行しましょうということが言いたかったのですが、意図通りに伝えられたんじゃないかなと思う。
ソフトウェアは完成しても価値はない 〜 アジャイル開発は何を解決するのか | Social Change!
「アジャイル開発を、お客さまに導入してもらうにはどうすればいいですか？」 そんな相談を受けることがあります。私はどんな優れた提案も相手にニーズがなければ通らないことを知っています。喉が渇いていない人に水を売ろうとしても売れないのです。そもそも提案する前に、まずはニーズに気付いてもらう必要があります。そして、そのお客さまは、本当にアジャイル開発に対するニーズがあるのでしょうか。 私の考えるアジャイル開発の本質は「アジャイル開発では当初に想定した機能を”全部”つくらない」ことだと考えています。（参考記事：アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは） この「全てを作らないことで、変化に対して柔軟に開発していく」というソリューションを求めるニーズがあるのであれば、アジャイル開発のメリットを伝えれば採用されることでしょうし、そういうニーズがなければ、何を言っても受け入れられま
ITS/BTSは進捗管理に使えるのか - SIの現場で使えるチケット駆動開発 - arclamp
2013年8月24日にグロースエクスパートナーズ主催にて「SIの現場で使えるチケット駆動開発」というセミナーを実施させて頂きました。「チケット駆動開発」の共著者である阪井誠さん（@sakaba37）をお招きしたものです（togetter）。 僕は基調講演で「チケット駆動で加速する、顧客と協業するプロジェクトマネジメント」を話しました。主にプロジェクトマネジメント論の中でチケット駆動の適用箇所について話をしています。 チケット駆動で加速する顧客と協業するプロジェクトマネジメント from グロースエクスパートナーズ株式会社/Growth xPartners Incorporated. 僕はアジャイルでもウォーターフォールでもプロジェクトに合ったものを選べばいいと考えています。どちらの手法にもメリットがありデメリットがあります。ただ、どちらの手法にしてもチケット（駆動）は有用なツールです。SI
ブラックボックステストとホワイトボックステスト | DevelopersIO
テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装（コード）を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか？ それともブラックボックステストでしょうか？ 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行
顧客を満足させ続けるプラクティスについて
【SQiP 2014】継続的システムテストについての理解を深めるための 開発とバグのメトリクスの分析 #SQiP #SQuBOK
業務システムの開発ツール・ベンダー13社が 共同で「超高速開発コミュニティ」を旗揚げ | IT Leaders
システムは「つくる」から「使う」──。多種多様なパッケージやSaaSが提供される今、よく言われることだが、どっこい、作るシーンがなくなったわけではない。パッケージやSaaSは、どの企業にもある標準的な業務には適合しても、そうでない業務も多い。基幹システムの使い勝手を高める周辺システムや、特定の部門だけが使う業務システム、例外処理が少なくない中堅・中小企業のシステムなどがその例である。スマートデバイスの普及などでIT化が広がる中、作るニーズはむしろ増えている。 こうした分野に向けたシステム開発ツールを提供するベンダー13社が8月6日、共同で「超高速開発コミュニティ（会長：関隆明氏）」という団体を旗揚げした。決して分かりやすいとは言えない各社のツールがどんな用途に適するのか、ツール相互の関係はどうか、どう利用すれば効果的なのかといったことを、個々のベンダーの立場を超えて議論・検証・公開。その上
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
Ruby on Rails を勉強しない方が良い100の理由 - @ledsun blog
はじめに 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyappを読みました。最初ツッコミどころが凄い*1なと思ったんですが、二回読んでちょっと思い当たる節があるなと思ったので書きます。 Rails を勉強しない方が良い理由 Railsにはscaffoldがあるので間口がすごく広いです。実際それを紹介した 15m intro video*2 が理由で人気を博しました。が、奥行きが深い。どこまで学べば「Railsを使いこなせます」って言えるのかまるでわかりません。 鉄板作法が共有されていない 2005年に出てきた割に意外に鉄板作法が共有されていません。 たとえばビジネスロジックをどこに置くのかについては以下のような議論があります やはりお前らのMVCは間違っている Rails の
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。 それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。だからといって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。 広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。 そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。 アジャイル開発では機能を全部つくらない これまで私の中で、アジャイルと言えば当たり前の前提がありました。それは
ビッグデータ時代のソフトウェアメトリクス - ソフトウェアアナリティクスとは：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
IEEE Softwareという雑誌でsoftware analyticsという分野に関する特集が組まれています。当初は1号分の特集の予定だったそうですが、2号に分けることとなったそうです。2013年7, 8月号の特集記事のタイトルは以下のとおり。ここに7, 8月号全体の目次があります。 T. Menzies, T. Zimmermann: Software Analytics: So What? R. Musson, J. Richards, D. Fisher, C. Bird, B. Bussone, S. Ganguly: Leveraging the Crowd: How 48,000 Users Helped Improve Lync Performance O. Baysal, R. Holmes, M. W. Godfrey: Developer Dashboards: T
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー: 森崎修司 (著), 日経SYSTEMS (編集): 本
モデリングもしないでアジャイルとは何事だ
Amazon.co.jp: リーン開発の現場 カンバンによる大規模プロジェクトの運営: Henrik Kniberg (著), 角谷信太郎 (翻訳), 市谷聡啓 (翻訳), 藤原大 (翻訳): 本
Hatena Blog Development Flow
Reactive Programming as an Emerging Trend
