Agile development One Thousand and One Q Series 17: What should I do if I have been subject to strong customers for a long time? (I)

Document directory

• Solution 1: Technically productization of projects
• Solution 2: extract semi-finished products

This is the first article in The One Thousand and One Q & A series of agile development. (Here, I would like to ask, one, two, three, and the General Directory of the question)

This is a question raised in an Open Class for telecom industry suppliers and is rated as the best question in this field.

For such "Suppliers", on the one hand, the business is deep-rooted and generally solidified in some proprietary fields, so it is necessary to productize the product; on the other hand, it is difficult to have their own autonomy because the customer always changes back and forth. The conflicts between the two can be solved by gradually promoting agile development, and a large number of peripheral technologies, management, and market means are also required.

On the other hand, agile development knowledge can assist in the implementation of these technologies, management, and marketing techniques.

Problem

What should I do if I am subject to strong customers for a long time?

Solution

In most cases, the customer will lead to the long-term existence of "reusable Projects" for development activities, rather than "one-of-the-box product. So this article will talk more about project development rather than product development, but it will follow the path of Project productization, because this is almost the only way out for project companies.

Old rules: the previous solution is the simplest and can be executed almost immediately. The later solution is the ultimate path, though difficult.

Solution 1: Technically productization of projects

Productization is a big topic. There is a lot of investment and risks. There is no boss, and no one wants to do anything.
In solution 1, "technically" means that even technical personnel can take the lead. You don't have to ask the boss, "Do we want to productize ". The specific method is to extract reusable parts from the project for reusable components.
Many people think that "we can talk about reusing products, but it is difficult to do projects because each project is different. In product development, because all functions are only performed once, it is difficult to reuse them at a high level. Instead, it is a project, it is possible that many similar and even the same functions are implemented in multiple customers, so we should reuse them.

If a project is only sold once by a customer ...... To be honest, the company is facing danger, and it is not easy to save it.
Reuse can be divided into multiple layers. In order to make things more dynamic, the reuse layers in Mars are roughly described here.

1.1 purely technical level, about 1000 lines of code
1.1.1mfcui (Martian Foundation Class UI) is used to process common web images, links, image links, Ajax calls, pop-up menus, and other content.
1.1.2mfcrepository/mfccaches. After adding any table, you only need one line of code to process the addition, deletion, modification, query, and table-level cache of the database table. The cache is automatically synchronized with the database.
1.1.3 ......
1.2 quasi-business model level, about 3000 lines of code
1.2.1items database, used to process any data that exists at the parent-child association level (product line-product-version-release, company-department-team-group, subsystem-module-business data-business operations-enhancement, any directory ...... It is the underlying layer, and there are about 10 types of tree data)
The 1.2.2udc Library (user defined column) can add custom fields for any item without writing any code (about 10 data types, their respective display and editing interfaces are also preset ).
1.2.3 ......
1.3 At the general business level, about 3000 lines of code (details in solution 2)
1.3.1mfc, used to process users, roles, permissions, Assignment Tasks, workload, calendar, team, personal center, notifications ...... Functions required by any product.
1.3.2dlc range (downloadrable content can be downloaded), processing plug-in class content.
1.3.3 ......
1.4 dedicated business level, about 1000 rows
1.4.1 process user stories, iterations, tables, and products. Only agile development is available.

In actual statistics, 89% of the entire martian code is within the reusable library range, and the rest is the code that can only be used in the "Agile development management tool" we see.
The benefits of doing so are also obvious, although so many libraries are "reused" only in the "1000" line of business code, however, the code efficiency of Martian users is about three times that of the industry (Note: each function point in the industry corresponds to 50 ~ 75 lines of C # code, less than 20 lines of Mars), production efficiency is about 2 ~ 3 times (Note: it takes about 400 person-days to produce 500 feature points in the industry, and fewer than 200 Martian users ). As the business grows and the number of reuse times increases in the future, this gap will continue to expand.
Therefore, if it is a project with a person-year level or above, regardless of whether it is "productization", it will only generate huge benefits if it is reused.
You can quickly build the next project without having to start from scratch. You can think of it as an "unofficial product ".
In essence, this solution is risky and balanced, because the "Reusable" library costs much higher than the one-time code, so I have a habit: the code used for the first time can only be encapsulated at the function level. It can be used "cleanly" for the first time. We will never consider whether future parameters will be diversified or whether methods will be added; the second time later.

Solution 2: extract semi-finished products

Even if the customer takes the lead, it will find that although the main business of each project is different, some functions can still be encapsulated in a large and complete manner, for example, the 1.3 General Business Layer mentioned above is:

1.3 General business level, including model and interface, about 3000 lines of code (details in solution 2)
1.3.1mfc, used to process users, roles, permissions, Assignment Tasks, workload, calendar, team, personal center, notifications ...... Functions required by any product.
1.3.2dlc range (downloadrable content can be downloaded), processing plug-in class content.
1.3.3 ......

If you delete the 1000 lines of code from the agile development in the Martian, a user can still log on to, join a department or team, view his/her workspace, and assign tasks (although there are no tasks that can be divided, is a general prototype.
In fact, this is no longer a new technology in the gaming industry. Most large game companies have found logon, figures, stores, sales, gangs, costumes, etc. in the game industry ...... Such systems are similar, so we have started to build our own semi-finished products. One of these companies is doing so well that some players have criticized several of them for "seemingly similar" games ".
Another company is also building their semi-finished games to shorten the development cycle of new games and enable them to develop core gameplay as soon as they come up, rather than starting from scratch.

Analysis: Re-talk about resonance (1)

Many programmers dream that one day the boss will give a speech, and they will not sell things for two years. They will develop their desired products. Two years later, they will be shocked by the fact that a product company is invincible. Unfortunately, the boss has no eyes, so you see, I am still here to answer the customer's call to change the code ......
Reusable libraries and productization are two layers of thinking. If a person does not accumulate reusable things at ordinary times, but is clamoring for productization every day, it is a daydream.
Therefore, we should make preparations for productization within the scope of our own control. If there are sufficient preparations, the boss found that three months later, instead of two years, he was able to build a product he had dreamed of, and he was able to make up his mind.

The technical methods mentioned in this Article can alleviate changes to some extent, but the business methods mentioned in the next article are far behind.