ソフトウェア開発における三種の神器、
バージョン管理システム
チケット管理システム
CI ( ウェブサービスならデプロイ、組み込みなら実機テスト )
無いと始まらないねこのへんは。
ソフトウェア開発に限らず、バージョン管理システムは使うべきだし、
チケット管理システムベースで仕事を進めるべき。
早くても質の悪い仕事じゃ意味ないので、仕事の成果を検証するためにもCIがあるべき。
私はソフトウェア開発者としてキャリアをスタートしたわけだけど、
幸い複数の部門で複数の働き方をすることが出来た。
おかげでどういったワークフローが良いモノなのかがざっくり見えてきたので、
ここで言語化してみる。
====================================================
まずは、Atlassian 様が紹介する以下の動画を見ると良い。(Angry Nerds とかワロタ)
JIRA はツールとしてかなり洗練されている。
洗練されすぎている。。!!
このシステムに乗っかって仕事していけば勝手に効率的に仕事が進むんではなかろうか。
ただし、Agile とかスクラムとか出てくるので何かしら勉強する必要があるけど。
日本語で読みやすい本はこれかな。
自分は Agile マンセーな環境にいたので、仕事していくうちに勝手に覚えていきました。
( はじめはなんだよアジャイルって。カタカナうぜえよ☆ なんて思ってました、ごめんなさい。 )
ワークフローにおいて重要だと思ったポイントは3つ。
* 2週間の単位でスプリントを切ること
夏休みの宿題を思い出そう。
およそ1ヶ月分の課題がドカっと与えられて「やっとけよ」って放置されるあのシステム。
狂気の沙汰です。
よっぽど効率的にさばけませんでした。
プロジェクトとして終わっとります。
学校の先生がアジャイルマスターだったら学生は間違いなく幸せ。
人間、締切がないと頑張らない。
そこで、2週間とかある程度の時間間隔を設けて締切を作るわけです。
この時間間隔をスプリントとか呼びます。
自然と優先度を考えたり、こなす業務の計画が立てやすくなります。
* 業務のストーリー化
会社組織は構造化されています。
平社員課長部長ほげほげって感じに。
一般に管理職と言われている方々はたくさんの人の仕事を管理しますよね。
しかしあんまり詳細まで見てられないです。
全部の仕事をしっかり見て評価するなんてそもそも無理なんですよ。
マネージャー視点からすると、こんなかんじじゃないでしょうか。
「こまけーこたぁいいから働け。進捗・成果は簡潔に教えろ」
みたいな。
簡潔に ⇔ 細部はいいからざっくりと ⇔ ある程度抽象化してって感じにも言い換えられます。
マネージャーが見てわかるレベルの抽象度で文章化されたお仕事のこと。
これ、「ストーリー」とか言います。
基本的には、「HogeがHogeできるようにする」といったテンプレな形の文章に落とし込みます。
フォーマットがあったほうが簡単に作れるし、マネージャーも把握しやすいし。
* ストーリーの分割
作ったストーリーは、抽象度が高いので、すぐにアクションに結びつきづらいです。
次は大きな単位のストーリーをタスク分割して仕事の粒度を細かくします。
細かくしたものはタスクとかサブタスクとか呼ばれます。
タスクを小さくすると何をすればよいかがより具体的に。
ソフトウェア開発であれば実装レベルまでタスクが具体化される感じです。
ここまで落ちてくればあとは Githubだのなんだのでプルリクだしちゃって開発ブランチにマージしちゃう感じ。
ソフトウェア開発における、ワークフローは色んなモノが提唱されてきた。
平たく言えば、
仕事に期限を設ける
大きな仕事は分割する
成果はチェックする
といったもので、事務職とかでもこのワークフローって回せるんじゃないかな。
Atlassian はこう言ってます。
非常に腑に落ちた動画でした。
バージョン管理システム
チケット管理システム
CI ( ウェブサービスならデプロイ、組み込みなら実機テスト )
無いと始まらないねこのへんは。
ソフトウェア開発に限らず、バージョン管理システムは使うべきだし、
チケット管理システムベースで仕事を進めるべき。
早くても質の悪い仕事じゃ意味ないので、仕事の成果を検証するためにもCIがあるべき。
私はソフトウェア開発者としてキャリアをスタートしたわけだけど、
幸い複数の部門で複数の働き方をすることが出来た。
おかげでどういったワークフローが良いモノなのかがざっくり見えてきたので、
ここで言語化してみる。
====================================================
まずは、Atlassian 様が紹介する以下の動画を見ると良い。(Angry Nerds とかワロタ)
JIRA はツールとしてかなり洗練されている。
洗練されすぎている。。!!
このシステムに乗っかって仕事していけば勝手に効率的に仕事が進むんではなかろうか。
ただし、Agile とかスクラムとか出てくるので何かしら勉強する必要があるけど。
日本語で読みやすい本はこれかな。
自分は Agile マンセーな環境にいたので、仕事していくうちに勝手に覚えていきました。
( はじめはなんだよアジャイルって。カタカナうぜえよ☆ なんて思ってました、ごめんなさい。 )
ワークフローにおいて重要だと思ったポイントは3つ。
* 2週間の単位でスプリントを切ること
夏休みの宿題を思い出そう。
およそ1ヶ月分の課題がドカっと与えられて「やっとけよ」って放置されるあのシステム。
狂気の沙汰です。
よっぽど効率的にさばけませんでした。
プロジェクトとして終わっとります。
学校の先生がアジャイルマスターだったら学生は間違いなく幸せ。
人間、締切がないと頑張らない。
そこで、2週間とかある程度の時間間隔を設けて締切を作るわけです。
この時間間隔をスプリントとか呼びます。
自然と優先度を考えたり、こなす業務の計画が立てやすくなります。
* 業務のストーリー化
会社組織は構造化されています。
平社員課長部長ほげほげって感じに。
一般に管理職と言われている方々はたくさんの人の仕事を管理しますよね。
しかしあんまり詳細まで見てられないです。
全部の仕事をしっかり見て評価するなんてそもそも無理なんですよ。
マネージャー視点からすると、こんなかんじじゃないでしょうか。
「こまけーこたぁいいから働け。進捗・成果は簡潔に教えろ」
みたいな。
簡潔に ⇔ 細部はいいからざっくりと ⇔ ある程度抽象化してって感じにも言い換えられます。
マネージャーが見てわかるレベルの抽象度で文章化されたお仕事のこと。
これ、「ストーリー」とか言います。
基本的には、「HogeがHogeできるようにする」といったテンプレな形の文章に落とし込みます。
フォーマットがあったほうが簡単に作れるし、マネージャーも把握しやすいし。
* ストーリーの分割
作ったストーリーは、抽象度が高いので、すぐにアクションに結びつきづらいです。
次は大きな単位のストーリーをタスク分割して仕事の粒度を細かくします。
細かくしたものはタスクとかサブタスクとか呼ばれます。
タスクを小さくすると何をすればよいかがより具体的に。
ソフトウェア開発であれば実装レベルまでタスクが具体化される感じです。
ここまで落ちてくればあとは Githubだのなんだのでプルリクだしちゃって開発ブランチにマージしちゃう感じ。
ソフトウェア開発における、ワークフローは色んなモノが提唱されてきた。
平たく言えば、
仕事に期限を設ける
大きな仕事は分割する
成果はチェックする
といったもので、事務職とかでもこのワークフローって回せるんじゃないかな。
Atlassian はこう言ってます。
We believe that Agile is not just for software development teams.
Agile > Finance, Design, Marketing, ...
非常に腑に落ちた動画でした。
コメント
コメントを投稿