アジャイルにおける事前合意について - arclamp
昨年末、ブログをネタにTwitterで議論したことを akipii さんが「アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺: プログラマの思索」というエントリにまとめてくださいました。ありがとうございます！。 ブログで書かれたことに直接の返答にはならないのですが「アジャイルにおける事前合意はどうあるべきか？」ということを書きたいと思います。 アジャイルは最初に全てのCDSを決めない まず、狭義のアジャイル開発プロセスは優れたマネジメント手法です。システム開発を評価するQCDS（品質/コスト/期日/スコープ）ですが、Q（品質）というは「そのシステムにとって問題ないレベルにする」でしかないので、CDSの調整が論点になります。 ウォーターフォール型開発というのは、 「スコープは最初に確定」し、 「コストや期日はスコープを達成するために必要な分を最初に設定」し、 必要
超楽アプリ開発！面倒な開発作業を解消する無料Webサービス10選 - Findy
2016.06.06｜最終更新：2017.11.16 超楽アプリ開発！面倒な開発作業を解消する無料Webサービス10選 自分でも何かアプリを作ってみたいと思ったことがある人は少なくないはず。 でも実際作るとなると、データベースの設定やサービス全体のデザイン、画像の用意などなど必要な作業がたくさんあってかなり大変です。 本記事では、それらの手間を大幅に省いてアプリ開発を効率化してくれるサービスを10個ご紹介します。 1.codic codic Webアプリのコードに使用する変数や関数に適切な名前を付けてくれるサービスです。 変な名前にするとあとで分かりにくくなるので、変数や関数の名付けは地味に大事です。 名付けに困ったら使ってみると良いでしょう。 2.CSSGram CSSGram CSSGramは画像を加工するのに重宝するサービスです。 CSSGramからcssファイルをダウンロードして自
iOSと似て非なるAndroid開発(1) 「iOSと同じで」と言われたら? Android版アプリ開発コストの抑え方【前編】
iOSとAndroidを両開発する場合に、iOSデザインを先行して考えてから、それをベースにしてAndroidに落とし込むというパターンがよくあります。その際、デザインコストを抑えるため、「iOS版のデザインを考えたので、Android版はそれと同じようにしてください」というように、半ば投げやりなまま開発がスタートするケースもあると思います。 しかし、iOSのデザインをそのまま踏襲するということは、Androidの標準にないものはすべて独自で実装しなければならないため、必然的に開発コストが大きくなってしまうということになります。 さらに、無理やりほかのプラットフォームのデザインを持ち込んだことで、Androidのデザインガイドラインから大きく外れてしまった場合は、普段使い慣れないものをユーザーに押し付けることになってしまい、最終的にはユーザーへの負担を増やす結果になってしまいます。 本記事
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> `�kH V z=H V Getting Real The smarter, faster, easier way to build a successful web application Start reading →
今どきのアーキテクチャ設計戦略 - QCon Tokyo 2016
2016年10月24日に開催されたQCon Tokyo 2016での講演「A-3 今どきのアーキテクチャ設計戦略」の資料です。Read less
リンク切れを検知したり、リンク間の関係を可視化するツールをつくった - Qiita
その名も Anomalynks Anomaly(異常) + Link(リンク)の造語。 https://github.com/cloudpack/anomalynks つくった背景と解決できる課題 PM < この前つくったあのサイトやねんけど、ちょっと部分部分きりとって別のサイトにしたいんよねー PM < でも１ページ消したら他のページからリンクされてるの切れちゃってつらみあるからどうにかして💢 ぼく < はい ＞ リンクチェッカーみたいなのつくろう ＜ PM < あとついでにページ間の関係性みたい PM < どうせならデザインチームでもできるように可視化してや ぼく < はい ＞ 可視化しよう ＜ PM < 管理画面とかでログイン必要だから ぼく < はい PM < Seleniumは重いからブラウザの拡張的なのがいい ＞ ChromeExtensionに ＜ PM < ドメインまたぐ
問題解決型UXデザインアプローチ - taninnosorani blog
受託のUXデザインを進めていく中で作業の流れと自分が心掛けていることを記載しています。 基本的なプロセスはHCDやデザイン思考とあまり変わりませんが、ウォータフォールのような受諾型のためドキュメント指向のコミュニケーティングデザインを行いやすいように独自に実践している内容になります。ここでのUXは受託開発で多い問題解決型のUXを扱うため、最近ではむしろ主流とされている顧客開発型のUXとは多少異なります。 問題解決型UXのデザインプロセス 理解 アイディア ストーリー UI ビジュアルデザイン 開発 フィードバック 参考手法 ゴールダイレクテッドデザイン About Face 3 インタラクションデザインの極意 http://hart.herokuapp.com/public/user/yk/book/39 コミュニケーティングデザイン Webサイト設計のためのデザイン&プランニング htt
Shibu's Diary: 僕のプログラマ人生を賭けてITエンジニア本大賞2016に推薦したい本はこれ
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 岩切さんがITエンジニア本大賞の募集をしていました。技術書とビジネス書の2カテゴリがあるんですが、それぞれのカテゴリで、2015年に出会った本で、「やばい、これは10年以上待ち望んでた次の時代の道標になる本だ」というものがあったのですが、清き平等な一票ではこの気持ちは伝わらないと思い、筆を執った次第です。 一応僕のことをあまり知らない人も多いと思うので一応説明しておくと、学生のころに日本XPユーザグループの設立準備から関わっていて、アジャイルという言葉が出る前から「仕様書通りにしかコーディングできない世界つまらなそうだし、XPなんか面白そうだな！」と思っていて、イベント運営をしてみたり、C++やらPythonやらRuby(とちぎ)やらのコミュニティに参加したり、ドキュメントツー
ダレずに開発を走り切る為の習慣
重要なのは、この「煩わしさ」は、「そのタスクを完了した際に、どれだけ体力と意欲を使い果たすか」 の指標であることです。 「技術的には難しくないから、経験の浅い人にまとめてやってもらおう」と、そうした「だるいタスク」を集中させてしまうと、あっという間に人員が疲弊して 最悪離職します 恥ずかしながらこういう経験があります。 「だるさ見積り」した => 予測工数の -5%〜+5% の前倒しor遅延 で済んだ 「だるさ見積り」しなかった => +20%〜40% も遅延した。 終わった後の生産性の低さも本当にもう酷かった。 ごめんなさい。。。。 やろう！『だるさ』見積り！本当に大事だよ！ [見積もり編] 3. OKR を意識したバックログ 具体的には Github の issue サマリを記載していく事柄で実践します Objectives : この PullRequest で何ができてほしいのか サ
フロントエンドのテクニカルディレクションに求められるスキル
フロントエンドのテクニカルディレクションに求められるスキル フロントエンドの多様化が進む中で昨今重要視されているのが「テクニカルディレクション」のスキルセットです。 会社の規模や職域、ビジネスモデルにより求められるスキルセットは異なりますが、中小のWeb制作会社を前提に話をいたします。 ディレクター/フロントエンドエンジニアの作業分担 ケースとしては以下のようなパターンが考えられます。 アサインされたディレクターがテクニカルディレクションを行い、フロントエンドエンジニアが実装を行う アサインされたフロントエンドエンジニアがテクニカルディレクションとフロントエンド実装を行う アサインされたSE/テクニカルディレクターがテクニカルディレクションを行い、フロントエンドエンジニアが実装を行う。 個人的には2のケースでアサインされることが一番多いですが、最近の案件では3のケースで1年ほどテクニカルデ
正しい製品を作る / 製品を正しく作る - ninjinkun's diary
Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節 エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。 というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング（実装）」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。 エンジニアは製品を正しく作る エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。 エンジニアと
Java が支える 人気ニュースアプリ NewsPicks の裏側
JJUG CCC 2015 Spring の発表資料です。
転校生の本歌取 - steps to phantasien
ふと思い出し書き直しの話 (1, 2) の続き。 書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。 この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。 Bazel と補欠たち 一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。 プログラミング言語をまたいだ補欠系書き直しとして真っ先に思い
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
KAIZEN platform Inc. の開発マネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
総務省｜電子政府｜政府共通ルールの策定(標準ガイドライン等)
技術的負債と向き合う
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
hckr news - Hacker News sorted by time
はじめよう! 要件定義 ~ビギナーからベテランまで
