A platform for organizing the production of information systems. Part 2

Short description

Organizing IT product production processes as IT services that interact with the platform can bring benefits, according to an article on Medium. It recommends breaking down the process into iterations, each containing specific activities that are repeated periodically. An organisation should consider the different phases of each iteration: planning, execution, verification and analysis. Tasks should be organised using a status model of possible state transitions unique for each type. However, the article warned that it is easier to stop an iteration than finish it and offered guidance on selecting the most effective approach to suit an individual organisation.

A platform for organizing the production of information systems. Part 2

In the first part of the article, see In Part 1, we discussed the benefits of organizing IT product production processes as IT services that interact with the platform.

Considered the possible structure of the first important service: “Accounting of IT Product Requirements”. It was determined that its result should be a complex structure of the description of Requirements for the target Information System (hereinafter IS), maximally adapted to the organization on the basis of activities related to their implementation.

The next step within the framework of the platform is to transfer the set of requirements to the service “IT Product Production Organization”where they should be embodied in the functionality of the finished IT product.

IV Organization of IT Product production

So, on the basis of the organization of implementation works product we have adopted the concept of recycling Demand into the final functionality that can be identified and measured in the target IT product.

1. Service for recording work in the IT Product

Since the most common approach to the development of IT products is iterative, we will organize our work in the form of a set of specific activities that are repeated periodically. It is accepted to carry out iteration in four phases: 1) Planning – 2) Execution – 3) Verification (fixation of deviations) – 4) Analysis (correction).

But let’s take a step back, since we neglected the moment of organizing the work of the stage of the formation of the Requirement itself, because they are also a process of manufacturing an IT product. This is not an entirely isolated stage, because during the work in the iteration that implements the requirements, they may need to be changed, supplemented or completely replaced by others. And with the Agile approach, it is recommended to generate most of the requirements already at the implementation stage.

It is clear that, for example, the task of creating requirements differs in its parameters from the tasks of their implementation. At least it is related to the requirement. As a result, there can be many different tasks for one Requirement. For example, creating, changing, and even implementing, testing, including in the assembly, etc. see Fig. 4.

Figure 4. Organization of Tasks

Tasks of production activity of other types (implementation, testing and others) can be organized in the same way. Based on this, most Tasks are characterized by generalized (generalized) properties (date of creation, planned execution time, etc.), but each unique type can have its own extended set of properties. For example: development tasks can refer to an IT product component or build version, and more see Fig. 4.

Although tasks often do not have a branched hierarchical structure, they require logical connection. For example, the task of creating functionality in the target product should be detailed with the tasks of implementing the software code, testing the obtained result, including it in the assembly, etc.

2. Organization of works using the iterative method

But let’s return again to the organization of work on the production of an IT product in the form of an iterative approach. It is obvious that it is necessary to take into account the Iterations themselves in the system and organize the works already in their section.

It is important to note that part of the work can be performed outside of the iterative paradigm, for example: pre-project inspection, work at the design stage, activity of the implementation of the finished product, and others. The iterative approach, in this case, ensures the organization of work on the implementation of the design solution on the target system, step by step, dividing them into components, parts available for inspection (Iterations), see Fig. 5.

Figure 5. Organization of Iterations

This allows during the execution of each iteration to ensure the increase of only a part of the built-in capabilities of the system, selected from the total volume, and makes it possible to gradually, step by step, analyze both the IT Product being created and the process of its production, making adjustments and buying deviations.

In fact, at the same time, the relevant (current) Iteration, at the stage of its planning, is added by the Task, the implementation of the Requirement (opportunity). Further, each of them is laid out, creating subordinate tasks already from their technical implementation. Separately, it is possible to include in the Iteration tasks not related to the Requirements, for example, to solve technical and infrastructure problems, see Fig. 6.

Figure 6. Accounting for the completion of tasks

The next aspect. According to most methodologies, Iterations must be completed in a strictly allotted time. Most often, a fixed period of execution is followed, for example, 2 weeks, 4 weeks, etc. But this approach often causes many problems during planning. How to determine the time it will take to implement not just a private task, but also their totality in the form Opportunities (functionality) associated with the requirement? Or, having entered, on the other hand, how many requirements to take on Iteration, so as not to delay their implementation or not to be idle, quickly solving all the tasks?

For example, the Scrum framework recommends organizing work in limited iteration (Sprint) terms and finishing it regardless of whether everything has been done or not. And the Kanban methodology involves the execution of all tasks taken for iteration, regardless of how much they deviated from the initial plan-schedule.

When using the first approach, there is often confusion in the scope of the obtained result (functionality) and its constant fragmentation between iterations, which significantly reduces the quality of the analysis and the possibility of adjustment. And in the second case, work on the implementation of requirements is delayed, which is facilitated by the lack of a rigid framework. Second, it is easier to stop an iteration than to just finish it.

For a better understanding of which way to go, let’s look at the essence of the approaches. Their differences are dictated by the method of work organization: Scrum – pushes, and Kanban – pulls. That is, in the first case, the execution of one work initiates the beginning of the next, and in the second case, one high-level work requires the creation and execution of a chain of smaller, detailed works. The second approach is obviously the most suitable for our proposed variant of forming activities in Iteration – on the basis of Requirement-opportunity. But this will not mean that we should recklessly follow all the nuances of the methodology, we still build our process using best practices.

If we abandon the strict observance of the Iteration deadlines in order to guarantee the implementation of the Requirements-capabilities of the target system, then we must solve the question: how to deal with the problem of delaying the deadlines? This pain is more likely to be resolved through management than through an IT service capability.

The Iterations themselves should be taken into account in the context of the Project for the creation of the target IT product.

The project in this case combines all activities related to obtaining a specific result in a given period. It can be an IT product, individual modules of the Information System, MVP, an integrated solution, and others. The project most often has its own Customer.

Based on this concept, tasks that do not require implementation in the paradigm of an iterative approach can be combined into separate Iterations (in one repetition), dedicated to the implementation of a certain stage of the production stage. For example, “pre-design survey”, “design”, etc. This will unify the general scheme of work.

3. Support of the life cycle of the Task in the process of its implementation

Each task is characterized by a set of stable states determined by the model of the LV, organized differently for each type. For example, a Task-opportunity (on demand), when all subordinate development tasks are completed, should move to the testing phase. This is achieved by configuring the status model of possible state transitions unique for each type of task.

So, when a new task is created, it is given the status “Created”. At the moment of accepting the task to work as an executor, its status changes, for example, to “At Work”. According to the current status, it is possible to determine the stage of the residential complex, see Fig. 7. and manage execution.

Figure 7. Status model Tasks for development and testing

When performing activities on the Task, each executor forms a report indicating the time of execution and a description of the process, see Fig. 4. When a task is fully implemented, its status changes according to the status model, for example, to “Completed”.

As mentioned above, if all the tasks for the implementation of the requirement have moved to the “Completed” status, then the Task-opportunity that unites them (related to the Requirement) moves to the “Testing” status. This event signals to the QA specialist that he should take the “Into Work” related task to test the realized capability. This signal can be generated without the use of visual boards (Kanban or Scrum), ensuring a seamless process of organizing production.

As a result of the work of quality engineers, new tasks can be created to correct errors and deviations from requirements. Sometimes, there may be tasks for the finalization of the Requirements regarding the capabilities realized in the product, which are different from the requirements, but complementary.

When the entire set of works is implemented according to the task-opportunity, the requirement-the basis of the task itself can be considered implemented. And therefore, in the service “Taking into account the requirements for the IT Product“, it is necessary to send a signal about the promotion of the related Requirement for the residential complex and change its status to – “Implemented”.

The entire mechanism of providing the Zavdany residential complex involves one more service.

Since each iteration must end with an analysis stage, the results must be recorded in the form of facts of positive and negative trends in the IT product itself and the process of performing work in the Iteration. On the basis of these facts, tasks for the next Iteration should be set for the organization of work to consolidate positive trends and level negative ones.

The result of the Iteration should (ideally) be the Compilation of an IT product with limited capabilities, see Fig. 8.

Figure 8. Iteration results

4. Support of the Requirements life cycle in its implementation

Thus, a production conveyor is formed.

Formed in the service “Accounting of IT Product Requirements” The request in the form of a context was transferred to development, to the service “IT Product Production Organization”. There, work was organized on its implementation and quality assurance, with feedback on the stage of passing through its residential complex.

5. Development of the platform

For those who are used to working in the classic project paradigm, a service representing a set of requirements with the type: “Product”, “Component”, “Opportunity” can be used in the form of Gantt chart works, which also displays the fixation of their implementation, see .

Figure 9. Requirements implementation planning on the Gantt chart

The set of services can be expanded. Each service that is not suitable for a specific team can be replaced with the most complementary one.

The model for organizing the interaction of the services themselves is a separate topic and is not discussed within the framework of this article.

Related posts