Playwrightのベストプラクティスを翻訳してみた
Playwrightの公式ドキュメントに「Best Practices」というページがあったので翻訳してみました。 原文： Best Practices | Playwright イントロダクション このガイドは、私たちが提供するベストプラクティスに習い、より弾力性のあるテストを書くために役立つはずです。 テスト哲学 ユーザから見えるふるまいをテストする 自動テストは、アプリケーションのコードがエンドユーザのために動作することを検証するものです。関数の名前、何かが配列であるかどうか、ある要素の CSS クラスのような、ユーザが通常使用しない、目にしない、あるいは知ることさえないような実装の詳細に依存することを避けるべきです。エンドユーザーはページ上でレンダリングされたものを見たり操作したりします。したがって、自動テストでは通常、レンダリングされた出力のみを表示/操作する必要があります。
アジャイル開発に関係ありそうな日本語資料ベスト50
1位もリーンスタートアップネタ。わずか10枚の資料が1位ってのが熱い。 6位から50位まで こうやってみるといろいろあって面白いですねぇ。スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!は自分の環境にあわせた感が素敵だし、AgileJapan2010 佐賀県庁でもできる！プロジェクトファシリテーションは、何回みても面白い熱い物語だし、「納品のない受託開発」にみるソフトウェア受託開発の未来は講演を2〜3回見ているけど、何回聞いても面白かった。 33729viewsUXのためのUIデザイン 31199viewsふつうの受託開発チームのつくりかた 28019viewsAgileJapan2010 基調講演：野中郁次郎先生による「実践知のリーダシップ～スクラムと知の場作り」 27941viewsProject Facilitation From Hiranabe
Redmine Backlogsで簡単スクラム！プロダクトオーナーとして使う編
前回、インストールまで終わったので、使い方を考えながら調べてみる。僕は認定スクラムマスターではないので、間違った認識があれば教えてくれるとうれしいです。 その前に、最近日本語化ファイルを作ってくださったかおるんさんのロケールファイルをRedmineのBacklogsプラグインを使ってみた via かおるんダイアリーからGet！ まずは、Redmine Backlogs :: Usage Product Ownerを参考に、プロダクトオーナーとしてのRedmine Backlogsプラグインの使い方を調べてみる。プロダクトプロダクトオーナーの役割についてはこちらを参照のこと。下の図でいうとプロダクトバックログの整備がメインの運用となる。 Scrum Process via Lakeworks in the Wikipedia プロジェクトメニューのBacklogsをクリックするとMaster
Redmine Backlogsで簡単スクラム！スクラムマスターや開発チームとして使う編
Scrum Process via Lakeworks in the Wikipedia 前回はプロダクトオーナとしての使い方を調べてみた。今回は、スクラムマスターの使い方をRedmine Backlogs :: Usage Scrum Masterを元に調べてみる。 スプリントバックログは、プロダクトバックログの上からチームのベロシティ分選択していくだけでよく、選び出されたストーリーにポイントを付け、スプリント内でストーリーが消化されるようにチームを支援するのがスクラムマスターの仕事になる。上の図だと全体にかかわるお仕事なのだが、Redmine Backlogsではスプリントバックログやスプリントが、舞台の中心になるのだと思う。 スクラムマスターとして使う ストーリーの調整はプロダクトオーナーともチームとも相談する必要がある。Backlogsではスプリントごとのベロシティも簡単に確認する
数千人が利用する楽天Redmineの過去と未来 #47redmine
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
Redmineが1000人のエンジニアに使われるまでのこと
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
Redmineプラグインを作るなら読むべき本家チュートリアルの日本語訳
Redmineのプラグインを作りながらRailsのテスト方法を学ぼうと思ったら、プラグインの作り方すら完全に忘れていたので、備忘録としてredmine.orgのPlugin Tutorialを訳してみる。これを読めばRedmineプラグイン作成が簡単にできるはず。 注意：チュートリアルを活用するにはRedmineのr1786以上が必要とのこと。 プラグインを作成する プラグインを作るときは、様々なコマンドを利用する必要があるので、パスを通しておくとよい。 https://gist.github.com/daipresents/cd8c75cbe343487bfa7968ee231b6589.js?file=gistfile1.txt Redmineのプラグインはプラグインジェネレータがあるので、ジェネレータを使って雛形を作成する。コマンドの構文は以下。 https://gist.githu
スクラムでつながる実践アジャイル – Scrum Boot Camp 横浜 #scrumbc
Scrum Boot Camp 横浜に参加しました。たくさんのコーチ陣に囲まれてのワークショップは楽しかったです。また、いろんなつながりによって「はじめましてな人」「ひさしぶりな人」にもお会いすることができました。こういった場を提供してくださった@ryuzeeさんはじめ、皆様ありがとうございます。 今回のブートキャンプでは、アジャイル開発の基礎からスクラムの概要。そして、スクラムで登場するツールやプロセスをワークショップで体験し、理解を深めていく内容でした。私は、書籍を読んで現場でTry and Errorを試していた「野良スクラムマスター」なので、こういう場でコーチの説明を聞くことにより、「自分との差分」「理論の裏付け」など、いろいろと発見することができました。本からは読み取れない部分を学べるのがワークショップの醍醐味ですね。
詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
Redmineでアジャイルチームのスピードやパワーを見える化する
burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか？チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
