マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -
プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
“Software Processes are Software, Too”
(ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです
マルチスレッド処理
複雑な問題を短時間で処理する方法の一つです。複数のスレッドを用いて並列処理すれば効率的です。シングルスレッドの処理をマルチスレッドで処理する場合、以下のような順になるでしょう。
- 並列処理の準備
- スレッド開始処理
- スレッドの主処理
- スレッド終了処理
- 並列処理の後処理
これらはマルチスレッドを考慮して設計します。うまく設計できればスレッド数に応じて効率化されますが、うまく設計できないで主処理以外のオーバーヘッドが多い場合はスレッドが増えても効率化できません。特にすべてのスレッドの完了を待つ場合は最も遅い処理に全体が引きずられるでしょう。
進捗管理・配員・作業分割/割り当て
並列処理の簡単な例は進捗管理です。リーダーが各メンバーから順にヒアリングするには多くの時間が必要ですが、メンバーそれぞれが進捗を報告すれば短時間で終わるでしょう。しかし、各メンバーがバラバラな形式で好きなタイミングで報告するなら、内容の把握や確認でかえって時間がかかるかもしれません。手分けする準備として情報共有の仕組みを用意しておけば、メンバーの処理が標準化でき、その管理や集約も容易になるでしょう。
配員の場合はさらに工夫が必要です。進捗や成果物の共有環境を用意するのはもちろんのこと、メンバーが独立に同程度の品質を保てるようにします。具体的には横展開できるように先行して部分開発してサンプルを用意します。サンプルは成果物だけでなく、部分開発を踏まえたルールや手順などを用意して、サンプルをたたき台に作業を横展開できるようにします。
作業の分割にも工夫が必要です。作業量を平準化しやすいように時間のかかる作業は細かな作業に分割します。また、マイルストーンに合わせないといけない作業とそれ以外を分けておき、予定通りに進まないときに作業の空きがないように工夫します。
作業の割り当てにも工夫が必要です。作業者の得意な作業を割り当てれば一見、効率的ですが、作業には偏りがあるので、作業量がバラツキが出て手が空いてしまったり、誰かが体調を壊すとプロジェクト全体が止まってしまうことになります。このようなことを防ぐには、教育的な視点で作業を割り当てたり、処理の実装とテストで担当者を分ける、ペア/モブプログラミング(作業)などを長期的な視点で取り入れると良いでしょう。
この記事はSRAアドベントカレンダーでも公開しています。
« カプセル化と組織パターン - Software Processes are Software, Too - | トップページ | One fact in one placeとチケット駆動開発 - Software Processes are Software, Too - »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
「プロジェクトマネジメント」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
« カプセル化と組織パターン - Software Processes are Software, Too - | トップページ | One fact in one placeとチケット駆動開発 - Software Processes are Software, Too - »
コメント