UIデザインの決定プロセスをより高速化するために、会議するのをやめました。会議をやめたことでより多くのフィードバックを得ることができ、デザインの修正コストを下げる事ができました。Read less
UIの話は会議室でするな
UIデザインの決定プロセスをより高速化するために、会議するのをやめました。会議をやめたことでより多くのフィードバックを得ることができ、デザインの修正コストを下げる事ができました。Read less
Kenn Ejima on Twitter: "おぉ、これは全くの同意見だ。ソフトウェア開発においてラストスパートは諸悪の根源、スタートダッシュこそ重要。だから、「締め切りを守る」より「2週間を超える長い締切りは（意味がないので）設定しない」ほうが戦術レベルでは有効と感じてる。 http://bit.ly/caqtxI"
おぉ、これは全くの同意見だ。ソフトウェア開発においてラストスパートは諸悪の根源、スタートダッシュこそ重要。だから、「締め切りを守る」より「2週間を超える長い締切りは（意味がないので）設定しない」ほうが戦術レベルでは有効と感じてる。 http://bit.ly/caqtxI
Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
Redmine Backlogsプラグイン カスタマイズ - こくぼ＠Everything is the experience.
うちの会社用にカスタマイズしてるのを公開してます。興味あったら試してみてください。 https://github.com/YusukeKokubo/redmine_backlogs ざっくりとしたカスタマイズのポイントとしては Task Board タスクの移動時に注記を入力できるようにした 本当はwindow.promptじゃなくてちゃんとしたポップアップを作りたい 終了してるストーリーとステータスを背景色でわかるようにした アバターを表示 タスクの入力項目から優先度を削除して代わりに予定時間を追加 終了したタスクは溜まると縦に長くなるのでギュッと表示するようにした 担当タスクのフィルタリングをできるようにした Master Backlog Backlogs管理外のトラッカーのチケットもMaster Backlogから参照できるようにした ストーリーのステータス選択の選択項目はプロジェク
Redmineのアジャイル開発用プラグインBacklogsの導入 | VASILY TECH BLOG
はじめまして。 梅雨で頭がモジャモジャしはじめてきた天パエンジニアの福本です。 さて、VASILYではアジャイル開発の導入を進めています。 前回は、デプロイ自動化の話でしたが、今回はタスク管理についてです。 アジャイル開発ではストーリーカードやタスクボードなどを使用する事が多いですが、それらをWEB上で管理できるツールを導入しました。 Backlogsプラグイン アジャイル開発用のタスク管理ツールを探してみると、BacklogsというRedmineのプラグインが評判もよくシンプルで使いやすそうでした。 タスク管理にRedmineを使用していていた事もあり試してみた所、使い勝手が良かったので紹介します。 全体的な操作感としてはAjaxを多用していて直感的でサクサク動くのが気に入ってます。 プラグインを導入すると通常のプロジェクト画面にBacklogsとReleasesというタブがあ
NOV1975のブックマーク / 2013年4月2日 - はてなブックマーク
「カラオケ秘史」 カラオケ秘史―創意工夫の世界革命 (新潮新書) 作者:烏賀陽 弘道新潮社Amazonを読んだ。 非常に面白かった。 初めて読むことばかりだが、カラオケが広がった時代を生きていたこともあり、自分の記憶が上書きされた。 カラオケは、１）カラオケ装置 ２）カラオケボックス ３）通信カラオケという三段階の発明を経て一般に定着したのだが、そのことはあまり知られていない。 特に通信カラオケが、ブラザーのソフトウェア自販機「TAKERU」を「インフラ」として活用し作られた秘史が凄まじい。 「TAKERU」自体は商業的にはほぼ失敗で、撤退を余儀なくされていたのに、その技術者の先見により「カラオケの音楽情報（MIDIデータ）の中継サーバ」として変更され、会社の幹部も知らない内に力を発揮していた、という。 その「TAKERU」を中継サーバにして作られたカラオケ装置が「JOYSOUND」だった
私がアジャイル崇拝をやめてウォーターフォールを愛するようになった7つの理由 - カイゼンにっき。
アジャイルがダメだと思う7つの理由 - arclamp にインスパイアされて、自分なりの考えをまとめてみました。一部SI前提で書いています。 制作（および詳細設計・結合テスト）フェーズの全体スケジュールを見通しやすい 確かに、全体スケジュールの完全なコミットメントは不可能です。しかし、少なくとも、信頼性の高い見通しは必要です。そもそも予算が下りません。顧客側組織の予算編成・執行体制を変えるべきだ、何て寝言を言えるはずもありませんし、見通しもなしに予算を出すべきだとも思えません。 ウォーターフォール型の開発プロセスでは、開発プロジェクトの大部分を占める制作（および詳細設計・結合テスト）フェーズの全体スケジュールを、先行する計画・設計のフェーズでじっくりと吟味します。 ウォーターフォール型の開発プロセスは、問題があった時に調整が効かないかのように言われています。しかし、ウォーターフォールにはフ
ウォーターフォールとアジャイル開発の比較
DeClang 誕生！Clang ベースのハッキング対策コンパイラ【DeNA TechCon 2020 ライブ配信】DeNA
アジャイルの「ライトウィング」と「レフトウィング」：An Agile Way：オルタナティブ・ブログ
アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人との会話のプロトコルと協働関係を作るしかけだろう。自分の現状を、アジャイルに変えるためには、どうしたらよいだろう？ "最近、「アジャイル」といっても中にいろんな要素があるために、「あなたのアジャイルは何のことを言っていますか？」と聞くことからはじめないと、話がかみ合わない"、と、Agile2012帰りのかわぐちさんと話していて、そのときに、かわぐちさんが描いた絵（たぶんどこかにある４象限の図）がいまひとつ自分にしっくりこなくて、私が描いて見た絵がこの絵だ。 あなたが、現状の開発現場を「アジャイル」に変えたい、と考え
永和システムマネジメント アジャイル開発支援事例｜株式会社ネクスウェイ
ネクスウェイ システム推進室 松森正彦 氏、小田切一成 氏 に、永和システムマネジメントのアジャイル開発支援サービスを採用した経緯と評価について詳しく聞きました。 第一部： 「アジャイル開発指導を取り入れて、ヒット商品の開発に成功」 第二部： 「NEXLINK BASICがヒット商品になった本当の理由」 第三部： 「『開発を一度ストップする』という決断」 第四部： 「プロジェクトマネージャーは知っておいた方がよい、アジャイル開発の影の部分」 ネクスウェイについて ネクスウェイは、ソフトウエア、FAX、メールなどを通じてBtoBマーケティング支援する企業です。主な商品は、NEXLINK、eオンデマンド便サービス、e帳票-FAXサービスなど。年商249億円、取引法人 約8000法人、従業員数249名、創立は2004年10月。 NEXLINK BASICについて NEXLINK BASICは企
なぜリリース頻度を上げるのか
サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり
アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの？」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ！」「君自身が編み出
チケット駆動開発 - Wikipedia
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。 はじまり[編集] チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた[3]。そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。 チケット駆動開発は、まちゅ氏のITpro Challenge のライトニングトーク「もう
Home | Scrum Guides
Download the official Scrum Guide in over 30 different languages Select language & Download Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s accountabilities, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and p
ストーリーポイントの見積りは何故時間の見積りより良いのか
みなさんこんにちは。@ryuzeeです。 よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら 左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性 ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。 新たな興味深い調査結果が公開された。 ス
要件におけるユーザーストーリーの利点 - winplusの日記
これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人
＠IT：連載：【改訂版】初歩のUML
ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。 筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。 では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UML
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発見積りの 基本的な考え方.pdf
要求開発×アジャイル開発×ドメイン駆動開発
