"アジャイル"投稿一覧

チームメンバーとの人間関係構築の状態問わず、まずは「なぜ導入するのか、導入することでどういった嬉しいことが起きるのか」をまず共有し納得してもらうことだと思っています。現状のプロジェクト進行やスループットに対する課題も添えるとメンバーも課題感を持ってくれると思います。

納得されたのであれば、「ではどんなことに気をつけ、どう動くべきなのか？」と言うフェーズになるのでそこでアジャイ... 続きを見る

「アジャイルコーチ」と名乗って仕事をしているものです。

厳密に言うと「アジャイルコーチはこうだ」という定義はないと思います。また、コーチとは名乗っていますが、純粋なコーチングを広めているICF（国際コーチング連盟）のコーチングとも関連性はありません。

僕の仕事内容は、ざっくりまとめると「アジャイル開発の支援をする仕事」です。広く言うと「ソフトウェ開発に関... 続きを見る

チームが分かれていないとありますが、さらにチームの中での役割分担が固定化されていないのであれば、DevOpsというキーワードが意味するところは、もしかしたらあまり気にしなくてもよいフェーズにいらっしゃるのかもしれませんね。

逆にチームの中で、「いつも◯◯さんが、本番環境へのリリース作業や障害対応をやっているんだよな・・・」「インフラのことは僕は知らないんだよね」といった状態が... 続きを見る

ウォーターフォール開発は開発そのものに対してのメリットというより
ウォーターフォール開発による開発物の販売/案件による請求方法が国内で確立していることがいい部分ではないでしょうか。また、これがウォーターフォール開発を実施している営利法人がアジャイル開発に切り替えられない理由でもあるはずです。

つまり、例えば受託開発会社においてアジャイル開発を取り入れるとして、 続きを見る

スクラムマスターが必要な組織と
その組織で行われるスクラム開発ではスクラムマスターが必要であり
スクラムマスターが不要だと思う組織と
その組織で行われるスクラム開発ではスクラムマスターが不要です。

インフラエンジニアが必要な組織と
その組織で行われる開発にインフラエンジニアが必要であり
インフラエンジニアが不要な組織と

プロダクトバックログに記載する受け入れ基準(AC)と完成の定義(DoD)をチームと見直して合意するのはいかがでしょうか？
スプリントレビュー前に品質の問題に気づいてほしい，という風に見受けられるため後者が特に重要と感じました．

Ryuzeeさんのブログでプロダクトバックログに書くACとDoDについて述べられています．
続きを見る

システム開発の方法として1番多く採用されている手法を教えてください。

少し前のデータとなりますが、日本においてはウォーターフォール開発を採用している企業が最も多いようです。

続きを見る

お客さんに説明するときは、こんな感じで説明しています。

アジャイル開発は「もっと良い開発をするための考え方」です。
考え方だけでは、実現が難しいので、スクラムという「方法」を使います。方法にはXP（エクストリームプログラミング）やかんばんなど、様々な種類があります。

さらにいうと、様々な方法にはプラクティスが用意されていることがあります。プラク... 続きを見る

MVPの考え方は、従来型のタスク分割とくらべて理解されにくいものです。アジャイル開発のトレーニングをやるときでも、MVPの考え方はかなり念入りに説明しています。

今回はデメリットということなので、自分なりに考えてみました。

まず、よくあるトラブルなのですが、初期開発の場合など、ある程度機能が揃っていなければ「ならない」開発の場合、MVPが通用しない場合が... 続きを見る

こんにちは。アジャイルコーチとして質問のような悩みを持つ現場を支援しています。

ベロシティの数値は、スプリントプランニングで見積もった計画の数値が元になります。たとえば、計画時に100と見積もったものが90だといまいちだし、110だとよくできた！という感じです。

安定しないということは、計画がうまくいかなかったとも言えます。よって、以下の対策をふりかえり... 続きを見る

バグ対処や人員確保、スケジューリング、顧客要望などでスケジュールが押してアジャイル開発になってしまっている気がします。

まずアジャイル開発...というところの定義の認識を揃えるところから始めると良さそうです。Wikipediaの引用ですが、アジャイル開発の定義は以下のようになっています。

典型...

続きを見る

分断がどういう状況を指しているかわからないですが、関係者での目標や目線合わせ・顧客課題に対して同じ方を向けている状況でしょうか？各々の職責で向き合うべき課題がどうしてもズレてしまうことは往々にしてあるし、それぞれが責任を持つことでもありますが、より抽象度が高いレベルでは同じ方を向いているべきだと思います。

なので基本的なアクションは複雑な手法などではなく、分断があるのであれば... 続きを見る

パッと思いつくものとしては以下でしょうか。

- ストーリーポイントを価値基準でなく、早くさばける順に並び替えようとした
- 技術的指向の異なるエンジニアが、得意な分野で働きたいためにチケット、開発する機能を用意しようとした
- 引かれたロードマップになぞることが正となり、スケジュールドリブンで動いてしまった
- スプリントレビューがルールになぞっ...

・各企業それぞれ独自のスクラムをしている
→スクラムは本来18ページほどのスクラムガイドに載っていることが原点ですが、企業の文化によって合う合わないなどの理由により独自スクラム文化が醸成されていることが多いです。
ですので、面接などでスクラムをやっているからと言って前の会社でやっていたスクラムと完全に一致することはほぼないと思います笑

・スクラムで朝会をや... 続きを見る

コントロールチャートを使ってざっくり各ステップのリードタイムをメンバー全員で眺める時間を作ってます。
あくまでそれは問題点や改善の糸口を探る為なので、糸口を見つけた後に深堀りしていきます。