本連載は、ちょっととぼけた女子高生の姉妹が今注目のアジャイル開発手法である「スクラム」とプロジェクト管理ソフトの「Redmine」を使って、システム開発をするというフィクションです ■ 登場人物の紹介
みなさんこんにちは。@ryuzeeです。 SlideShareを徘徊していたところ自動テストと手動テストに関する良いスライドがあったので、翻訳して公開します。 ライセンスはオリジナルに準じてCC BY-SA 3.0とします。 内容としては、僕自身も一貫して主張しているテスト自動化の必要性の話で、主に以下の観点で記載されています。 作業量とコスト再利用性ユニットテストによる良い設計への誘導手動テストのリスクリスクマネジメント書き方が若干極端な箇所もあると思いますが、全体としてはかなり分かりやすいのではないでしょうか。 なお、テストの自動化に際しては、必ずしも全てのテストを自動化「しなければならない」わけではありません。 スライドではROIの例があがっていますが、テストの自動化のコスト>手動コストの1回あたりのコスト×実行回数になる場合もあり得るので、ROIやテスト自動化によって得られる効果に
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです(Slideshareはこちら)。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入&運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
Henrik Knibergさんのブログで「One day in Kanban land」という記事を見つけました。そこでは、かんばんの使い方のポイントがうまく描かれたマンガが紹介されています。各国語に訳されているので、ヘンリック氏に許可をいただき、日本語訳してみました。 赤い人がプロダクトオーナー(PO)の役割で、青い人たちが開発チーム(DEV。ここでは2名ずつ2チーム)、緑の人がテスターだと思います。テスターチームはデプロイまで担当しているみたいですね。 また、「TODO」「開発」「デプロイ」という各ステージにはWIP(Work in Progress:仕掛り作業)が制限されています。WIP制限とは、各ステージにWIPの数以上のカードを貼ることができないというルールです。
競合してコミット出来ない時には 複数のメンバーで開発を行っている時には、1つのファイルを同時に2人が編集していると言う事もあると思います。 TortoiseSVNでは、同一ファイルを複数人が編集した状態であることをコミット時にエラーとして教えてくれ、一方のデータが消えてしまうことを防ぎます。 ここでは、競合のエラーの解消方法を記載します。 前提 sample.txtを同じプロジェクトのmember1とmember2が同時に編集。 member2が先にコミットを行った。 member1がsample.textを編集し、コミットを行おうとしたところ、以下のようなエラーが表示。 解消方法 TortoiseSVNでは、自動的にマージ(結合)する機能を持っていますが、どのように結合すべきかTortoiseSVNが判断出来ない時はマージツール等で手動で結合する必要があります。 まずは、自動的にマージ(
プロダクト ロードマップのプレゼンテーションは開発者とプロダクト マネージャーの双方にとって、いらいらさせる展開になる場合があります。片方はビジョンを描くことに懸命になり、もう片方は自分たちの作業に影響を及ぼすことになる未知の部分がわかるまで様子をうかがいます。 開発者として仕事をしていた頃、私はこの葛藤を感じ、プロダクトマネジメント担当が作成したロードマップを不満に思っている自分に気づくことがよくありました。その決定に完全には同意しておらず、多くの場合、計画会議の後「納得いかないが、これが上層部の考えなら仕方ない」という気持ちで会議室を出ました。もっと感情が高ぶっているときには、「自分たちで考えて、このロードマップを開発作業に合ったものにしなければだめだ」とさえ感じました。 問題は、私が NIH (Not Invented Here (ここで発明されたものではない) 症候群) にかかって
ホットペッパービューティーで開発を担当している須藤です。 ホットペッパービューティーは近年著しい成長を見せている、リクルートライフスタイルの主力サービスの一つです。 当然システムもエンジニアの体制も大規模で、開発チームはエンジニアだけで100名を超えています。 しかし、その急激な成長故に、いろんなところで歪みが生まれているのもまた事実です。 ホットペッパービューティー開発チームは、「開発スピードがビジネス要求に遅れを取ることがあってはいけない」を合言葉に、様々な改善活動を行っています。 ホットペッパービューティー開発チームのインセプションデッキから引用 今日はそんな取り組みの中から、私のチームで実施しているものをいくつか紹介したいと思います。 チームビルディングで大切にしていること 最初に、私がチームビルディングする際に、常にチームに意識してもらうよう心がけている価値観をお話します。 常に
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
フリーを経てwebプログラマ。Ruby on Rails, Python, CoffeeScript, TDD, BDD, Lean, Agile, スモールビジネス, 機械学習, 人工知能, 投資, FX, 酒, 歌など。エンジニア出身の起業家になってもっとエンジニアを幸せにしたい。 こんにちは!ITプロパートナーズ編集部です。 弊社では、エンジニアの方の起業やフリーランスのご支援をしています。 phpについての週2日から可能な案件も豊富に取り扱っていますので、是非気軽にご相談いただければ幸いです。 webアプリケーションを作りたいけど、プログラミング未経験という方にとっては、PHPはとっつきやすいプログラミング言語の1つといえるかもしれません。 初学者の方にとって最初のハードルとなるのが、PHPが動作する環境を整えることでしょう。 使っているパソコンのOSなど環境に依存することで、入門
In an attempt at damage control, the CEO of the equity management startup Carta, Henry Ward, today emailed customers, telling them that if they are concerned about “negative press” tied to the out In the Lego-like world of Roblox, about a hundred blocky avatars march through a lamplit street, wielding Palestine flags that are larger than their own animated bodies. Characters dressed like cartoo
2012/12/22(土)の社内で開催した「プレゼン祭り」で発表した内容です。アジャイルに全く触れたことが無い人を対象にしたつもりが、「難しい」「内容が盛り沢山で覚え切れなかった」「寝ちゃった」などなどとあまり好評ではなかったのですが、自戒の念も込めて公開しておきます。 対象は「ウォーターフォール開発しか体験したことのない経験5〜6年程度の若者」です。 ※2022/04/11追記 Speaker Deckに移行しました。 https://speakerdeck.com/takigawa401/toriaesu30fen-tehitotoorifen-katutaqi-nihanareruasiyairuru-menRead less
海外ではなぜアジャイル型開発が普及しているのか、IPA(独立行政法人情報処理推進機構)が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 (非ウォーターフォール型開発の海外における普及要因編)」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く