マガジンのカバー画像

アジャイル開発奮闘記

9
運営しているクリエイター

記事一覧

ファシリテーションの心得

社内の開発チームの中で、会議のファシリテーションが初めてで、自分がファシリ担当の会議があるときには緊張して身構えてしまうという話があったので、自分の経験やファシリテーションの関する記事・本を参考に「ファシリテーションガイド」というものを作成しました。せっかくなので、noteでも公開してみます。

ファシリテーションとは何か広義

日々のチーム活動の中で、会議の進行やプロジェクトの管理、あるいは仕事

もっとみる

会議での議論の進め方を変えてみた~参加者の情報整理の仕方に合わせて進行~

最近、開発メンバー同士でのふりかえりの場で「議論の時に一部の人ばかり話していて、何も意見しないメンバーが何人かいるよね」という問題提起が複数回出ていました。

聞かれずとも自分から意見を主張する人もいれば控えめな人もいるので、そこはファシリテーターの人が各自に名指しするなどして参加者一人一人から意見を聞くようにしよう、ということになってある程度は発言量のばらつきが減ってきたのですが、今度は発言の質

もっとみる
イテレーティブ開発でのベロシティ推移をグラフ化する良し悪し

イテレーティブ開発でのベロシティ推移をグラフ化する良し悪し

スクラムなどのイテレーティブな開発において、チームが各イテレーションでどのくらいの規模の開発をできるかという指標は、イテレーションの計画(スプリントプランニングなど)を円滑にする上でとても役立つ指標だと思います。そしてこの「チームが一つのイテレーションでどれだけの規模を開発できるか」の指標として、ベロシティというものがあります。具体的には、チームが取り組む各タスクのサイズを数値で定量化し、イテレー

もっとみる

イテレーティブな開発 = スクラム と捉えると生じ得る誤解

不確実性に向き合うためのイテレーティブな開発何がユーザーにとって価値があるのかを事前に推測することが難しいような不確実性の高いプロダクトを作るとき、なるべく早くフィードバックを得て機敏に方向転換ができるように、スクラムではイテレーティブ(反復的)な開発スタイルを採用しています。具体的には、スクラムガイドを道標としながら、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロ

もっとみる

カンバンとスクラム

アジャイルの実践方法として取り上げられる、カンバンとスクラム。

現在私が所属しているチームでは、これまでカンバン形式でプロジェクト管理をしていたのですが、次第にチーム内外での要求が変化し、スクラムを参考にイテレーティブな開発を導入し始めました。

その中で、チームの中にはスクラム未経験のメンバーもいたため、これまでのカンバン形式と、参考にしようとしているスクラムがどのような関係性にあるのかチーム

もっとみる

スクラム失敗談 | スクラムマスターがチーム改善をリードしてしまう

Androidエンジニア 兼 スクラムマスターのNichiです。

スクラムマスターの拝命を受けて9ヶ月ほどたち、約18スプリント(2週間スプリント)が経過して、最近ようやく、スクラムマスターとして自分がどう振る舞うのが良いのかが少しずつ見えてきました。

そこで、今になってようやく気づいた、スクラムマスターとしての失敗談を不定期で更新しております。

なお、過去の2記事は↓↓

自分がスクラムマ

もっとみる

スクラム失敗談 | みんなで話そうとするレトロスペクティブ

スクラムチームが、自分たちのコミュニケーションやプロセスを改善し、より生産的に価値を届けるためのふりかえりの場であるレトロスペクティブ。

今回は、私がスクラムマスター(兼エンジニア)を務めるスクラムチームでのレトロスペクティブでの失敗例を紹介します。

失敗:専門職で分かれてるのに一度しかしないふりかえり「レトロスペクティブの場でチームメンバーみんなで話すことの何が問題なのか」と思われるかもしれ

もっとみる

スクラムの開発チームを10人以上で回すツラミ

スクラムガイドでも以下のように書かれているように、スクラムチームにおける開発チームの規模は、3~9人が良いらしいです。

開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。(中略)メンバーが 9 人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバ

もっとみる

職能チームのチームビルディングに奮闘してる話

ソフトウェア会社の組織で良くある編成として、プロジェクト毎に職能横断のメンバーで構成されたプロジェクトチームと、職能ごとのチームの二軸編成があると思います。縦軸と横軸で表現されることもありますね。

僕が所属している部署もそうで、クライアント・サーバーエンジニア、デザイナー、QAなどからなるプロジェクトチームと、Androidなど職能ごとのチームがあります。

プロジェクトチームは普段から一緒に共

もっとみる