Dude, your schedule

Dude, your schedule

Zhou yinhui

It is said that Xplanner In Team It was popular for some time, but was then silently swept into the garbage bin of history. (Note: Xplanner Is Web Of XP Team planning management and tracking tools. XP Unique development concepts such Iteration , User stories , XplannerAll provide corresponding management tools, Xplanner Supported XP Development Process and exploitation XP Idea to develop the problems encountered by the project. Xplanner Features include: Simple Model planning and virtual note cards (Virtual note cards) , Iterations , User stories Tracking of work records, incomplete Stories Automatic iteration, working time tracking, generating team efficiency, personal work hour report, Soap Interface Support) later we realized that this was a pity, although it was used at the "Review Conference" a month ago. XplannerMany of my colleagues are still hesitant, but I and some of my colleagues still insist on using it. Now it seems that the persistence at that time is very correct. Some of my colleagues' hesitation is understandable, because I have had similar concerns: division of tasks and estimation of time are indeed a challenge. However, development without a schedule is tantamount to suicide. Although there must be a more coarse-grained timetable (for example, when to release a new version) beyond the control of developers, we cannot know the latest development status by relying on this, I don't even know if I can send my package on time. I don't want anyone to lose most of the market share because of the delay in product release like Wangjing, and become a negative tutorial in many books.

In fact, estimation of the task time is not only a challenge for developers, but also a challenge for bosses. Bosses are also afraid to pat their heads and say,"OK, Three months ". Then I cannot know the actual needs of my team.6It takes only one month to complete. A funny saying is that "when a project is started, the project is shot in the thigh, and the project is ended, the project is shot in the ass ". Sticking to the schedule can greatly avoid this situation. First, the result is a long time of exploration. The boss can understand his team's abilities and can well estimate the project time, second, you can use the schedule to find out as early as possible when the time is not enough, and then you can take appropriate measures, for example, cut off some relatively unimportant and time-consuming features and save time to those very important features. The benefits for developers are also obvious. We can arrange tasks well and estimate the number of tasks we can complete during the current period, one is to make your work more organized and efficient, and the other is to detect existing risks as soon as possible (for example, a task is indeed time-consuming and can be completed only by learning new knowledge in addition to the workload) then, you can find these risks at the very beginning of the task and ask your boss in time, instead of waiting for the packet to be sent to explain, "I am really working very hard, but I am not sure, there are too many tasks. Do not be afraid of inaccurate task time estimates or inaccurate tasks (we cannot fully predict the future). However, this is an accumulation of experience that has been accumulated for a long time, the more time you estimate, the closer it actually consumes.

1,This articleArticleNoXplannerAdvertisement

It should be declared that the reason why many points are mentioned in this ArticleXplannerIt is because I am using it now and feel very good. The main purpose of this article is to demonstrate the importance of the schedule and relevant lessons. I cannot make good recommendations on what tools I use. I have insufficient experience in this regard and need to learn more.XplannerVisit here:Http://www.xplanner.org/. However, it is said thatMicrosoft ProjectAnd so on. In factMicrosoft ExcelIt is also a good choice.

2,The schedule is not a work-hour report.

Fortunately, we are not a hourly engineer; otherwise, the schedule is very likely to be a work hour report. Unfortunately, the schedule does not support this function. If someone wants to do this, it may be a big mistake. The task time in the employee schedule may be dragged down for a long time, and the employee may wish to include the start and shutdown into the schedule to indicate that he has been working.

3,The schedule is not the work of the bosses.

The schedule discussed here is not arranged by the bosses, but planned and filled by the developers themselves. A simple truth is, only the developer knows the time required to complete the task. It would be too bad to have your manager fill out a schedule for you, unless he knows yourself and the task details better than you. This involves a problem (but at least we haven't met it yet, but some other teams may encounter this problem ): your manager thinks that you have placed too much time on a small task. This is a terrible problem. I feel that the boss should pay attention to the rationality of your plan and give proper guidance, without any reason to compress the time, after all, you are the most familiar with the task time. In this case, you don't have to worry about it. You can change the estimated time to the time that the boss thinks is reasonable, but keep the time that you think is reasonable in the remarks. On the other hand, as developers, we have the obligation and responsibility to make the schedule more reasonable.

4,Schedule table structure

Follow Xplanner In terms of structure, there are mainly Story And Task A schedule contains several Story , One Story Contains several Task . For Story Can be understood Feature Or yes. Case , Its granularity Ratio Task Big, and Task This is what we call Case. As far as our experience is concerned, I prefer to divide tasks according to the process, for example, from determining the requirements to writing design documents to coding (of course, the actual Task The granularity is much smaller than the granularity of these words, Task The granularity should be small, as small as "Hour", rather than "day", which will be discussed later ). Then Task It should contain at least the following items: Task Name, task content, and Story , Task implementer, task tracker, priority, scheduled time, used time, remaining time, actual time used to complete the task, etc. But I still insist Task It should also be simple and clear. First, it should be clear at a glance, second, it should be time-saving, and third, it should be prevented from resistance of team members. Task There are not too many fields to be filled in.

5,Small Task Granularity

The Task Granularity cannot be large, story rather than task . The recommendation granularity is based on "hours" rather than "days, A good experience of one of my colleagues is to refine the task to 4 hour or 8 hour or less, and maintain task integrity as much as possible (meaning, it is not recommended that you get off work when you are just half done.) This is conducive to "Daily check" ( daily check in ) and" Daily build "( daily build ). The granularity is too large. The obvious drawback is that the time estimation error is very large. If it is a brand-new task (instead of a task that you have repeated countless times) however, it is of little significance to give a reference of "I need about three days. In addition, I have a failure experience. When I use Outlook specifies a task for itself, if I only specify a task in the future, 3 if the task is completed within days, the task is often postponed until the third day to start, or even be delayed for a longer period of time. The correct approach is, even if the task requires 3 days, the task should be split into 3 parts (or more) and allocated to each day, today's event is complete.

6,Debugging, integration, and other things are time consuming.

In particular, debugging takes a long time to make people have a headache and an inevitable situation.20Modify a row in secondsCodeFrom the open project, check out (Check out) File, to modify the code andBuildThe project and final debugging will take dozens of times as expected. Maybe the example I gave is a bit extreme, but in general, debugging takes time Encoding1 ~ 2Times. Don't be surprised, and you must never ignore these factors. Although the debugging time is so difficult to estimate, you must take it into account in the task time estimation, otherwise, your time will seem so tight that you have to work overtime (and then the wife complained that you didn't have time to accompany her and never looked after the children....). Other things, such as upgrading development tools, are time-consuming items in the schedule.

7,Buffer added to the schedule

This is a question worth discussing, because our schedule does not seem to have a buffer, that is, there is no spare time to deal with the following situations: first, the actual task time is much longer than the estimated time. This may be because our estimation error or development is delayed due to other reasons; second, newly added tasks or features that were previously cut down must be re-added. Although it is not easy to add new tasks from an ideal perspective, it is not ruled out, in addition, from the market perspective, we must append a feature to make the product more advantageous.

8,Daily update schedule

Since one of the purposes of using a schedule is to reflect the progress of the current project, it is necessary to update the schedule every day, which only takes less than minutes. However, when we accidentally forget it, the current method is to useOutlookGroup oneMeeting RequestThen, the daily scheduled reminder (such as half an hour before work) and the "standing meeting "(Standup MEETINGIf no updates have been made to the previous schedule, everyone will know....).

9,Analysis schedule

If you knowXplannerOrProjectIt will show a lot of charts to analyze the problems reflected by the schedule. As for how to use these charts to analyze these schedules, you can refer to the relevant documentation, which is skipped here. However, it is worth noting that during the preparation of the schedule, you should pay attention to the areas that will affect these charts so that the charts can reflect problems more realistically.