Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き - TechとPoemeの間
これはなに 世の中の3人~8人程度のソフトウェア / システム開発チームの多くは，俗に言う「アジャイルな開発手法」のプラクティスを実践し，1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。 そして，日本の多くの現場では，「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います． 私が開発リードを務めているチームでは，KPT とは違ったフレームワークで週に1度のふりかえりを行っていて，割とうまくいっていると思っているので，それを紹介しようと思います． KPT は「チーム」のふりかえりには向かない 最近個人的に思っているのは，KPT はチームのふりかえりには
今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間
株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン
「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」 - TechとPoemeの間
TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない． 「HRT」は人に向けるものであり，ソフトウェアに向けるものではない． プログラマの三大美徳 プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる． 詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ． 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
