方針に納得できない時のお作法 - Konifar's ZATSU
誰かから方針を共有された時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう 一見して不合理な方針だと感じたとしても、その裏にはそれなりに込み入った背景がありタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかって
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。 The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。 その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも十分である』というようなまとめになっていました。 ではImpact Engineeringってなんなんだよと元記事268% Higher Failure Rates for Agile Software Projects, Study Findsを最後まで読
「バラバラな職場」はどうして作られるのか────チームビルディングのプロに聞く。
「うちの部署(会社)ってバラバラだな」と感じたことはありますか？ 今回は、「分業はバラバラな職場を生みやすいのでは」という疑問をチームビルディングのプロである楽天大学 学長の仲山進也さんにお聞きします。ちなみに仲山さんはAgendの登場2回目。 私たちが「バラバラな職場」にならないよう、どうすべきかを教えていただきました。最後の「まとめ」まで是非お読みください。 仲山考材株式会社 代表取締役 / 楽天グループ株式会社 楽天大学 学長 まだ社員20人しかいない創業期の楽天に入社。楽天市場出店者の学び合いの場「楽天大学」を設立、人にフォーカスした本質的・普遍的な商売のフレームワークを伝えつつ、出店者コミュニティの醸成を手がける。「仕事を遊ぼう」がモットー。
あなたのおっしゃるレビューってどのことかしら？ - Qiita
ソフトウェアのレビュー ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。 人は間違いを犯しますし、間違った本人よりも他人のほうが誤りを見つけ易いものです。 ここまでは、認識を共通できるものでしょう。 しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。 ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。 しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。 ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。 しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。 プロジェクトを初めて、レビューといった場合、
忍者式テストをやってみた - @ledsun blog
忍者式テストを二週間くらいやってみた感想です。 忍者式を見習って毎日一時間手動受け入れテストの時間を確保してみた。 「受け入れテストを徐々に増やしていく」感覚が新鮮。 「受け入れテストはテストフェーズの最初に一度に作るもの」は思い込みだった。— ぎゃばん (@ledsun) 2014年6月27日 忍者式テストとは 那須のKent Beckと呼ばれる隠者が発明（発見？）したテスト手法。 特徴をあげると 毎日、手動でテストを行う テストをペア作業で行う 実施のたびにテスト項目を見直す テスト項目の粒度は受け入れテスト 初めてこの手法を知ったのは2005年だったと思います。 当時、自社開発ソフトウェアの結合試験の真っ最中でした。 「バグの発見漏れは減るだろうけど、どうやって導入すれば？？？」と、 使えそうなのに手が出せなく、もどかしい思いをしました。 導入方法の謎 何年経っても導入方法が分からな
さよならスプレッドシート Azure DevOps の Azure Boards でスクラム開発一元化！（前編） - ecbeing labs（イーシービーイング・ラボ）
目次 本記事は前編と後編に分けてお届けいたします。 前編と後編を合わせた記事の目次は以下の通りです。 前編 はじめに Azure DevOps について スクラム開発をAzure Boardsで管理する プロジェクト作成時にプロセスを設定 ポートフォリオバックログどうなる？ プロダクトバックログどうなる？ リファインメントどうなる？ 後編 スプリントプランニングどうなる？ デイリースクラムどうなる？ スプリントレビューどうなる？ レトロスペクティブどうなる？ まとめ はじめに Azure DevOps について こんにちは、アーキテクトの小林です。 現在 ecbeing 社内のソースコード管理・課題管理・自動ビルド＆デプロイを Azure DevOps に集約しようというプロジェクトが始動しています。 今まではどうだったのかというと、以下のようにプロジェクトや部署に応じて採用しているツール
「最悪のソフトウェアはマネージメントの問題」、よいソフトウェアを作る方法を政府のソフト開発を行う技術者が語る
by Austin Distel 「ひどいソフトウェアが生まれる場合、問題は特定のエンジニアリングではく、マネージメントにあることが多い」と語る、Googleのプロダクトマネージャーを経てシンガポールの公安部門向け技術開発を行うLi Hongyiさんが、「よりよいソフトウェアはどうやって構築するのか？」をつづっています。 How to Build Good Software https://www.csc.gov.sg/articles/how-to-build-good-software Hongyiさんは、ひどいソフトウェア開発の問題点を一文で「プロジェクトオーナーが解決すべき問題を明確にすることなく解決策としてのソフトウェア構築をスタートさせ、関係者からの長い要望リストを、フルスクラッチで開発を行おうとする外部の開発チームに委託すること」とまとめています。 一方で優れたソフトウェア開
ソフト開発に「かんばん方式」を導入すべき理由とスクラムとの違い
プロジェクト管理方法としての「かんばん方式」について聞いたことはあっても、その詳細については知らないという人は多いかもしれません。かんばん方式は、スクラム（Scrum）などほかのアジャイル方式や、ガントチャートなどのツールとはどのように違うのでしょうか。また、かんばん方式はどのような目的で使われているのでしょうか。 かんばん方式の由来を説明しながらこのような疑問に回答し、実践でどのように使われているのかを解説します。 かんばん方式の基本原則 日本発祥の「かんばん」という言葉はトヨタの生産システムから生み出されたことは、業界周辺では良く知られています。その存在と基本原則を知っていれば、利益を受ける人は多くなると見込まれています。かんばん方式の基本原則とは、リーン生産方式、継続開発、カスタマーオリエンテーションなどです。すべてトヨタの元副社長、大野耐一氏の著書『トヨタ生産方式―脱規模の経営を目
スクラム風チケット駆動開発で開発の見える化に取り組んでみた - Qiita
おきまりのやつ CYBIRDエンジニア Advent Calendar 2015 - Qiitaの5日目を担当します新卒入社4年目の@megadreams14です。 もう入社して4年も経つのかー・・・ さて昨日は今年新卒で入社した@kanachaさんの 「Cocos2d-x超入門 そもそも何からはじめればいいの？」でしたね！ 社内で開催している、普段アプリを触っていないエンジニア向けのCocos2d-x勉強会でも、 新卒でありながらも講師として教える側に回っており、普段から凄く勉強させて頂いております。 開発の見える化について みなさんプロジェクト管理や新規開発をどのように進めていますか？ 弊社では最近スクラムをベースとした開発が主流となっており、 それぞれチームに合った手法やカスタマイズをした開発を行いながら 開発の見える化に取り組んでおります。 今回はこれまでいちエンジニアとして開発に
タスクの完了からはじめるプロジェクト進捗管理 - @ledsun blog
何の話？ タスクの進捗状況をパーセンテージで管理することがあります。 例えば、進捗報告会議で現在着手中のタスクAの進捗を報告するとき「50%完了しています。」という報告の仕方です。 進捗を「タスクの進捗率」で測る方法には、ちょっとした問題があります。 「予定しているタスクのうち2つ完了しています。残りのタスクは3つです。」というように、完了したタスクの数と未完了のタスクの数で報告すると、プロジェクトの進捗管理が、すこし良くなります。 どんなメリット？ プロジェクトの進捗を「タスクの進捗率で測る」方法に比べて、「完了したタスクの個数を数える」方法は、早く正確な進捗情報が手に入ります。 早く正確な情報が手に入れば、プロジェクトが遅れたときにとれる対応策の選択肢が増えます。 お客さん（ステークホルダー）とスケジュールの調整をする プロジェクト全体で確保してあるバッファを使う 予想より早く作業が進
毎朝15分の勉強会で若手の行動が驚くほど改善した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 本稿は、私のプロジェクト(ベテラン1人、開発経験が半年未満の若手2名)で4ヶ月前から実施している「アウトプット勉強会」の実施方法を紹介します(投稿日は2019/7/2です)。 私は過去に新人8人くらいの育成に携わりましたが、この勉強会を実施してから、若手が驚くほど成長しました。なぜ今までこれをやらなかったのかと後悔しています。 この「アウトプット勉強会」の形式は、「書籍編」と「設計・実装編」の2種類があります。本稿では「書籍編」の方法を説明します。「設計・実装編」については、以下の記事を参照ください。 毎朝15分の勉強会
毎朝15分の勉強会で若手の設計力がメキメキアップした話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1. はじめに 本稿は、私のプロジェクト(ベテラン1人、開発経験が半年未満の若手2名)で実施している「アウトプット勉強会」の実施方法を紹介します。 この勉強会を実施してから若手の設計・実装スキルがメキメキアップしました。私は過去に新人8人くらいの育成に携わりましたが、これが一番効果的だと思います。 なお、「アウトプット勉強会」の形式は、「書籍編」と「設計・実装編」の2種類がありますが、本稿では「設計・実装編」を説明します。「書籍編」の形式については、以下の記事を参照ください。 毎朝15分の勉強会で若手の行動が驚くほど改善した話 本稿は、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた