スムーズに進行するためのエンジニアリングタスク分割の工夫 - $shibayu36->blog;
会社の振り返りで「エンジニアリングの作業タスクがうまく分割できていそうだったが、その知見を共有してほしい」と言われたので、自分がどう考えてタスク分割をしているかをこの記事で共有したい。 この記事のスコープとすること・しないこと タスク分割をするときの工夫点 少なくとも1スプリント以内で終わるタスクになっている 完了条件が明確である 開始から終了まで他タスクによる待ち時間がない 他タスクが待ち状態になる時間を最小限にする 自分にとって難易度の高いものが1タスクの中で1つである 初めから完璧なタスク分割を目指さない 工夫を考慮した分割例 まとめ この記事のスコープとすること・しないこと 今回の記事では、あるユーザーストーリーが存在するとして、その設計・実装・テストなどをスムーズに進行するための工夫について書く。 逆に次のようなタスク分割については取り扱わない。 ユーザーに提供すべき価値があると
Re: チームのベロシティを上げる vs. 安定させる - $shibayu36->blog;
yigarashi.hatenablog.com これが良い話だなと思ったので感想メモ。 「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象 「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち 何となく、悲観
開発パフォーマンス指標とバリューストリームマップでチーム改善をする - $shibayu36->blog;
以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。 前回の記事のサマリー バリューストリームマップを作り、開発フローの課題を発見する バリューストリームマップとは何か チームのバリューストリームマップを作る バリューストリームマップから課題を見つける 見つかった課題を解決する 開発パフォーマンスの指標で改善結果を振り返る まとめ：データを根拠にチーム改善するという進歩 参考 前回の記事のサマリー 前回の記事を前提として書くため、簡単にサマリーすると 開
開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する」としてみた話 - $shibayu36->blog;
最近開発チームの改善を行う時に、どういう目的で開発チーム改善を行うのかや、開発チームの責務は何なのかについて悩んでいた。色々本を参考にしながら、自分の中でしっくり来た責務があったので、ブログにまとめておく。 まず自分の中で、開発チームの責務は次のものであると言語化した。 エンジニアリング観点でのサービス継続リスクをコントロールしながら、開発速度を最大化する なぜこの責務としたか まず現代のソフトウェア開発においては、非常に不確実な状況で、顧客にとって価値があるものが何かを探索しながら、高速に価値を創出・提供しなければならない。これを満たすためには、「正しいものをつくる」ということと、「正しくつくる」ということの両輪を回す必要がある。 この時、プロダクトオーナー側と開発チーム側で分業するとすれば、やはり開発チームは「正しくつくる」ことに焦点を当てて責務を持つと良いと考えた。つまり開発速度(価
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
良かったことは良かったとはっきりフィードバックする - $shibayu36->blog;
最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
「オブジェクト指向入門 第11章 契約による設計」を読んだ - $shibayu36->blog;
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon これまでの続きで、「オブジェクト指向入門 第11章 契約による設計」を読んだ。「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog; で紹介した抽象データ型と同様に非常に面白い章であった。プログラムの設計を考える時に役立ちそうな知識が自分の中で言語化されたので、今後の設計時や、コードレビューの指摘の時にも役に立ちそう。 この章は信頼性の高いソフトウェアを記述するために、表明という概念を解説してくれる。例えば、ソフトウェアが正しいとは何かについての議論や、事前条件・事後条件・クラス不変表明のような表明の種類の説明、それぞれの表明の役割、表明の使いみち、表明の監視などについての
「オブジェクト指向入門 第2版」の上下巻を全て読み終えた - $shibayu36->blog;
「オブジェクト指向入門 第2版 方法論・実践」を読み終えた。これでようやく「オブジェクト指向入門 第2版」を全て読み終えることが出来た。読むのは確かに大変だったけど、抽象データ型や契約による設計などといったエンジニアにとって役立つ概念を学ぶことができ、今後のプログラムの設計に大いに役立つだろうと思った。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 上巻 原則・コンセプト 上巻は特に「第3章 モジュール性」、「第6章 抽象データ型」、「第11章 契約による設計」の3つの章が面白かった
実践に繋げるように勉強する - $shibayu36->blog;
遅延評価勉強法だと得られなかったもの - As a Futurist... 漢(オトコ)のコンピュータ道: ヒゲモジャのギークが提案する技術習得戦略 を読んで、なんとなく気分が高まったので、自分の学習のことについて書いてみる。 以下の様なことを書いているつもり。 勉強は実践につなげると知識が定着すると思っている 実践課題を探すのではなくて、実践の目処のあるものを勉強する 一番簡単な実践課題として、自分の言葉でまとめ直すということをしている 実践に繋げる 僕は勉強する時は、いろいろ本を読んだり、情報を調べたりして、まず知識をつけようとすることが多い。ただし、それだけだとだめで、実践しないと知識が定着せず、どんどん忘れていき、結局意味ないということになる。実践大事。 大事なのはわかってるんだけど、実践するのは意外と難しい。本に練習問題あったりすることもあるけどあんまり面白くないし、良い実践課題
「オブジェクト指向入門 第2版 原則・コンセプト」を読み終えた - $shibayu36->blog;
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon まだ上巻だけどようやく読み終えた。大変だけど非常に有意義な本だった。 この本はいろいろ話題があるけど、第3章 モジュール性、第6章 抽象データ型、第11章 契約による設計の３つの章が面白かった。これまでに感想を書いたブログは以下のとおりなので興味があれば参考にどうぞ。 「オブジェクト指向入門 第3章モジュール性」メモ - $shibayu36->blog; 「オブジェクト指向入門 第6章 抽象データ型」を読んだ - $shibayu36->blog; オブジェクト指向入門 第7章〜第10章を読んだ - $shibayu36->blog; 「オブジェクト指向入門 第11章 契約による設計」を読んだ - $shiba
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog;
最近フロントエンドの速度改善をほんの少しだけやって、いろんな資料を参考にしたので、今後また速度改善をする時に備えて、参考になった資料をまとめておく。今回パフォーマンス改善やった項目としてはExpiresヘッダ付ける、gzip圧縮かける、JSをbodyの一番下にとか基本的なことしかやらなかったので、そのあたりはこの記事ではまとめていません。 今回は「測定する」「ブラウザがどう表示しているか知る」「改善を検討する」の流れで調べていったのでその順にまとめる。 測定する 何はともあれ測定しないと何も始まらないので、まずは測定の仕方について調べた。 PageSpeed Insights( https://developers.google.com/speed/pagespeed/insights/ )と、webpagetest( http://www.webpagetest.org/ ) はとりあえ
curlとjqで簡単にAPIの調査をする - $shibayu36->blog;
ちょっとAPIを調査したいと思った時に、スクリプトを書くのも面倒なのでcurlとjqとかを利用してみたら、便利だったのでメモ。今回はTrelloをちょっといじってみた。 Redirecter ひとまずcurlでjsonを出す これは普通にcurlするだけ。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards'これでは見づらい。 curlで出たjsonをpretty化する jqに通すだけでpretty化と更に色付けされる。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards' | jq '.' curlで出たjsonの一部だけ表示する jqはjsonをいろいろ絞り込み出来る。 例えばリストの5件目まで表示。 curl 'h
職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
