Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to evaluate the working hours of development tasks is more reasonable". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. let's study and learn "how to evaluate the working hours of development tasks is more reasonable"!

Why evaluate working hours?

In the process of agile development, we focus on fast iteration, through small steps and fast running, deliver available products to users as soon as possible, constantly improve user experience, win user recognition and meet the needs of business development.

When the product manager puts forward a demand, as the demand side, such as the marketing department, the operation department or the customer, all hope that the demand can be put online as soon as possible, and expect to know the time node that is expected to be online, in order to arrange the next work plan.

The online time of the requirements, backwards, need to be evaluated by the developers involved in this requirement before a relatively accurate schedule can be given. Finally, the abstract requirements are broken down into small tasks that each technician can accomplish within a specified period of time. When the task working hours are evaluated, the project manager or technical leader can sort out the time nodes and project milestones of the entire requirements, and then feedback them to the demand side.

In this way, from demand to task, from man-hour evaluation to project scheduling, it forms a positive and good feedback mechanism, which can not only clarify the division of responsibilities, but also improve the efficiency of team cooperation. Agile development is more approachable and efficient.

Why is it so difficult to evaluate development hours?

However, with regard to the evaluation of working hours, there will be some contradictions in the actual situation.

On the one hand, as a product staff, usually feel that this requirement is very simple, isn't it just to change a few lines of code? It'll be done in a few minutes. On the other hand, as a boss who doesn't know much about technology, he often doesn't know whether the workload assessed by technicians is too high.

In addition, as technicians themselves, the assessment of working hours is also a very challenging thing.

Why? According to the summary of many years of project experience, I think there are two main factors. Uncertainty and mission scenarios.

Uncertainty refers to the uncertainty of demand and future. It is possible that the requirements themselves are vague or imperfect, without indicating in detail or in the form of documentation the pages, functions, logic, rules and processes that need to be changed, or it is also possible that the product personnel have become very familiar with the requirements themselves after constant communication, but they will be very strange to the technology that comes into contact with the requirements for the first time. Even if the requirements themselves are very clear, there are detailed requirements documents. Because of the complexity and relevance of the business system, changing this process may affect other processes, and then modify other modules, resulting in more work. To put it simply, it is difficult for technicians or other personnel to judge from the beginning whether changing this requirement will have implications and impact on other functional modules. For example, in chess, it is difficult to predict thousands of different endings from the beginning.

Task scenario means that for the same requirement, there will be great differences in different contextual scenarios. For example, developing a login function is different for interns and senior development engineers, or for employees who have just started and have been on the job for several years. It is also different to develop a login function and do a new login function, which is not the same as modifying or upgrading existing functions in the existing system. Because the modification of the existing system has a historical burden, it is not only necessary to have a good understanding of the original business logic, but also may need to carry out additional processing of the historical data. If it is a new system, we also need to build the infrastructure. In addition, it depends on whether you need to dock with an external third party. If the login function requires access to Wechat login, or LDAP login, or SSO login, but also need to be familiar with the external access process, communication and debugging is also a very time-consuming and costly thing. Finally, it depends on the current technical staff in charge of development, whether there are any other requirements and tasks. In summary, the task scenario should take into account environmental factors other than the requirements, including, but not limited to, the professional competence and working years of the technical personnel, the scheduled needs and tasks, and external communication.

How to evaluate working hours is more reasonable?

How to evaluate working hours depends on how we will do this requirement.

Once in my sharing PPT, I suggest not to spend time only on development and debugging, but to arrange your time more reasonably, in addition to coding development, but also for responsible requirements, actively communicate and confirm, but also learn to write documents, UML modeling, unit testing, and small steps of refactoring by the way.

Generally speaking, when a requirement is done, the main tasks required are: writing code, meeting, co-tuning front and rear, writing documents, testing and changing BUG, and technical research. Make it clear what we are going to do, combined with our own task scenario, then when evaluating the task, it will be very clear.

According to the requirements you receive, combined with the existing code repositories and code modules, after you are familiar with the existing systems, business logic, and new requirements, you can begin to sort out the functional requirements matrix of this requirement. The functional requirements matrix refers to associating the functional points of the requirements with the visible interface links or specific interface links, and marking the core technical implementation, such as what new database fields are added at the back end. Finally, don't forget to add one more note, and then carefully consider whether there are any forgotten areas and uncertainties. The more carefully you organize, the more accurate your work evaluation will be and the more efficient your work will be.

For example:

Demand

APP client

H5 mobile terminal

PC web version

Low-level technology implementation

Remarks

Add a new mobile number to log in quickly

Added API API: mobile number verification code login API

Added API API: mobile number verification code login API

Modify the original login page:

Http://xxx.demo.com/login.html

Using SSO to achieve single sign-on

With these analyses and preparations, and through the functional requirements matrix, if you can provide technical development documents and UML, then your task assessment will be more reasonable and make people very clear about your work. Naturally, you can get more people to recognize your working hours assessment.

Evaluation, implementation, feedback and promotion

After ten years of interconnected project development, I have found that the more detailed the tasks are, the more productive the programmers are. Because they can evaluate abstract tasks into task units that are easy to perform, quantifiable and controllable, and then execute.

In the process of implementation, pay attention to the timely feedback during the implementation process, not after the implementation. When the requirements are not clear, they will find the demand side for confirmation and communication; when the interface or interface is ready, they will take the initiative to find the corresponding technical personnel for joint technical debugging; when the function is developed, they will carry out self-test, code review and code refactoring; when problems are found, they will respond in time; when the test passes, they will prepare for launch and list confirmation in advance. When the release is launched, they will confirm the online within half an hour and inform the product manager, "this requirement has been launched, please check and accept it in time."

Feedback is really important.

In this way, after constantly iterating, completing one development task after another, and overcoming one difficult problem and another challenge, you will find that you have been climbing the slope all the time, and all of a sudden you will find that you are not long away from the ashes-level technology Daniel.

The harder you work, the luckier you are!

How can teams collaborate on development tasks efficiently?

Previously, I have shared how individuals evaluate task work and how to develop quickly. Next, let's discuss how teams can collaborate and develop efficiently. As a team, the more closely you work together, the higher the overall efficiency and morale will be.

A project, done, has several obvious characteristics: long time period, large number of participants, and complex information. If it is not properly arranged, it is difficult to give greater value to each of the technicians involved.

The following practices are worth referring to:

Plan on Monday and summarize on Friday.

The demand is responsive and the project is on schedule.

Make a plan on Monday

Every Monday is not only a day for many regular meetings, but also a new day every week. On this day, if you can systematically sort out last week's work and this week's goals, assign them to everyone, and then let each technician evaluate and plan the development tasks, it will form the work schedule of the whole team for this week.

For example, in YesDev's work schedule, the following is our team's work plan for this week. When I used to work in an enterprise, I had to summarize the work and task hours of the team every week. I was very painful because I had to manually summarize the working hours of nearly 10 people on the team, but with the work schedule here, I could directly export Excel and send it to the boss at once. Hello, everyone! ^ _ ^

YesDev also has a great tool that allows you to quickly see his job saturation when you are assigning tasks.

2. Summarize on Friday

Before leaving work on Friday, in the form of a weekly report, ask everyone on the team to report on the work of this week, the tasks completed and the plans for the next week, which is not only a summary and promotion of everyone, but also an important channel for the whole team to report upward. Make your work visible and your team's achievements visible. More importantly, one email a week, about 50 emails a year. How did we break through this year? review these emails and you will clearly see what roads we have traveled and what important milestones we have crossed. Not only can we look back on the past, but we cannot look forward to the future. The attitude of doing things seriously is bound to achieve more remarkable results!

In YesDev, for weekly newspaper, there is a great innovation, that is, according to everyone's work situation, everyone's work weekly report can be generated automatically, which greatly saves the time of writing email. After saving, you can also send it directly to the team or your supervisor.

3. The demand is responsive

When the product manager puts forward the requirement, the technical staff responsible for the requirement will receive the email notification in time. When the requirements are completed, the product manager can also receive the relevant email notification in time. If you are neither a product manager nor a technician, if you are interested in this requirement, you can follow it. Then you can also receive the latest notification of requirements in a timely manner.

For example, an email notification like this:

4. The project is in progress.

First of all, after the task evaluation of the project, you will get a task list. This part needs to be evaluated by the technicians themselves.

After the evaluation is completed, you can automatically get the project schedule and the project burnout diagram.

The project schedule automatically generates important responsible persons, time nodes and project milestones, which makes it convenient for project managers or technical leaders to carry out project management and team collaboration.

Project scheduling is static and theoretical. The burnout plan of the project is the actual implementation. It's like setting a goal of running 5 kilometers after work today, which is expected to be finished in 30 minutes. Maybe in the end, you only ran 3 kilometers and it took you an hour. Because I can't run anymore.

Thank you for your reading. the above is the content of "how to evaluate the working hours of development tasks more reasonable". After the study of this article, I believe you have a deeper understanding of the problem of how to evaluate the working hours of development tasks more reasonable. the specific use of the situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.