テスターが要件定義のレビューからプロジェクトに参加する現実について｜Tsuyoshi Yumoto
最近、ソフトウエア開発にて、テスト技術者が要件定義からレビューに入る件について、いろいろ話を聞いたので、まとめておきます。 これは、ちょっとかっこよく言うと「Wモデル」という、テスト担当者の作業と開発の作業を同時並行で行っていくVモデルの進化した開発モデルが目指すゴールの一つです。ただ、話をしてくれた人は、Wモデルという言葉を知っているわけではありません。 その人の組織では、1980年代後半から、独立したテストを行っているとのことです。開発したものの統合テスト以後のテストだけを請け負うテスト専門部隊です。 Windowsが出る前はCOBOLで作った会計プログラムを対象にしていて、それがWindowsが出たころに全てWindowsアプリになり、それが今では全てWebアプリになり、クラウド上で動くようになっているという感じです。今では、そこの組織では、要件定義の段階からドキュメントをテストチー
難易度は？ 効果は？ 実践して初めて分かった「ペアプログラミング」の実際
この20年ほどの間に、「ウォーターフォール」へのアンチテーゼとして現れた、XP（エクストリーム・プログラミング）やScrumと呼ばれる「アジャイル」な開発手法が浸透してきた。中でも、近年ではXPの一部を構成する「ペアプログラミング（ペアプロ）」に対する関心が高まりを見せているようだ。ただ、ペアプロという手法があることを知ってはいても「どのように導入を進めれば良いか」「どのような効果があるのか」については、漠然としたイメージしか持っていないという人も多いのではないだろうか。今回、Yahoo! JAPANのヤフオク!カンパニーにおいて「Lean XP」の一部としてペアプロを導入した山下真一郎氏と、日本におけるテスト駆動開発（TDD）の第一人者である和田卓人氏に、自らの実践の中で感じているペアプロのメリットや、導入のポイントについて語ってもらった。 「Lean XP」の一部としてペアプロの導入に
Android アプリのリソース定義ポリシーを整備した話 - クックパッド開発者ブログ
前回のあらすじ その後発生した様々な問題 トップ画面の大規模変更 画面ごとの Style の乱立 Style 定義の度に質問が飛んでくる 改善に向けて 実際の定義ポリシー Color Dimen Style 再利用性を高めるために 継承の仕組み parent 指定による継承 名前による継承 クックパッドにおける Style 定義のポリシー TextAppearance Base TextAppearance の定義 TextAppearance の定義 まとめ 技術部モバイル基盤グループの児山(@nein37)です。 モバイル基盤グループではモバイルアプリの開発だけでなく、開発環境の整備や開発効率の向上も重要な目的の一つとしています。 昨年、開発効率向上の一環として行っているアプリのリソース整理の取り組みについてAndroidアプリのリソースを整理して開発効率を改善した話という記事で紹介さ
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
一休での開発における改善の取組み /devops-at-ikyu
4/28(金) にDevOps推進協議会 で講演したときの資料です。
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
mobster - マルチプラットフォーム対応のモブプログラミングタイマー MOONGIFT
モブプログラミングはペアプログラミングの次の形、チーム全員が同じ問題に対して同じ時に同じ場所で取り組むというものです。実際にコーディングするのは一人なので、他の人たちは自分の考えを言語化して説明しなければなりません。 そんなモブプログラミングを行い際に使えるツールがmobsterです。Web技術によるモブプログラミングタイマーです。 mobsterの使い方 設定画面です。 こちらは休憩時間です。 mobsterではチームのメンバーを登録し、決まった時間ごとにアラートが表示されます。そうしたら作業する人が代わって再度モブプログラミングを開始します。休憩時間の際には格言的なものも表示されるようになっています。チーム全員で集中して作業に当たるのは、ついついサボりがちな方にとっては良いことかも知れません。 mobsterはElectron/JavaScript製のオープンソース・ソフトウェア（MI
インタビューに関する記事
Unity入門に最適なチュートリアルサイトまとめ・比較今回はUnityでのゲーム開発を始めるときに参考になる、入門チュートリアルサイトをまとめました。全くプログラミング初心者の方から、他のプログラミング言語で開発をしたことがある方を対象にまとめています。 入門に最適！C++を学習できる無料サービス10今回は、C 言語を無料で学習できるサービスをご紹介していきます。C をこれから学習したいと思っている方や初心者はもちろん、既にCを習得しているという方も、復習してみてはいかがでしょうか？ 入門に最適！C言語を学習できる無料サービス10今回は、最もメジャーなプログラミング言語の1つでもある、C言語を学習できる無料サービスをご紹介していきたいと思います。C言語初心者でも安心して使えるおすすめのサービスをまとめているので、ぜひ参考にしてみて下さいね。 フォロ爆の方法・やり方・ツール紹介｜iPhone
"High 意識 Android Team" のチームワーク – その 1 | メルカリエンジニアリング
Mercari Android チームの @tsuyogoro です。US 版 Mercari Android アプリの開発を担当しています。 今年 1 月に弊社で開催した Mercari Day 2017 において、我々 Android チームは 「High 意識 Android」というお話をしました。 これから数回に分け “High 意識な開発” の実例を紹介していこうと思います。 本シリーズ第一回目では、”ベースにしている考え方” と “東京とサンフランシスコで one source 開発を行った話” を紹介します。 公安 9 課モデル 我々の間には、チームプレーなどという都合のよい言い訳は存在せん。 有るとすればスタンドプレーから生じる、チームワークだけだ。 荒巻大輔, 2002 我々は自分たちのチームワークを “公安 9 課モデル” と名付けており、”各メンバーが最高のスタンドプ
開発手法を学ぶことに意味を感じない件について - ボクココ
ども、@kimihom です。 開発手法について議論されたり、発表するような場があったりする。例えば “弊社ではアジャイル開発手法を用いて最先端の開発を実践しています。” 的な話ね。最近はアジャイルじゃなくて何て言うのかよく知らないけども。 それらの話に関してなぜ私が意味を感じないと思うのかを書いていこうと思う。 事前に一つ注意していただきたいのは、私は開発手法に関する話は1,2冊程度しか読んだことがない。だから開発手法を極めればこんなことができるようになる！みたいなのは是非教えて欲しい。開発手法に関する本を読んで、それが全く見えなかったから興味が沸かなかったので。 それより実際に開発しようぜ 基本的にあまり開発をしない方々が、開発手法に関して話しているような感じがする。開発しない立場でチームの開発をとりまとめる立場であるために、何か良い方法を模索している感が漂ってくる。はて開発手法通りに
まとまってない文章を晒すのに抵抗があったけど、メモを垂れ流したら仕事がうまく回りだした件について - CARTA TECH BLOG
Zucks Ad Networkでデータ解析をしています、@yuu_itoです。 気づいたら3月も半ばですね。花粉で目がしょぼしょぼします。 メモを取ることについて書いていきます。 きっかけ 技術調査のために論文を集めGoogle Docsにまとめていた時、 とりあえずまとめた後に共有しますねと連絡したら、 メモはGitHub Issueへのコメントで書いておいたら？というのが始まり。 やってみて気づいたこと まとまっていない状態の文章を晒すことに抵抗があったのですが、やってみると嬉しいことがありました。 1. Issueに気づいた人がコメントをくれる。 弊社ではGitHubとSlackを連携してIssueの更新をSlackに通知しています。 取り組んでいること、考えていることを書いていると 「なんかデータの傾向がイメージと違った」→「それ～だからかも」 「計測しているデータ、不要なものも
ストレスフリーなGitHubのIssue生活 - クックパッド開発者ブログ
こんにちは。サービス開発部の丸山@h13i32maruです。 今日はGitHub/GHE(GitHub Enterprise)で快適なIssue生活をおくるために作ったJasperというツールと、それを実際にどうやって使っているかを紹介させていただきます。 ストレス GitHub/GHEを日々の業務の中心として使っていると、すごくたくさんのIssueやPull Request(以下PR)が流れてきます。 これらのIssueを処理する方法としては主に「メール」と「通知ページ(github.com/notifications)」の2つだと思います。 僕もこれらの方法を使っていたのですが、以下の点ですごく困っていました。 多すぎてメンションされたものやコメントしたものを見逃してしまう あとで見ようと思って、忘れる ブラウザのタブを大量に開いた状態になる 知らないところのIssueで議論が進んでい
RevertとBlameを使いこなして安全性の高い開発を推進しよう
前回の記事ではProtected Branchesの機能を使ってシンプルなGitHub Flowに権限管理の味付けをする方法を学びました。 今回はPull Request単位でのRevertやビジュアルなBlame機能について学びましょう。 GitHub Flowに従ってmasterにマージする前のコードレビューやCIを必須にした運用をしていたとしても、誤ったコミットをマージしてしまい、システムテスト時または本番環境にて問題になることは、珍しい話ではありません。 そんな時に行いたいのがコミットのRevert（巻き戻し）ですが、Pull Requestをベースとした開発を行っていると、このような時にも恩恵をこうむることができます。 Revertとは Revertとはコミットの巻き戻しのことです。たとえば次のようなコードをコミットしたとします。printの出力文字を変更しています。 - pri
尊敬するエンジニア - 旧gaaamiiのブログ
会社の飲み会で酒に酔って、気付いたら個人的に社内で尊敬してるエンジニアの尊敬してる点を話していた。こんなことを挙げていた。 コミットがきれい 全体的に丁寧 技術仕様やソースをちゃんと読む 話してみると、なんでこれらの点を尊敬しているのか考えたくなった。 コミットがきれい -> 作業がひとりのエンジニアの脳内で完結されると困るから だれか一人で全てのプロダクトを担当するわけではないので、ひとのコードを読むこと・自分のコードが読まれることがある。きれいなコードとかクソコードとかいう言葉があるけど、実際にはただのきれいなコードとかクソコードというのは無くて、それが生まれた経緯がある。時間が無くて似たようなコードを抽象化できなかったのかもしれないし、レガシーな仕様に合わせるために命名を不自然にするしかなかった、とか。 そのコミットをするときに１つ１つ決断しなければいけなくて、逆に言うと決断の数だけ
非エンジニアが体験した、働き方としてのスクラムと鉄の規律 - BOOKS & STUDIES LOG ～ 本と勉強会
今日は株式会社アトラクタ主催のスクラムトレーニング(SCRUM BOOT CAMP)に参加してきました。有料講座なので詳細は書けませんが、感じたこと、気付いたことを、徒然なるままに書いていきたいと思います。 スクラムというのは、主にソフトウェア開発で使われる開発手法の一種です。IT系出版社に勤務する身としては、知識としてはスクラムのことを聞き齧っていたのですが、一度目と耳と体でしっかり体験したいと思って、身銭を切って申し込んでみました。永瀬美穂さん、原田騎郎さん、吉羽龍太郎さんという最強の布陣によるセミナーです。創立記念とのことで多分お買い得価格だとは思うのですが、やはりそれなりのお値段がしました。 ワークショップの詳細については触れませんが、座学とワークショップがバランスよく散りばめられた構成でした。一見ゆるふわな感じで進んでいくのですが、緻密な計算の元に組み立てられていて、笑いあり気付
Androidアプリを長く開発し続けるために気をつけている9個のルール - ZOZO TECH BLOG
Androidエンジニアの @nissiy です。Androidが発表されてからもうすぐ10年になろうとしています。長いですね。 実はAndroid版IQON、今年の4月でリリースしてから丸5年を迎えます。ここまで長くサービスを続けられて、かつ3年連続でベストアプリをいただけたのは、使ってくれているユーザーの方々のおかげであると日々感謝しています。 この5年で様々な追加機能の開発を行ってきました。新機能を1つ追加する度に、古い機能を1つ削除することを徹底して開発を進めてきたものの、長く開発を続けているのでそれなりに巨大なアプリになっています。 今回はAndroid版IQONを長く開発し続けるためにチーム内で徹底しているルールをいくつか紹介したいと思います。 当たり前な話ばかりですが、大きくOSのアップデートを繰り返すAndroidのアプリ開発に取っては大事な話ばかりですので、少しでも参考に
「合成の誤謬」を意識せよ｜
メルカリの中で働くメンバーが、日々どのようなことを考え、どのようにチャレンジしているのかを紹介する場として初めて開催した『Mercari day 2017』。 本稿では、アメリカ向けプロダクトのUX改善を担う2人がパネラーを務めた「”メルカリUS”カイゼンの最前線」の模様をお届けします。 テストしてみて分かった、想像以上に違う日本とUSのユーザー行動 メルカリでは現在、アメリカ向けプロダクトの開発に注力しています。このセッションでは、メルカリUSの買い手側・売り手側双方のUX改善の担当者が登壇し、日本のプロダクトとの違いなど、文字通りの「カイゼンの最前線」について語りました。 伊豫： モデレーターを務めます、US版のプロダクトを統括している伊豫です。今回はメルカリUSのプロダクトマネージャー2名と共にお話できればと思います。買い手側（Buyer）のUXを担当している森山、売り手側（Sell
実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
Timely、個人もチームの時間も記録できる時間トラッキングサービス
日中にどんな作業を、どれだけの時間おこなっていたのかを自動的に記録する時間トラッキングサービスには、いくつかの定番があります。 パソコン上のすべての作業をアプリ別、アクセスしているURL別に自動的にモニターしている Rescue Time。設定したプロジェクトに何分従事したかを簡単にメモすることができる Toggl などです。 しかし、これらのサービスはスマートフォンがここまで主流になる以前に開発されたという事情もあって、少し現状に合わなくなってきている部分もあります。 そこで最近注目しているのが、Timelyという、RescueTimeとTogglを足し合わせたようなサービスです。ここに、最近発表された Memory という機能が加わって、スマートフォンとパソコンからの全方位のトラッキングがぐっと現実味を帯びてきます。 Timelyの考え方 Timelyは、記録を取りたいと思っているプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
