手順書フォーマットは千差万別 みなさんは自己流または、組織やプロジェクトで定められた手順書のフォーマットはありますか? 私は自己流の手順書フォーマットがあります。 自己流の手順書フォーマットがあるといっても、かなり扱いがふわふわしているので、備忘やメモの意味合い強めでまとめていきます。 「もっとこうした方がいいよ!!」などフィードバックがあれば、ぜひお願いします! いきなりまとめ 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書はgitで管理する 5W1Hを意識して手順書を書く 基本的にはCLIを使った手順書にする 手順書はExcelやスプレッドシートではなく、Markdownで書く 手順書をExcelやスプレッドシートで書くメリット・デメリット 手順書をExcelやスプレッドシートで書いている方も多いと思いますが、私はMarkdownで書いています。 Exce

プロジェクトを機能・ストーリー・タスクに分割する方法と、それぞれの見積もり、優先順位付け、スケジューリングのガイダンスを提供します。 見積もりは細かく細分化するほど精度を上げることができるのは明らかです。しかしその代償として時間がかかります。不正確にすべきではありませんが、見積もりのコストは抑えたいと考えます。 有効な技法として「三点見積り」があります。この見積りは、「最良ケース」「最有力ケース」「最悪ケース」の３つの数値で構成されます。これらの数値は信頼性のより見積もられます。これはPERT法として調べると詳しい情報が得られるでしょう。 しかしながら三点見積りは長期のプロジェクトには有力ですが、プロジェクト内部のマネジメントで使うには精度が悪すぎるため、「ストーリーポイント」を用いるとよいということです。 ユーザー視点での機能であるユーザーストーリーに対し、具体的な時間の工数ではなく、相

僕としてはGoのおすすめのフレームワークを聞かれたら、標準ライブラリのnet/httpと答えるようにしています。というよりも、Goの他のフレームワークと呼ばれているものは、このnet/httpのラッパーでしかないからです。 Goでアプリケーションを作成する場合のイメージは次の通り。battery includedなアプローチは他の言語でもたまにありますが、ついてくる機能が今時のものが多くて、標準ライブラリで済むことが多いです。ウェブ開発についてもそんな感じです。 PythonとかRubyとかもそうですが、言語組み込みのウェブサーバー機能はテスト用で本番運用には機能が足りない、性能が足りない、ということから「プロダクションに耐えうるフレームワークを別に入れないと」と思う人も多いんじゃないかな、と思いますが、Goの場合は組み込みのサーバーで問題なかったりします。Node.jsに近いかも？ 世間