タグ

ブックマーク / www.ryuzee.com (9)

  • アジャイル開発がうまくいっていない気がするというチームに確認すべきこと

    みなさんこんにちは。@ryuzeeです。 仕事柄さまざまな会社のいろいろなチームから相談を受けます。 具体的な相談のこともあれば、抽象的な相談のこともあります(内容が具体的になっていればもう解決までそう遠くありません)。 抽象的な相談で多いのは「なんとなくうまくいっていない気がするけど、何を確認したらいいの?」というものです。 今日はこの質問に対して、どう対応しているかを共有したいと思います。 スクラムをベースに書いていますが、スクラムでなくても構いません(その場合は適宜用語を読み替えてください)。 確認ポイント いきなりほぼ結論です。 このような相談を受けたときに、いちばん重要な確認ポイントは 「毎スプリントごとに動作するソフトウェアを作って、チームの外側に見せてフィードバックをもらっているか?」 です。この確認をしないうちに「スクラムイベントは全部やっているか?」とか「プロダクトバック

    アジャイル開発がうまくいっていない気がするというチームに確認すべきこと
    Wacky
    Wacky 2024/03/02
  • 社内でアジャイル開発標準を作るときの注意点を教えてください

    アジャイルソフトウェア開発宣言では、 よりよい開発方法を見つけだそうとしている とあり、またこれに付随する「アジャイルソフトウェアの12の原則」では 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されますチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整しますとあります。 これらが意味するのは、どんな形で開発するといいのかはチームごとに違うこと、それぞれのチームが自分たちの状況にあわせて改善していくことに価値があるということです。 つまり、アジャイル開発標準を作って、それを強制することは、アジャイルの価値観そのものを毀損することになります。 誤解を避けるために繰り返しますが、アジャイル開発の標準を作ること自体は役に立つ可能性はあります。 ですが、この利用や遵守を強制してはいけません。強制したところで標準化自体が生産性や成

    社内でアジャイル開発標準を作るときの注意点を教えてください
    Wacky
    Wacky 2023/08/08
  • 【資料公開】目標設定の基本

    みなさんこんにちは。@ryuzeeです。 2023年5月9日に開催されたNTT Com Open TechLunch #7「エンジニアリングマネージャーと目標設定」の登壇資料を公開します。 このイベントはNTTコミュニケーションズの社内ランチ勉強会を一般に公開しているものです。 ぼくは、NTTコミュニケーションズの技術顧問をしており、顧問業の一環として登壇しています。 多くの組織では、この時期に期初の目標設定を行っているのではないかと思いますが、目標設定の意味や位置づけ、それをどのように使うのか、評価や報酬との関係はどうなるのかといったことについて組織のなかで認識が揃っていることはまれです。 こうなると、人事制度のなかで目標設定をすると決められているのでめんどくさいけどやる、という感じになったり、目標設定が終わったら内容を綺麗さっぱり忘れて、期末になって「あー、そういえば……」みたいなこと

    【資料公開】目標設定の基本
    Wacky
    Wacky 2023/05/18
  • DevOpsトポロジー

    みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者/訳者:マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社:日能率協会マネジメントセンター発売日:2021-12-01単行:280ページISBN-13:9784820729631ASIN:4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ

    DevOpsトポロジー
    Wacky
    Wacky 2022/04/11
  • FAQ

    SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発著者/訳者:西村 直人、 永瀬 美穂、 吉羽 龍太郎出版社:翔泳社発売日:2020-05-20単行(ソフトカバー):288ページISBN-13:9784798163680ASIN:4798163686 アジャイルコーチングやトレーニングを提供しています株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。 詳細はこちら エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法著者/訳者:James Stanier / 吉羽龍太郎 永瀬美穂 原田騎郎 竹葉美沙出版社:オライリージャパン(2022-08-26)定価:¥ 3,740エンジニアリングチームのマネ

    FAQ
    Wacky
    Wacky 2021/09/02
  • 【資料公開】マネジメント向けアジャイル開発概要

    みなさんこんにちは。@ryuzeeです。 2020年1月20日にとある企業の経営レベルの方向けにアジャイル開発の概要について説明した際の資料を公開します。 自社で経営者の方やマネージャーの方にアジャイル開発がなぜ必要なのかを説明する際の参考になれば幸いです。 (スライドはこちらからもご覧いただけます:https://slide.meguro.ryuzee.com/slides/101) 資料は、なぜ今アジャイルが必要なのかという点をまず理解していただけるようにコンテキストのすり合わせに主眼を置いています。 経営者やマネージャーの方にとってはスクラムの具体的なやり方といった手法部分はあまり関係なく、それによって組織がどういう影響を受けるのか、組織としてどんな取り組みをすべきなのかが分かることが重要なためです。 単一チームや小さなプロダクトでアジャイル開発をするのと、組織的にそれをスケールし

    【資料公開】マネジメント向けアジャイル開発概要
    Wacky
    Wacky 2020/01/20
  • statSVNで開発の状況を可視化する

    みなさんこんにちは。@ryuzeeです。 先日何人かに聞かれたので書くことにします。 うちはPHPでの開発が多いので、色々なオープンソースなツールを組み合わせて自動化に組み込んでいますが、Javaな人はSonarを使うとよいかもしれません。 statSVNって何?http://www.statsvn.org/にある通りで、Subversionのログを利用して以下のような分析をしてくれる。 ソースコードの行数推移開発者ごとのソースコード行数時間別のアクティビィティ分析開発者毎のアクティビィティ分析モジュール毎のアクティビィティ分析ディレクトリ毎の状況ファイル数や平均ファイルサイズ、巨大ファイル変更回数の多いファイルの分析コミットログの時系列での整形出力などなど インストール簡単です。 http://sourceforge.net/projects/statsvn/にアクセスし、statsvn

    statSVNで開発の状況を可視化する
    Wacky
    Wacky 2011/04/29
  • TraM0.2をリリースしました

    全世界5億人のTracユーザーのみなさんこんにちは。ということでタイトルの通りなのですが、TraMのTrac0.11対応版であるTraM0.2を日リリースしました。 ダウンロードはShibuya.Tracのレポジトリからどうぞ 以下にインストール手順や制限事項について記述しますので、導入の際は是非ご参照ください。また要望や不具合レポートは、このエントリにコメントを付けていただけると見落とさず対応できます。 概要 TraM(Trac Multi) は同一インスタンスを利用しているプロジェクトを俯瞰するツールです 必要なもの TraM0.2はTrac0.11でのみ動作します。 (Trac0.10用のTraMが必要な場合はhttp://trac.rectang.com/projects/tram/にアクセスしてください) Apacheとmod_python Clearsilver(>=0.10

    TraM0.2をリリースしました
    Wacky
    Wacky 2009/08/04
    TraM(Trac Multi) は同一インスタンスを利用しているプロジェクトを俯瞰するツールです
  • ソースコードレビュー | Ryuzee.com

    つい先日現在進行中の案件のソースコードレビューへの同席を要請されたので、一応もし品質悪かったら謝るのは俺だしぃ、ということで同席してみた。 結果分かったことについて書いておく。(前から分かっているけどさ) いくらちゃんと概要設計や詳細設計をしようが、品質はかなりの確率でコーディング力に依存する。 血と汗と涙と努力の結晶のようなソースコードは、ほぼ糞ソース。 こういう場合は大体1ファンクションがやたらと長いのと、あちこちで同じことが繰り返されていること間違いなし。なのでバグも繰り返し。 英語のスペル間違えているようなのも駄目。他の人がソースを読むかもしれないことに意識が回っていない。 バージョン管理しているのに既存ソースがコメントアウトでごっそり残っているのは危険。バージョン管理の意義を理解していないレベルの要員か現場だ。別にメインブランチでなくたって別ブランチに分岐して好きに履歴取れるの

    Wacky
    Wacky 2008/06/19
  • 1