Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest. →
プレイングマネージャー型のEMをしています、鈴木(@szk3)です。 今回は、私たちのサービスチームが新規プロダクト開発を始めるにあたって「スクラムを導入しなかった」経験について共有します。 このタイトルだけを見ると、スクラムに対して否定的な印象を持たれるかもしれません。しかし、これはスクラムへのアンチテーゼではありません。むしろ、スクラムの価値をリスペクトし、その実践に真摯に向き合いたいからこそ行った慎重な決断でした。実際、新規プロダクト開発の開始とほぼ同時期に認定スクラムマスター資格も取得し、スクラムについての理解を深めていく中で、この決断の意義をより一層実感しています。 新規プロダクトの開発において、アジャイル開発を取り入れることは当然の選択肢として考えられます。むしろ、アジャイル開発の実践にスクラムのフレームワークを使うことは、実質上のスタンダードとなっていると感じます。しかし、「
ウォーターフォールとアジャイルは、それぞれ異なる前提と目的を持つマネジメント手法です。ウォーターフォールは全体計画の精度を前提に効率的な開発を目指し、アジャイルは変化に適応しながら試行錯誤を重ねることに重点を置きます。しかし、世の中ではマネジメント手法としてフェアな評価ができていないようにも感じます。 その要因は、アジャイルの説明が精神論や感情論に寄りすぎている点にあると思っています。そこで、そういった要素を排除し、双方をマネジメント手法として整理してみました。 前提条件 僕は、いわゆるエンタープライズ業界の人なので、SIerがいるような規模の組織を前提にしていますが、マネジメント手法としての考え方は、どの業界でも利用できると思います。 「ウォーターフォール」とは、大手SIerなどで定義されているウォーターフォール的なマネジメント手法のこと。V字と呼ばれる要件定義、基本設計、詳細設計、実装
タイトルの議論はよく見られるもので、スクラムコーチの間ですら(一見すると)意見が分かれることがあるようです。自分は「安定させる」派だったのですが、CSPO研修を受講したチームのPOが「上げる」派のコーチングを受けてきて、改めてチームとしてどういうスタンスを取るか考える機会を得ました。結論から言ってしまうと、そもそもこれは二項対立ではなく、「上げる」派の人も「(安定させた上で)上げる」と言っているだけで、単に目指している高さが違うだけだろうと解釈しました。その上で、チームの現状に合わせて適切な目標設定をすれば良いと考えました。以下でもう少し掘り下げてみます。 大前提 まずソフトウェア開発の大前提として、開発チームには常にベロシティを下げる方向に様々な力がかかっています。これは「変化」と呼ばれて恐れられ、プロダクトや開発チームに次々と襲い掛かります。例えば以下のようなものです。 市場が求めるも
「アジャイルリーダーシップは、これからのリーダーシップです」 変化の速度が速まり、また、複雑化した現在のビジネス環境に適応し、価値を創出し続ける組織であるためには、旧来的ではない、新たなリーダーシップが必要になる。 こう説く書籍『アジャイルリーダーシップ』が2022年秋に刊行されました。著者であり高名なアジャイルコーチであるZuzana Šochová(ズザナ・ショコバ / @zuzuzka)さんは、自身の経験と多くの情報を融合し、変化に適応するアジャイル組織を形作るうえで重要な要素である、アジャイルリーダーシップを具体化し、それを体現するために必要なコンピテンシー(行動特性)やエクササイズを同書にまとめました。 書籍で語られる、アジャイルリーダーシップの価値はどこにあるのか、組織内で浸透させるための課題は何か、いかにして現場で発露するか。こうした「アジャイルリーダーシップの実践」を、同書
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く(前編)。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか? という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
情報処理推進機構(IPA)は2021年10月6日、アジャイル開発版「情報システム・モデル取引・契約書」を改訂した。厚生労働省が同年9月21日に公表した「『労働者派遣事業と請負により行われる事業との区分に関する基準』(37号告示)に関する疑義応答集(第3集)」に関する情報を追加した。これに伴い、「アジャイル開発外部委託モデル契約(解説付き)」も更新した。 アジャイル開発版情報システム・モデル取引・契約書は、IPAが設置した「モデル取引・契約書見直し検討部会」と「DX対応モデル契約見直し検討WG」で検討された、アジャイル開発を外部委託する際のモデル契約についてまとめたもの。アジャイル開発を外部委託する際の契約条項とその解説、補足資料で構成されている。 発注者の意見が反映されるアジャイル開発は偽装請負になる? 改訂の基になった「労働者派遣事業と請負により行われる事業との区分に関する基準」(37号
はじめに 大企業や非IT系企業がアジャイル開発に取り組む際、自社のメンバーだけで"内製"することはなかなか難しいのが現実です。 そこで、ビジネスパートナーやシステム子会社など(以下協力会社)と自社社員(以下プロパー)と混成アジャイルチームを構成するケースが多くあります。 その際、よくプロパーの管理職から、 「協力会社社員のモチベーションが低い」 「受け身の姿勢で、言われたことしかやらない」 という悩みがよく寄せられます。 プロパー社員と協力会社社員の姿勢の温度差は、一見大きな問題ではないように見えます。 ですが、このようなケースでは「関係各所との調整」「複雑な仕事」「重要な意思決定」がプロパーに委ねられ、結果、プロパーがボトルネックとなり、チームであることのメリットが活かせず、開発が停滞する現場を多く見てきました。 今回は、この悩みと解決の方向性について述べていきたいと思います。 (Bob
みなさんこんにちは。@ryuzeeです。 10月に発売となった『プロダクトマネジメント - ビルドトラップを避け顧客に価値を届ける』ですが、まだお読みになっていない方是非よろしくお願いします。 また、ここ数か月新しい書籍の翻訳に取り組んでいて、来年の春くらいには発売になるかと思います。この本も楽しい本だと思うので是非楽しみにお待ち下さい。 さて、先日、プライベート講演で、SIのコンテキストでアジャイル開発を進める場合に、どのような点に気をつけておくとよいかを話して来ました。 汎用的な内容で読者の方の参考になるかと思いますので、資料を公開しておきます。 以下、資料だけ見てもわからない方向けの解説です。 TL;DR(結論)SI案件でアジャイル開発を適用する場合、顧客側がアジャイルを正しく理解していない可能性があるので、案件開始前に教育すべしステークホルダーマネジメントは重要。これはウォーターフ
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン(ソフトウェア)開発とは何か? 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発~アジャイル開発を実践する22の方法~ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感:結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
まあ、クラウドもそうなんですが、アジャイルも10年程経ちますと、これでいいんだっけ?という振り返りの時期に入っていくんでしょうね、その振り返りをマニフェストを作った一人が提起しているということらしいです、はい。 Utah州のSnowbirdに集まった仲間と13年前に作った「アジャイルソフト開発のマニフェスト」について、Dave Thomas氏の非常にインパクトのある、でも逆説的なタイトル「アジャイルは死んだ(生きの長いアジリティ)」についてです。要は「アジャイル」とは何かを見直す時期に来たと言いたいようですね。 「その当時既に骸化していた80年代から90年代に流行った手法が蔓延していて、その手法をぶち壊すために開発者の心の支えとなってきた「アジャイルソフト開発のマニフェスト」は下記の4本柱からなる」と言います。 Individuals and Interactions over Proce
English Version: https://www.slideshare.net/sakataakinori/xp-fes-2019-b6-application-of-statistical-quality-control-to-agile-software-development XP祭り2019 B-6 「アジャイルソフトウェア開発への統計的品質管理の応用」の資料です。 On 2019年8月20日, in XP祭り2019, XP祭り2019セッション 【セッション情報】 セッションID:B-6 時間:14:45~15:15(30分) 会場:B(1F 102室・後) タイプ:講演 【セッション内容】 アジャイル開発のマネージメントやチーム運営のお手伝いをしていく中で、ウォータフォールで使われている品質メトリクスを利用しようとしているプロジェクトを見かけることがあります。 ウォー
開発部の土岐です。今日が誕生日で割り切れない数の歳になりました。 さて、これまでの幾度か弊社アプレッソで「アジャイルへの取り組みを始めてるよ!」ということを紹介して参りました。 appresso.hatenablog.com appresso.hatenablog.com 2016年7月現在、DataSpider Servistaの次バージョン、4.1の開発プロジェクトが本格化し、実際にアジャイルな開発に取り組んでおります! と自信満々に言ってみたものの、本格的なアジャイルに取り組むのは初めての我々。「ヒヨコードでピヨピヨしている」状態ではありますが、日々悩み議論しながらいろいろなことにチャレンジしています。 ということで今後、その取り組みを具体的に紹介していこうと思います。 今回はアジャイル的な見積りの技法、「プランニングポーカー」についてです。 プランニングポーカーとは? プランニング
DevLOVE X の発表資料です https://devlove.wixsite.com/devlovex
スピーカー60人超!? 公式 セッション一覧 DevLOVE 新サイト 【Day1】 6/22 6/22 11:00-11:40 新井 剛 普通のエンジニアが10年でニュータイプやスーパーサイヤ人になれるのか?カイゼンさんのジャーニーの巻 松下 雅和スタートアップで培ったアーキテクチャ設計ノウハウ 横道 稔 「嫌われない」を諦めない 小田中 育生(おだなか いくお) ソフトウェア開発に最短経路はあるか 及部 敬雄【勝手に基調講演】アジャイルで目指した坂の上の雲 6/22 11:50-12:30 山口 鉄平 良い感じにイベント・勉強会を 開催するために意識していること 島川 悠太 スモール イズ タノシイデスネ〜小さく回して楽しい開発体験を得るための処方箋をいくつか ちゃちゃき エンジニアがUXデザインを学んでみた10年 篠原 徳隆 ゼロイチ人材の存在意義と生存戦略 中村 洋 「正しいものを
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ! 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く