Workload estimation(작업량 추정)

한국어는 아래

In order to do everything, you need to know:

• what you need to do,
• how set the order of the tasks,
• who should do the work, and
• how long it takes.

The reason that the work is delayed or the quality of work is severely damaged is that job estimation activity is skipped

Looking at a recent book whose title is ‘team of teams’, I doubt ‘is this always right?’ Although it is doubtful, basically, most of the things of the non-complex world around us work well in this way.

That’s why I’m working on a project which is not related to software certification project, I’m participating in this way. Although I participated in the beginning of the assignment, I didn’t participate in a resource management plan that was very, very, very very, very very important in my assignment planning process, so it was quite difficult to work in a poorly established environment.

At that time, it could be a variable which is now fixed, and it would be useless to say that the constant had to be changed in order to complete.

Here, in fact, the estimation of the workload at the concept stage was already wrong, and there was a problem with resource allocation. The effect will continue to occur until the task is completed. As if the cesium accumulated in the human body continuously emitted radioactivity and affect the human body. (Is Japan ok now? -_-)

The method of estimating the workloads can be different depending on who carries out the work. So it is necessary to communicate with persons who will be assigned. Also, if there are variations that can occur here, depending on whether I have full control over the person in charge (i.e. whether I am a direct boss, fully penetrating the person’s schedule, and scheduling the person’s work) And can vary depending on how much the person can devote to the work (whether I am not interested in it, or whether I do my best to do nothing until it is not fired) is.

Because of these various variables, there is no formula to accurately calculate or determine workload. It is just an estimation.

In SW development, estimation is done in the following way.

1. Refer to projects you have done in the past.

2. Estimate considering velocity of the ongoing task. (In this case, monitoring activity is required to measure the progress speed.)

If there is no data to refer to, do atomic decomposition. Then, each workload is evaluated relative to each other. For example

T1 = 5 * t2

T2 = 3 * t3

T10 = n

T1 takes five times longer than t2. It is precisely five days or five weeks.

When you compare each other in this way and do a relative evaluation, you can maintain a balance between the workloads. Of course, several people participate in this evaluation. Participants are those who will eventually do the work, and because they are not assigned to ‘myself’ in the work, they do not selfishly increase their workload. And because it determines the ‘relative’ amount of work, it is 5n rather than 5days, so you can be willing, honest, and sincere to participate in decision making.

At the end, determine the unit of n (whether the unit is 1 day, 1 hour, or 2 days) and assign the workforce to do the work.

Of course, it will take time, but even though you can get the best efficiency, it will be much better than the time constant and the variables become constants, and these things become constraints and constantly damage the project schedule and quality.

 

모든 일을 하기 위해서는 어떤 작업을 해야 하는지를 알아야 하고, 작업의 순서를 정해야 하고,  그 작업을 누가 해야 하고, 그 작업이 얼마나 걸리는지를 알아야 한다. 보통 일을 하다가 일정이 지연되거나 일의 퀄리티가 심각하게 훼손되는 것은 이 작업을 하지 않기 때문이다.

최근에 본 team of teams 책을 보고, 이런 생각이 항상 옳은건가? 하는 의문이 들기는 하지만, 기본적으로 우리 주변의 비복잡계 세상의 일들은 대부분 이런식으로 하면 잘 먹힌다.

그래서 지금 참여하고 있는 소프트웨어 인증이 아닌 다른 프로젝트에서도 이런 방식으로 일을 하고 있다. 나름 그 과제의 초반에 참여하기는 했지만 과제 기획과정에서 매우매우매우매우매우매우매우매우매우 중요한 자원관리 계획에는 참여를 하지 못했기 때문에 판이 짜여진 상황에서 일을 하려니 일하기가 꽤 어려웠다.

그 당시에서 변경가능한 사항들이 참여하는 시점에서는 고정불변의 상수가 된 시점이었고, 그 일을 하기 위해서는 그 constant가 다른 값이어야 한다고 아무리 얘기를 해도 소용이 없는 상황이 된 것이다.

여기서 사실 concept단계에서의 작업량 추정이 이미 잘못되어 있었던 것이고, 그에 따라 자원 배분에 문제가 있었던 것이다. 그에 따른 영향은 과제가 종료될 때까지 지속적으로 발생한다. 마치 인체에 축적된 세슘이 지속적으로 방사능을 배출해서 인체에 영향을 끼치는 것과 비슷한 이치라고나 할까..(일본은 이제 괜찮은가? -_-)

작업량 추정의 방식은 그 작업을 누가 하느냐에 따라서도 기간이 달라질 수 있다. 그래서 작업담당자와의 의사소통이 필요하다. 또 여기서 발생할 수 있는 variation이 있다면, 그 담당자를 내가 온전히 control할 수 있는 관계인지(즉 내가 직속 상사이고, 그 사람의 스케줄에 대해서 완전히 꿰뚫고 있는지, 그리고 그 사람의 일을 스케줄링이 가능한지) 아닌지에 따라서 달라질 수 있으며, 그 사람이 얼마나 그 작업에 헌신할 수 있는지(본인은 그 일에 관심이 있는 것이 아니라, 짤리지 않을때까지 최선을 다해서 아무 일도 하지 않으려는 본성인지의 여부)에 따라서도 달라질 수 있다.

이런 여러가지 변수가 있기 때문에 작업량을 정확하게 계산하거나 결정하는 공식은 존재하지 않는다. 다만 추정할 뿐이다.

SW개발에서는 다음과 같은 방식으로 추정을 한다.

1. 과거에 수행했던 프로젝트를 참조한다.

2. 현재 진행중인 과제의 진행 속도를 참조한다. (이 경우 진행속도를 측정하기 위한 모니터링 활동이 필요하다.)

참조할 만한 데이터가 전혀 없는 경우 작업을 atomic decomposition을 한다. 그리고 각 작업량에 대한 상대평가를 한다. 예를 들면

t1 = 5*t2

t2 = 3*t3

t10 = n

t1은 t2보다 5배 작업 기간이 오래걸린다. 정확하게 5일인지 5주인지는 모르는 것이다.

이런 방식으로 서로를 비교하면서 상대평가를 하게 되면, 그 작업량들간에는 균형을 유지할 수 있게 된다. 물론 이 상대평가를 할 때에는 여러명이 참여를 한다. 참여자는 결국에는 그 일을 하게 될 사람들이고, 그 일에 대해 ‘본인’에게 할당된 것이 아니기 때문에 이기적으로 작업량을 늘리거나 하지 않게 된다. 그리고 어디까지 ‘상대적’ 작업량을 결정하기 때문에 5일이 아닌 5n을 결정하는 것이기 때문에 부담없이, 정직하고, 진실하게 의사결정에 참여할 수 있게 된다.

맨 마지막에는 n의 단위를 결정하고(1일인지, 1시간인지, 2일인지…), 그 일을 수행할 인력을 배정한다.

물론 시간이 소요되기는 하지만, 최적의 효율을 낼 수 있는데도 불구하고 시간이 흘러 변수가 상수가 되고, 그런 것들이 제약사항이 되어 프로젝트의 일정과 퀄리티에 지속적으로 데미지를 주는 것보다야 훨씬 나을 것이다.

 

Requirement elicitation and analysis (요구사항 수집 및 분석)

한국어는 아래로 스크롤..

When doing SW certification consulting, most customers are conceptually aware of what they need to develop and know roughly how to implement it. So the requirements collection and analysis phase was not too difficult.

However, in the project I am participating in, the customer did not have requirements. Obviously, there exists what we have to do, but the concept of what our team should do is not perfect either.

So I perform requirements collection and analysis activities.

It is a very vague and difficult task. I feel like I create a concept called iPad when the iPad does not exist in this world.

It is very vague and I need a lot of time. But there is not much time given in the project.

I want to get a consulting service for this project (Lesson learned is really valuable information).

In fact, this project is not a software development project, but a laboratory building project. I think it is a very different field, but I have found that there is not much difference. The similarity is that wherever I participate, “I” am only a consultant, and have little knowledge about a product.

I collects data from ‘domain experts’ and collects and identifies requirements. So I looked up useful resources. Here are some resources to help you do this.

These activities are called ‘requirements gathering and analysis’ activities, and related resources are found by Google.

Requirements Collection and Analysis (Lecture note)
When you want to write a requirement, there is a way to guide you to write it in a framework, which I do not personally prefer. I think there will be places where this area is appropriate.

SW Requirements Analysis Guide (Korean)

SW인증 컨설팅을 할 때, 대부분의 고객들은 자신이 무엇을 개발해야 하는지에 대해서는 개념적으로는 알고 있고, 어떻게 구현할지에 대해서도 대략적으로는 알고 있다. 그래서 요구사항 수집 및 분석 단계가 그리 어렵지 않았다.

하지만, 지금 참여하고 있는 프로젝트에서는 고객이 요구사항을 가지고 있지 않았다. 분명히 무엇을 하긴 해야 하는데 그 팀은 어떻게 해야 할지에 대한 개념 자체도 완벽하지 않다.

그래서 어쩌다보니 요구사항 수집 및 분석 활동을 하게 되었다.

굉장히 애매하고 어려운 작업이다. 마치 이 세상에 아이패드가 존재하지 않을때, 아이패드라는 컨셉을 만들어야 하는 느낌?

굉장히 막연하면서도 시간은 많이 필요하다는 느낌. 하지만 과제에서 주어진 시간은 별로 없다.

이것을 위해 컨설팅이라도 받고 싶은데(교육의 힘은 위대하다, 그리고 해 본 사람의 능력은 위대하다. Lesson learned 정보는 정말 귀한 정보이다) 가능할지 미지수이다.

사실, 이 프로젝트는 소프트웨어 개발 프로젝트가 아니라 시험소 건축 프로젝트이다. 굉장히 다른 분야라고 볼 수 있으나, 겪어보니 domain이 다를 뿐 크게 차이가 없다는 것을 알게 되었다. 비슷한 점은 어딜가나 ‘나’는 컨설턴트일 뿐이고 제품에 대해서는 철저한 문외한이다.

‘나’는 ‘도메인 전문가들’로부터 자료를 수집해서 요구사항을 수집하고 식별해낸다. 그래서 자료를 좀 찾아보았다. 이런 작업을 위해 도움이 될 만한 자료를 소개한다.

이런 활동을 ‘요구사항 수집 및 분석’활동이라고 하며, 관련 자료는 구글님이 다 찾아주신다.

요구사항 수집 및 분석자료(Lecture note)

요구사항을 작성하려고 할 때, Framework방식으로 기술하도록 가이드 하는 방식이 있는데, 개인적으로는 선호하지 않는다. 이런 분야가 적합한 곳도 있을 것이라고 생각은 든다.

SW요구 분석 가이드(Korean)

(scrap) good implementation skill

코딩 가이드라인으로 참조하기에 유용한 듯 하다.

implementation부분에 대한 것도 컨설턴트로서 깊이 관여하고 싶기는 하지만 현실적으로 여의치 않은 경우가 많은지라..

아래의 link가 c에 직접적으로 적용이 어려울 수도 있지만, 간접적으로는 가능한 부분도 많이 있다.

Anti-OOP: if를 피하는 법

좋은 분기문(if) 작성법