ミルクボーイがアジャイルを説明したら
序章駒場「最近、うちのおかんがシステム開発に興味を持っててなぁ、名前は忘れたらしいんやけど、迅速に開発できて、仕様変更にも対応できる、素晴らしい開発手法を取り入れてるところがあるらしいんやわ〜。」 内海「そんなもんアジャイルに決まってるがなぁ〜! 今やシステム開発と言えば、アジャイル。素早く変化に対応できるってゆーのが特徴なんよ。そもそも名前が “迅速” を意味する英語やねんから、アジャイルに決まってるがなぁ〜。」 チームの人数駒場「最初、オレもそう思たんやけどな、なんでも 40 人ぐらいで開発してるらしいんやわぁ〜。」 内海「ほなぁ、アジャイルちゃうかぁ…。アジャイルでは 5〜9 人ぐらいが推奨されてるからなぁ〜。40 人もおったら、とてもやないけど、コミュニケーションが成立するとは思われへんなぁ〜。効率の悪い伝言ゲームになるのは目に見えてるからなぁ〜。おかん、他にもなんか言うてなかった
デンソーのアジャイル開発チームができるまで チームビルディングにおける工夫と実装の裏側 | ニュース | DENSO - 株式会社デンソー / Crafting the Core /
翔泳社主催のソフトウェア開発者向けITカンファレンス「Developers Summit 2019」が2月14日～15日に開催されました。セッション「デンソーのMaaS開発～アジャイル開発で顧客との協調・チームビルディング・実装概要～ 」に登壇したのは、当社MaaS開発部デジタルイノベーション室の佐藤義永と冨田進。昨年のDevelopers Summitで発表した内容をベースに、この1年で実際にサービスをリリースするまでの知見やアジャイル開発・チームビルディングについて語りました。 佐藤義永（以下、佐藤）：ご紹介ありがとうございます。デンソーの佐藤と冨田です。今日は「デンソーのMaaS開発が具体的にどんなことをやっているのか？」ということをご紹介できればと思っています。 はじめに、去年のデブサミでもおうかがいしましたが、デンソーという会社を「知ってますよ」という人、どれぐらいいますか？ （
スクラムで失敗する5大理由とその対策としてできること | POSTD
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
心理的安全性が高くアジャイルな組織設計
心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、本来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例：リーダーが超ベテランでメンバーが超若い
銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) - ari's world
銀の弾とアジャイルについてのメモ (Agile is a Silver Bullet) 2018年10月9日 要点 1986年にソフトウェアエンジニアリングについて書かれたフレデリック・P・ブルックス氏（以下、Brooks）『人月の神話』「銀の弾はない」はすごい（久しぶりに読み返した）。まじリスペクト。 本質的な困難と、その攻略を通じて、アジャイル開発を理解するとスッキリする（個人的な見解です）。 はじめに アジャイル開発は、ソフトウェアエンジニアリングにおいて迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 アジャイル開発の「なぜなのか(WHY)」や「どのような問題を解こうとしているのか」を、自分なりに整理したかった。その時、Brooks『人月の神話』を改めて読んで、びっくりした。これは、すごいと。 2018年10月9日に書いたメモがある。まだまだ整理や考える余地はあ
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
アジャイル開発時におけるプロジェクトの進め方（その1） - Qiita
アジャイル開発におけるプロジェクトの進め方 アジャイル開発において、色々悪い意味で誤解をしている方々が沢山いるので、 アジャイル開発をした事が無い方々の指針になればと思い書いております。 はじめに ここに記載している内容を読む前に、必ず以下の点を考慮してください。 全てのチームに同じように適用できるとは限らない。 そもそもプロジェクトの段階で、アジャイル開発の適用が出来るものとできないものがある。 やり方は一つじゃない。 スケジュールの立て方 アジャイルにせよウォーターフォールにせよ、まずはスケジュールがあります。 アジャイルにスケジュールなんて( ´,_ゝ｀)ﾌﾟｯ っと思うかもしれませんが、そもそも1年後か10年後か100年後か成果を何時出せばいいか わからないようなプロジェクトは極僅かしかありません。 アジャイルとウォーターフォールの上のスケジュールの違いは、 スケジュールの粒度とス
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
アジャイルは”再び"死んだ
Mathew (Ford) Kern氏とMilko氏は先日，どちらも“アジャイルは死んだ(Agile is Dead)”と題した記事を書いた。この話題を，Kern氏は，アジャイルコンサルティングの飽和とハイプサイクルの速さに関連するものとし，Miko氏は，アジャイル活動の具現化したアプローチの速さを越えるために，アジャイルからDevOpsへと進化する必要性を説いている。 Kern氏の最初の記事のタイトルは，“Agile is Dead”そのものだ。意識的に物議を醸すような(そして皮肉な)スタンスを選んだ氏は，次のように言う。 アジャイルソフトウェア開発は死にました。実践している人はドアストップです。管理手法として用いている人はボートの錨です。波は過ぎ去りました，もう終わりです。騙されて資格を取った人は，残念ですがお金の無駄でした。 氏はさらに，マーケティングとマネジメントに関する流行とセン
速いサイクルで開発できるようになってもビジネスに結び付かない理由
単に開発のサイクルが速くなっただけではウオーターフォール型開発と同じ 開発期間が長期にわたるウオーターフォール型開発を見直しつつ、短期間のサイクルで迅速にソフトウェア開発を行うアジャイル型開発の採用を進める開発会社が増えつつある。変化が速い昨今のビジネス環境においては、これまでのウオーターフォール型開発のままでは顧客のビジネスニーズに対応しきれなくなっているのである。特に、消費者との接点となるようなWebサービスの開発では、アジャイル開発に対応したプロジェクト管理ツールを導入し、積極的にアジャイル型開発に取り組む傾向が見え始めている。 一方、アジャイル型開発を実際に進めていく中で、プロジェクト管理ツールを導入しただけでは解決されない課題も幾つか浮き彫りになってきた。その1つが、開発チームがアジャイル型にシフトし、短期間でのソフトウェア開発が実現しても、そこに運用チームやエンドユーザーのリク
「ウオーターフォールかアジャイルか」ではなく「目的に最適かどうか」、“本質を見極める視点”が勝負を分ける――グロースエクスパートナーズ
「ウオーターフォールかアジャイルか」ではなく「目的に最適かどうか」、“本質を見極める視点”が勝負を分ける――グロースエクスパートナーズ：特集：アジャイル時代のSIビジネス（3）（1/3 ページ） クラウドの浸透などを背景に、「SIビジネスが崩壊する」と言われて久しい。だが顕在化しない“崩壊”に、かえって有効な手立てを打てず不安だけを募らせているSIerも少なくないようだ。本特集ではSIビジネスの地殻変動を直視し、有効なアクションに変えたSIerにインタビュー。SI本来の在り方と行く末を占う。 ビジネス展開に一層のスピードと柔軟性が求められている今、それを支えるシステム開発・運用についてもクラウドネイティブな技術、新しい技術が注目を集めている。だが言うまでもなく、最新の技術を使えば全てを解決できるわけでもなければ、技術そのものが課題を解決してくれるわけでもない。技術を選び、使いこなし、正しく
失敗するプロジェクトと成功するプロジェクト
多様なプロジェクトの進め方がありますが、進め方を問わず、「成功するプロジェクト」に共通する要件は何なのでしょうか。 以下に最も重要だと思う2点を紹介します。 うまくいくプロジェクトの要件 コミュニケーションがプラットフォーム化しているプロジェクト 弊社、Cuonでの経験則になりますが、成功するプロジェクトは「コミュニケーションがプラットフォームとして成立しているプロジェクト」といえるのではないでしょうか。 『もしドラ』のヒットで日本でも一般的に有名になったピーター・ドラッカー氏は、かつてこう言いました。 コミュニケーションで一番大切なことは、相手が口にしていない言葉を、聞き分ける力である。 この言葉には、「相手が全てのことを口にしているわけではない、もしくは全て言葉で表せるものではない」という意味が含まれていると思います。 プロジェクトを進める過程で、プロジェクトマネジャーに大事なことは、
アジャイル界隈研修の感想まとめ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
「アジャイル開発のススメ」＠香川大学 | ワイクル株式会社
香川大学の富永浩之先生からご招待いただき、「アジャイル開発のススメ」と題して講演を行いました。 ソフトウェア開発が専門ではない学生さんもいらっしゃるとのことでしたので、アジャイル開発の手法そのものよりも、背景にある考え方にフォーカスした内容にしました。よく見かける「アジャイル開発宣言から説明する」スライドよりも、だいぶ平易な内容になっているかと思います。 講演のあとは、富永先生の研究室で「XP：ペア計画ゲーム」を行いました。学部1年から修士の学生さんまで、合計34人に参加していただきました。 ペアプログラミングの様子 プログラミングに不慣れな学生さんもいましたが、逆に時間が余ったという余裕のある学生さんもいらっしゃいました。いずれにしてもペアでプログラミングをする機会はこれまでになかったようで、終了後に「楽しかった」との声を数多くいただきました。 富永先生からの反応もよかったようで、とりあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
世界最大級のアジャイルカンファレンス報告：Agile2016参加レポート