『More Effective Agile』：私のお気に入りなエンジニア向け書籍 | IIJ Engineers Blog
35年かそれ以上にわたってソフトウェア業界に携わってきた中で、一番の難題は、「コード&フィックス開発」を避けることだった。コード&フィックス開発とは、事前の見通しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである。 (中略) アジャイル開発には、見るからに短期集中型でコード中心であるために、チームがアジャイル開発のプラクティスを実践しているのか、それともコード&フィックスを行っているのかますます見分けがつかなくなる、という課題がある。壁に付箋紙がベタベタ貼ってあるからといって、チームがその作業に組織的かつ効果的に取り組んでいるとは限らない。 ――『More Effective Agile ―― “ソフトウェアリーダー”になるための28の道標』 「第4章 より効果的なアジャイルの始まり: スクラム」より IIJイノベーションインスティテュートの四谷です。普段はサー
大規模にアジャイルをやるにはどうしたらいいか、に対する答え - 海と山が好き
大規模にアジャイルをやるにはどうしたらいいですか？ 答え 大規模にしない 以上終わり。 先日大規模な組織レベルでのアジャイル導入をするという人と話す機会があったのだが、どうするのがいいですかね？って聞かれて出た感想が、「大規模にしない」だった。 ドメインも違う、プロダクトも違う、顧客も違う、作るチームも違う そんなチームのプロセスを同期や依存させる意味あるのかと。 「DB にアクセスするときは必要ないけどこっちの DB へもコネクション確立してね！」 って言われたらどう考えても頭おかしい人でしょ。 依存がいらないところをわざわざ依存させない。 偉い人が同じ？組織上同じだから？ 依存を増やしてどうやって変化に対応するのか？ 変化に対応するコストを高めるだけの価値がその偉い人が気持ちよくなることにあるのか？ そんなことを感じないでもない。 アジャイル界隈で悪名高い？Scaled Agile F
真面目な人を本気にさせる方法
先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 本気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ
【翻訳】ストーリーポイントを使うのをやめよう - PoohSunny's blog
はじめに このエントリーは、Industrial LogicのCEOで、モダンアジャイルの提唱者としても知られるJoshua Kerievskyの「Stop Using Story Points」というブログポストを許可をえて*1翻訳したものです。2012年と古いものですが、今でも有益な内容だと考えています。原文はこちらになります。 www.industriallogic.com 誤訳等あれば優しく指摘していただけるととても助かりますし喜びます。 ユーザーストーリーを使うのをやめよう ハンバーガー、ポテトそしてコーラがファーストフードのシンボルであるように、スプリント、朝会そしてストーリーポイントは、アジャイルの方法論のシンボルになりました。 アジャイルハッピーセットの準備はできていますか？ おそらくNoでしょう。 ファーストフード研究者のように、我々はアジャイルハッピーセットに、アジリテ
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
KPTのサイクルで実践する継続的チーム改善 - Qiita
コミュニケーションアドベントカレンダー 5日目の記事です。 ソフトウェアの開発を行う上で1人開発であっても、チーム開発であっても様々な問題が発生します。最初は小さな問題だったとしても次第にそれは無視できない問題となり、放置することで成果物の品質が著しく下がったり、最悪プロジェクトが頓挫することがあります。 それを防ぐためにKPTという方法が提案、実践されています。 ミーティングでは、ホワイトボードなどに「K：keep＝今後も続けること」「P：problem＝問題なので、やめること」「T：try＝今後、試してみたいこと」の項目を用意し、メンバーが行ってきた活動報告の内容を「K」と「P」に振り分けていく。その後、「P」に対する解決策や新しいアイデアや企画を「T」欄に書く。 今回は私達の組織で実践しているKPTの目的、手法、そして成果についてまとめます。 KPTの目的とは 最終的な目的は、より良
It's an Experiment
In my last blog post questioning the state of the agile movement, I asked “What happened to the idea of inspect and adapt? What happened to the idea of introducing new practices, of evolving our practices to suit the challenges at hand?” According to a 2014 survey on agile development by VersionONE, 56% of the teams they surveyed use Scrum, some 10% use a Scrum/XP mix, and 8% are using a mixture o
Googleはどうやってサービスを生み出すのか？ – Google主催のプロトタイピング・ワークショップ | fladdict
＜追記＞オリジナルのデザインスプリント文献翻訳はじめました＜／追記＞ THE GUILDのメンバーで、Google主催のプロトタイピングのワークショップ「デザインスプリント」に参加してくるなど。ご招待いただき多謝でございます。 デザインスプリントとは？ デザインスプリントはグーグルによるデザイン教育メソッドとそのワークショップ。数時間から数日で一気に籠って、商品のコンセプトデザインやプロトタピングを仕上げてしまう高速なデザイン手法です。Googleのベンチャー機関Google Venturesがよく、投資先に行っているものです。 導入事例としては、最近に日本にも上陸したブルーボトルコーヒーのサイトブランディングで行われたのが有名でしょうか。GoogleX内部でも頻繁に行われているようです。本来は5日間でやるこのデザインスプリント、今回は入門編ということで圧縮して2時間で1つの企画を考えます
DAD(Disciplined Agile Delivery)概要 - Qiita
はじめに Scott Ambler Mark Lines が提唱しているDAD(Disciplined Agile Delivery)の概要をまとめる。 XP(Extreme Programming), Scrum, Lean, といったアジャイル手法の１つであるが、それらを総合的に利用しながらエンタープライズ向けに作られたコンセプトとなっている。 日本語の翻訳はこちら。(藤井智弘さん監訳) 日本版の公式サイトDisciplined Agile Deliverty - Japanも立ち上がっている。 Agile2014でのAmblerの講演資料も参考に。 定義 DAD とは、、、、 The Disciplined Agile Delivery (DAD) process decision framework is a people-first, learning-oriented hybr
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Process is not the Product — The New Agile Anti-Manifesto.
朝会のこと - @m_seki の
捨てて開発できるチームづくり
Trello