Management of the company-developer: you need it?
At the Gaidar Forum, German Gref said that Sberbank will switch to new information technologies, choosing a Russian-American company with 60 people as its main partner. At the same time, Sberbank spent 65 billion rubles. on an ambitious and complex project to centralize the IT structure, and today it has more than 22,000 IT employees, including 6,000 people in Sbertech. The main reason for the transition is the rate of change in IT, which was low and led to the lag of Sberbank's IT from the leaders in the development and flexibility of the IT infrastructure. And how important is the speed of making changes in the design? What should I look for in managing the development process? Should I use models and methodologies? Let's try to figure it out.
When you develop your automated control system (ACS) you encounter some issues from two sides. For example, on the one hand, you manage the development process yourself, and on the other, you adapt your XRM (for example, Ruli24 ) for companies that want to use it as a management tool for their development (development companies, development partners). Besides the fact that the system takes into account time resources and task planning, you need to properly evaluate the environment with which you have to work.
')
In the simplified scheme of the company's IT infrastructure, all elements are separated. However, we all know perfectly well that in real life a “clean profile” is rare and there is no clear separation of functional responsibilities. Actually, there is nothing bad in it, moreover, DevOps has recently gained popularity, an approach that implies a “hybrid” of a developer and an administrator, and rapid deployment and testing of releases. It is precisely because of such functional intersections that development management comes to the fore.
Before proceeding to the models, methods and techniques, let us designate the development cycle to be managed. There are a lot of approaches to the cycle, we turn to the standard GOST 34.601-90.
It was not by chance that we touched on this topic - in our company ILADA there is a need to change the development management model due to business growth and the dynamic requirements of our customers. The experts of our team carefully analyzed various models and methodologies, weighed the pros and cons. Today we are ready to share with you the material, and at the same time listen to recommendations in the comments, based on your experience.
IT management and development management have always sought to find the optimal model. Models have evolved with technology and changes in the commercial component of the development. The speed of technology change, business development and ever-changing demand have influenced the models: from a hard cascading world, development has come to an iterative model and the so-called agile development. However, as in any science, previous experience was necessarily taken into account and the best practices of all models passed into more modern ones. We single out and briefly consider three main models.
Cascade development model (waterfall model): requirements definition, design, programming, testing, implementation, maintenance. The developer, following this model, consistently moves from one stage to another. It is obvious that, despite the rigor of the approach and the clear separation of the stages, this model is inflexible, takes a lot of labor and time resources. It seems that the cascade model in our time should have died out as unproductive, but it continues to live and be used, however, more and more in government and defense structures. For example, in projects of national importance in Germany, it is customary to use the V-model of development, which is based on the cascade one. This choice is not without logic: this model can be carefully monitored and can reduce the majority of management risks. However, the state rarely works in austerity mode and is not forced to optimize the process in any way — it has other tasks. Modern business chooses other models.
The iterative model of development involves the execution of work in parallel with the continuous analysis of the results and the adjustment of the previous stages. Here, the development process appears to us as a cycle: planning - development - testing - evaluation. This model looks attractive by reducing risks, working in project teams, evenly distributing the workload of development participants, continuous testing and refinement. Perhaps this is the most appropriate model for developing corporate software, since it involves the interaction with the user / customer, allows you to use the experience of the team and reduces the overhead of development costs. From a market point of view, a product created by an iterative model may be cheaper than a similar product created using a cascade model.
The spiral model , also suitable for commercial development, especially for complex projects, combined the advantages of prototyping (creating a minimally working prototype) and a cascade model. Moreover, at each turn, different development models can be applied, the main thing is that the customer should receive working software as quickly as possible. In fact, this is a development by iterations: without completing one stage, the developers proceed to the next one, which complements the results of work at the previous round. Due to the formation of a development plan and strict adherence to it, development is carried out fairly quickly. Such a model helps to overcome such management problems of a developer company as a shortage of manpower, disruptions in the development and delivery of software, and changes in customer requirements. Especially successfully, this model works on large projects, for example, on the implementation of complex expensive CRM and ERP, when in the process of finalizing and deploying the system from a client from the vendor’s side, resources are limited (the whole team cannot deal with one client), and from the customer’s side at any moment may have changed requirements.
Within each model, developers can apply various software development methodologies — the value systems of developers that underlie business processes and development management.
Modern companies are universal organizations that simultaneously develop the main product, create client versions, carry out refinement and implement implementation. Accordingly, following one selected model is very difficult. To determine which model fits your company, you need to conduct a small internal survey.
The answer to these questions forms the basis for making decisions about choosing a methodology. For example, large projects, including developments for the defense industry and industry, are likely to choose a cascade model, which allows in the most profound way to work out all aspects of the interaction of technologies in development, to separate areas of responsibility and carefully implement each stage. I think that large developers and vendors of large-scale corporate and user solutions also use a cascade or mixed model: operating systems (by the way, in the case of Microsoft, MSF is a combination of cascade and spiral models), CRM, ERP, xRM.
Iterative and spiral development models are perfect for custom solutions and implementation projects. Most likely, these same models will be chosen by startups, large sites and portals, social networks, that is, large-scale projects, which, however, are not replicated and not customized.
I can give you an example of our development of the Ruli24 system. For the development of versioned box solutions, our team uses a cascade model, for implementation projects and custom releases - iterative and spiral models. As for methodologies, we have not yet chosen the final version, however, we have built a development management system, similar in spirit to agile, based on Ruli24. Moreover, it was the work on the problem of development management that prompted us to create a process management module.
Obviously, the entire development cycle fits into a set of processes:
All actions are consecutive, one process is replaced by another, accompanied by standard workflow, it needs to control tasks, deadlines and planning. While we are talking about 10 clients and 5 projects, all problems are solved orally and by keeping records on a whiteboard. However, as projects grow, automation is needed, and such that all levels of processes and project management are linked.
In our work we used different management systems, but not a single solution allowed us to link together all the processes that operate within the company. Had to work simultaneously in multiple systems. So the understanding came that it is necessary to create your product - “Ruli24. Process Management . This decision combines all unregulated processes related to the activities of companies. And with the help of this product, you can manage both business processes and projects, manage customer service and customer relations and workflow. Like any developer of commercial software, we have chosen our product to simultaneously test it. Several implementations in IT companies have proven the correctness of our solution. Well, five seconds of bragging - the business community rated our decision and the team received the SOFTTOOL award as “Product of the Year”.
So, the model is chosen, now we need a methodology. Let's talk about them.
Recently, a flexible development management methodology, the so-called agile-methodology, has gained incredible popularity. Consider it in more detail and find out whether it is suitable for all.
The word agile, which came to English from French, means “clever, agile”. Perhaps no single word would better characterize this methodology. As I have already mentioned, agile does not include strict rules or practices, but determines the values ​​that guide the teams using this methodology. At first glance, the basic ideas of the agile methodology do not look quite realistic:
However, many teams using agile are extremely effective and successful. This methodology, in fact, greatly simplifies product development. I am sure that not least this is the merit of a specific approach to the formation of the development team and management of this team: in addition to the architect, programmers and designer, the team must include representatives of the customer (his staff or his project manager). Here are the reasons and expectations for the transition to agile, listed by respondents to the Techbeacon survey:
Increased cooperation between teams that usually do not work together - 54%
Increase software quality level - 52%
Customer satisfaction growth - 49%
Reducing the time to market for a product - 43%
Reducing the cost of development - 42%
In general, agile has many advantages, thanks to which he was able to win the love of not only the managers, but also the developers themselves.
From the point of view of business, agile is also profitable.
Of course, there is a negative experience with agile. It can occur in three main cases.
Scrum is a project management methodology used in agile. Scrum is designed to control the quality of the development process, and is also an approach to managing the development and maintenance of the project.
Scrum assumes short iterations with sprints of 15-30 days, during which the team is maximally focused on development and at the end of which the user receives working software with new features that were selected from the project backlog as priority ones. Tasks for the development of functionality can not change throughout the sprint, and time is strictly fixed and its shift is a signal that the team does not take into account any factors when planning. The shorter the sprint in scrum, the more flexible the development - choosing tasks from the backlog, the developers know that they are moving in the right direction and create exactly the software that the customer needs.
The main source of information about the necessary improvements and new functionality in scrum is the project's backlog, where all team members can collect any requirements. This list is ordered by the importance of each of the changes. Based on the time of the sprint and the experience of the team, the most priority tasks fall into the backlog of the sprint - what will be implemented in the next segment of development and divided into tasks for team members. Scrum-team includes an architect, designer, programmers, testers and customer representative. Before the sprint there is a 2-8 hour planning meeting for the sprint, during which motivated tasks of their backlog of the project are selected and the duration of the sprint is set. A large meeting on the results and at the end of the sprint. Every day, small, up to 15 minutes, rallies take place to assess the current state of affairs and the need to adjust actions. All this time a task combustion diagram is being built - a graph on which the amount of work done and the remaining work is marked. Most often, the scrum-team leads the board with stickers, where he moves tasks between stages.
Despite the seeming randomness, scrum is a highly disciplined approach to managing development, ensuring transparency of all tasks for the whole team and focused on results.
One option to scrum is lean development and kanban. They came to the development of the Japanese automotive industry, namely from the concern Toyota, which is widely known for its approach to lean manufacturing and successfully uses the Kanban card system to assemble cars without overstocking and reloading the shop.
Kanban, like scrum, is not a business process, not an action, but a developer’s value system, a methodology. In the kanban process, the team works on the task from the beginning to the end; there are no set deadlines for the task. In this methodology, it is important to be able to properly prioritize when performing tasks.
Unlike scrum, kanban eliminates the loss of waiting for decisions or the development of unnecessary functionality. Short development cycles, early testing, even distribution of workload in a team and a clear development system ensure transparency of the work and complete stability of the team. Today, this methodology is chosen by large development companies and even some banks.
Agile is a rather well thought out methodology in its own right, but it should not be taken as the only truth. Before turning to a particular methodology, just as in the case of models, it is important to determine which approach to the reduction will be most effective for your company. It may be worthwhile to develop according to the strict GOST standards of the USSR with careful design of the TZ and the creation of a technical project, or maybe it’s time to buy a board, stickers and introduce the team to Kanban.
Agile is convenient to use if you have:
This is not a complete list of conditions for a successful start of agile, but the most characteristic signs are listed. In general, you can apply various methodologies and combine them in one company: for example, you can develop the development according to a cascade model and GOST, and create scrum teams for implementation. The main thing is that such combinations should be aimed at maximum efficiency of work, speed of project implementation and high quality of development.
But still, the main thing that you should be guided by when choosing a methodology is accumulated experience and common sense. Fashion here is not the best adviser.
At the core of most software development lifecycle management is system engineering in terms of performance engineering software (performance engineering), designed to provide an approach and tools for creating viable programs. Whichever software development methodology is chosen, performance engineering (PE) is applied at least at one of the stages. Here is how various specialists evaluate the importance of performance engineering in applying to some aspects of development and methodologies:
PE is focused on non-functional requirements (how powerful the software should be, that is, how fast it should work in certain conditions). During the design phase, PE is focused on creating code that provides better performance. During testing, PE sets requirements for systems and studies performance on various configurations (load, type of operating system, interaction with various types of devices, etc.), the best of which will be used in production. After software implementation, performance engineering is responsible for three main areas:
Engineering productivity with the development of scientific and technological progress does not lose its value, but on the contrary, comes to the fore. Modern GUI capabilities, the use of databases with complex architecture, work with cloud technologies are challenging for performance, which PE must meet, at all stages of the product life cycle.
Take, for example, our system Ruli24. In configurations for medium and large businesses (for example, banks, industrial enterprises, telecom), this is a rather complex software. In addition, our system is running Oracle DBMS, powerful, but having the glory of "slow." We are carefully working on the performance and architecture of our software, seeking to provide the minimum response time for the current configuration. We succeed. And it's not about Oracle at all, it's about the ability to manage architecture and constant refactoring of code.
Beyond our small review, there are several development methodologies that, despite their specificity, continue to be used successfully in development companies. Let's go through the main ones.
Often, the leaders of development companies, even large ones, in response to a question about the development methodology, have their shoulders and either keep silent or tell something about the tools with which they work. Obviously, management may consider adherence to a particular methodology as a waste of time and bureaucratization of the process, but this is not the case. Working with the methodology, the company receives a number of advantages: an organized work, a team that shares values, the experience of the best practices of those who have already implemented this or that methodology.
In fact, each software company already adheres to a specific model and methodology: from a rigorous and lengthy cascade to extreme programming. Things are easy: set rules for yourself and learn from the best that development management practices use. Try it - you will like it.
Surrounded
When you develop your automated control system (ACS) you encounter some issues from two sides. For example, on the one hand, you manage the development process yourself, and on the other, you adapt your XRM (for example, Ruli24 ) for companies that want to use it as a management tool for their development (development companies, development partners). Besides the fact that the system takes into account time resources and task planning, you need to properly evaluate the environment with which you have to work.
')
In the simplified scheme of the company's IT infrastructure, all elements are separated. However, we all know perfectly well that in real life a “clean profile” is rare and there is no clear separation of functional responsibilities. Actually, there is nothing bad in it, moreover, DevOps has recently gained popularity, an approach that implies a “hybrid” of a developer and an administrator, and rapid deployment and testing of releases. It is precisely because of such functional intersections that development management comes to the fore.
Before proceeding to the models, methods and techniques, let us designate the development cycle to be managed. There are a lot of approaches to the cycle, we turn to the standard GOST 34.601-90.
It was not by chance that we touched on this topic - in our company ILADA there is a need to change the development management model due to business growth and the dynamic requirements of our customers. The experts of our team carefully analyzed various models and methodologies, weighed the pros and cons. Today we are ready to share with you the material, and at the same time listen to recommendations in the comments, based on your experience.
Development Models - Three Whale Management
IT management and development management have always sought to find the optimal model. Models have evolved with technology and changes in the commercial component of the development. The speed of technology change, business development and ever-changing demand have influenced the models: from a hard cascading world, development has come to an iterative model and the so-called agile development. However, as in any science, previous experience was necessarily taken into account and the best practices of all models passed into more modern ones. We single out and briefly consider three main models.
Cascade development model (waterfall model): requirements definition, design, programming, testing, implementation, maintenance. The developer, following this model, consistently moves from one stage to another. It is obvious that, despite the rigor of the approach and the clear separation of the stages, this model is inflexible, takes a lot of labor and time resources. It seems that the cascade model in our time should have died out as unproductive, but it continues to live and be used, however, more and more in government and defense structures. For example, in projects of national importance in Germany, it is customary to use the V-model of development, which is based on the cascade one. This choice is not without logic: this model can be carefully monitored and can reduce the majority of management risks. However, the state rarely works in austerity mode and is not forced to optimize the process in any way — it has other tasks. Modern business chooses other models.
The iterative model of development involves the execution of work in parallel with the continuous analysis of the results and the adjustment of the previous stages. Here, the development process appears to us as a cycle: planning - development - testing - evaluation. This model looks attractive by reducing risks, working in project teams, evenly distributing the workload of development participants, continuous testing and refinement. Perhaps this is the most appropriate model for developing corporate software, since it involves the interaction with the user / customer, allows you to use the experience of the team and reduces the overhead of development costs. From a market point of view, a product created by an iterative model may be cheaper than a similar product created using a cascade model.
The spiral model , also suitable for commercial development, especially for complex projects, combined the advantages of prototyping (creating a minimally working prototype) and a cascade model. Moreover, at each turn, different development models can be applied, the main thing is that the customer should receive working software as quickly as possible. In fact, this is a development by iterations: without completing one stage, the developers proceed to the next one, which complements the results of work at the previous round. Due to the formation of a development plan and strict adherence to it, development is carried out fairly quickly. Such a model helps to overcome such management problems of a developer company as a shortage of manpower, disruptions in the development and delivery of software, and changes in customer requirements. Especially successfully, this model works on large projects, for example, on the implementation of complex expensive CRM and ERP, when in the process of finalizing and deploying the system from a client from the vendor’s side, resources are limited (the whole team cannot deal with one client), and from the customer’s side at any moment may have changed requirements.
Within each model, developers can apply various software development methodologies — the value systems of developers that underlie business processes and development management.
How to choose a development model?
Modern companies are universal organizations that simultaneously develop the main product, create client versions, carry out refinement and implement implementation. Accordingly, following one selected model is very difficult. To determine which model fits your company, you need to conduct a small internal survey.
- Who does the company position itself as a developer of large custom projects, a vendor (manufacturer) of lottery software, a unique solution developer, a SaaS solution developer or a small project developer? Or maybe she is engaged in software implementation projects?
- How long do these projects last: month, quarter, year, three years or decades?
- What is the composition of the team? What is the qualification?
- Who is the customer? Are typical clients ready to work on the developer’s side and interact at all stages or are they passive observers who have agreed on a technical task and are waiting for a result?
The answer to these questions forms the basis for making decisions about choosing a methodology. For example, large projects, including developments for the defense industry and industry, are likely to choose a cascade model, which allows in the most profound way to work out all aspects of the interaction of technologies in development, to separate areas of responsibility and carefully implement each stage. I think that large developers and vendors of large-scale corporate and user solutions also use a cascade or mixed model: operating systems (by the way, in the case of Microsoft, MSF is a combination of cascade and spiral models), CRM, ERP, xRM.
Iterative and spiral development models are perfect for custom solutions and implementation projects. Most likely, these same models will be chosen by startups, large sites and portals, social networks, that is, large-scale projects, which, however, are not replicated and not customized.
I can give you an example of our development of the Ruli24 system. For the development of versioned box solutions, our team uses a cascade model, for implementation projects and custom releases - iterative and spiral models. As for methodologies, we have not yet chosen the final version, however, we have built a development management system, similar in spirit to agile, based on Ruli24. Moreover, it was the work on the problem of development management that prompted us to create a process management module.
How did it happen?
Obviously, the entire development cycle fits into a set of processes:
- The research process, during which the requirements are collected, the terms of reference is drawn up.
- The process of creating a project, the result of which is the creation of a prototype first, and then a complete working software, ready for deployment on the client side. This process also includes software verification.
- Project support process. This is nothing more than service support, HelpDesk, which processes user requests according to established service level regulations. Requests must be sorted, accumulated, processed, on the basis of which a knowledge base is formed.
- Conducting forums and meetings related to the development of some new products, research, and what is happening inside the company on current activities.
- Development of new versions of software is a standard business process of a company-developer, it includes the usual steps: the project of creating a version, testing a version, delivering a version to a customer.
All actions are consecutive, one process is replaced by another, accompanied by standard workflow, it needs to control tasks, deadlines and planning. While we are talking about 10 clients and 5 projects, all problems are solved orally and by keeping records on a whiteboard. However, as projects grow, automation is needed, and such that all levels of processes and project management are linked.
In our work we used different management systems, but not a single solution allowed us to link together all the processes that operate within the company. Had to work simultaneously in multiple systems. So the understanding came that it is necessary to create your product - “Ruli24. Process Management . This decision combines all unregulated processes related to the activities of companies. And with the help of this product, you can manage both business processes and projects, manage customer service and customer relations and workflow. Like any developer of commercial software, we have chosen our product to simultaneously test it. Several implementations in IT companies have proven the correctness of our solution. Well, five seconds of bragging - the business community rated our decision and the team received the SOFTTOOL award as “Product of the Year”.
So, the model is chosen, now we need a methodology. Let's talk about them.
Clever methodology
Recently, a flexible development management methodology, the so-called agile-methodology, has gained incredible popularity. Consider it in more detail and find out whether it is suitable for all.
The word agile, which came to English from French, means “clever, agile”. Perhaps no single word would better characterize this methodology. As I have already mentioned, agile does not include strict rules or practices, but determines the values ​​that guide the teams using this methodology. At first glance, the basic ideas of the agile methodology do not look quite realistic:
- people and interaction are more important than processes and tools - it seems that such an approach will lead to the team's disunity, unwillingness to be responsible for the result of the work;
- a working product is more important than comprehensive documentation - it is difficult to imagine a complex information system, production software or, for example, a text editor without detailed supporting documentation;
- cooperation with the customer is more important than agreeing the terms of the contract - for Russian realities this item looks scary: every developer is afraid of continuous changes in requirements on the part of the customer;
- willingness to change is more important than following the original plan - you will agree, it is difficult to develop without a roadmap.
However, many teams using agile are extremely effective and successful. This methodology, in fact, greatly simplifies product development. I am sure that not least this is the merit of a specific approach to the formation of the development team and management of this team: in addition to the architect, programmers and designer, the team must include representatives of the customer (his staff or his project manager). Here are the reasons and expectations for the transition to agile, listed by respondents to the Techbeacon survey:
Increased cooperation between teams that usually do not work together - 54%
Increase software quality level - 52%
Customer satisfaction growth - 49%
Reducing the time to market for a product - 43%
Reducing the cost of development - 42%
In general, agile has many advantages, thanks to which he was able to win the love of not only the managers, but also the developers themselves.
- Agile-approach allows you to have always relevant product that meets the requirements of the customer, because the methodology involves the principle of responding to changing customer requirements. On the one hand, the product corresponds to the time, on the other - the customer always gets exactly what he wants, which means that he has less reason to turn to the competitor’s team.
- Frequent software delivery due to short sprints provides the team with the opportunity to quickly analyze the project's backlog and implement the highest priority tasks.
- Close cooperation with the customer at all stages of the project helps to correctly interpret the terms of reference and, in combination with short sprints, does not allow to deviate from the requirements and create functionality unclaimed by the client.
- Attention to the technologies used and usability significantly affects the quality of the developed product. The project is constantly adapting to new trends and user requests.
- Self-organization of teams, face-to-face communication has a good effect on the performance of each of the team members. As the study showed, agile does not take root only in 15% of the teams that chose it.
From the point of view of business, agile is also profitable.
- It allows you to accelerate the entry of the product into the market and constantly comply with the requirements of the market
- A product created using agile methodology creates the impression of being extremely loyal to users. for example, you can collect user feedback and put them in the sprint, constantly reporting on changes. Willingness to change significantly increases the credibility of the project.
- Agile helps align IT (development and maintenance) with business goals.
- Despite the apparent democracy, the methodology improves the overall performance of the company.
Of course, there is a negative experience with agile. It can occur in three main cases.
- The customer goes too far, changes the requirements without good reason, and the team turns into a machine for continuous, emergency refactoring. The manager of the entire project (scrum-master) is obliged to communicate with the client and explain that the requirements must be reasonable and consistent with the objectives of the business. Leapfrogging in development and a constant change in the direction of product development does not lead to good.
- The team cannot organize itself and turns agile into licentiousness and idle chatter at meetings. Indeed, up to 30% of the sprint time goes to meetings and meetings (before the sprint, a 4-8 hour meeting, after and every day, no more than 15 minutes). It is necessary to convey to the team that these meetings are an important part of the work on the project and their task is not the exchange of gossip and jokes, but a discussion of the problems, tasks and time of the project. After all, customer satisfaction, company income and the personal income of each employee are at stake.
- Reducing the quality of the product due to the negligent attitude to the development technologies and features of the IT infrastructure. Indeed, it so happens that the team, fascinated by usability or design, completely forgets about performance, refactoring and testing on different builds. This is where performance management comes to the rescue, which should also become a business process. I will tell about it a little lower.
Scrum - the developers' crush
Scrum is a project management methodology used in agile. Scrum is designed to control the quality of the development process, and is also an approach to managing the development and maintenance of the project.
Scrum assumes short iterations with sprints of 15-30 days, during which the team is maximally focused on development and at the end of which the user receives working software with new features that were selected from the project backlog as priority ones. Tasks for the development of functionality can not change throughout the sprint, and time is strictly fixed and its shift is a signal that the team does not take into account any factors when planning. The shorter the sprint in scrum, the more flexible the development - choosing tasks from the backlog, the developers know that they are moving in the right direction and create exactly the software that the customer needs.
The main source of information about the necessary improvements and new functionality in scrum is the project's backlog, where all team members can collect any requirements. This list is ordered by the importance of each of the changes. Based on the time of the sprint and the experience of the team, the most priority tasks fall into the backlog of the sprint - what will be implemented in the next segment of development and divided into tasks for team members. Scrum-team includes an architect, designer, programmers, testers and customer representative. Before the sprint there is a 2-8 hour planning meeting for the sprint, during which motivated tasks of their backlog of the project are selected and the duration of the sprint is set. A large meeting on the results and at the end of the sprint. Every day, small, up to 15 minutes, rallies take place to assess the current state of affairs and the need to adjust actions. All this time a task combustion diagram is being built - a graph on which the amount of work done and the remaining work is marked. Most often, the scrum-team leads the board with stickers, where he moves tasks between stages.
Despite the seeming randomness, scrum is a highly disciplined approach to managing development, ensuring transparency of all tasks for the whole team and focused on results.
Lean / Canban - scrum, which comprehended Zen
One option to scrum is lean development and kanban. They came to the development of the Japanese automotive industry, namely from the concern Toyota, which is widely known for its approach to lean manufacturing and successfully uses the Kanban card system to assemble cars without overstocking and reloading the shop.
Kanban, like scrum, is not a business process, not an action, but a developer’s value system, a methodology. In the kanban process, the team works on the task from the beginning to the end; there are no set deadlines for the task. In this methodology, it is important to be able to properly prioritize when performing tasks.
Unlike scrum, kanban eliminates the loss of waiting for decisions or the development of unnecessary functionality. Short development cycles, early testing, even distribution of workload in a team and a clear development system ensure transparency of the work and complete stability of the team. Today, this methodology is chosen by large development companies and even some banks.
Is agile right for you?
Agile is a rather well thought out methodology in its own right, but it should not be taken as the only truth. Before turning to a particular methodology, just as in the case of models, it is important to determine which approach to the reduction will be most effective for your company. It may be worthwhile to develop according to the strict GOST standards of the USSR with careful design of the TZ and the creation of a technical project, or maybe it’s time to buy a board, stickers and introduce the team to Kanban.
Agile is convenient to use if you have:
- Project requirements are not clearly defined or are constantly changing at the request of the client or as a result of competitive intelligence.
- The characteristics of the future product are subject to high volatility.
- There is no time for the preparation of formal project documentation, you have to work "on the fly".
- The contractor and the customer have an increased tolerance for risk.
- You have the opportunity to create a cohesive and effective team to manage the development.
- Your product beats easily into modules that agile teams can handle.
This is not a complete list of conditions for a successful start of agile, but the most characteristic signs are listed. In general, you can apply various methodologies and combine them in one company: for example, you can develop the development according to a cascade model and GOST, and create scrum teams for implementation. The main thing is that such combinations should be aimed at maximum efficiency of work, speed of project implementation and high quality of development.
But still, the main thing that you should be guided by when choosing a methodology is accumulated experience and common sense. Fashion here is not the best adviser.
The promised moral teaching about performance
At the core of most software development lifecycle management is system engineering in terms of performance engineering software (performance engineering), designed to provide an approach and tools for creating viable programs. Whichever software development methodology is chosen, performance engineering (PE) is applied at least at one of the stages. Here is how various specialists evaluate the importance of performance engineering in applying to some aspects of development and methodologies:
PE is focused on non-functional requirements (how powerful the software should be, that is, how fast it should work in certain conditions). During the design phase, PE is focused on creating code that provides better performance. During testing, PE sets requirements for systems and studies performance on various configurations (load, type of operating system, interaction with various types of devices, etc.), the best of which will be used in production. After software implementation, performance engineering is responsible for three main areas:
- service level management (SLA) - determining software compliance with requirements, monitoring and analyzing system performance;
- , — , , , , ;
- — . , , , , .
Engineering productivity with the development of scientific and technological progress does not lose its value, but on the contrary, comes to the fore. Modern GUI capabilities, the use of databases with complex architecture, work with cloud technologies are challenging for performance, which PE must meet, at all stages of the product life cycle.
Take, for example, our system Ruli24. In configurations for medium and large businesses (for example, banks, industrial enterprises, telecom), this is a rather complex software. In addition, our system is running Oracle DBMS, powerful, but having the glory of "slow." We are carefully working on the performance and architecture of our software, seeking to provide the minimum response time for the current configuration. We succeed. And it's not about Oracle at all, it's about the ability to manage architecture and constant refactoring of code.
And a few more methodologies
Beyond our small review, there are several development methodologies that, despite their specificity, continue to be used successfully in development companies. Let's go through the main ones.
- TDD ( ) — , , , , . , , , ( ), , , . TDD — , , , .
- DSDM (Dynamic Systems Development Method , ) — , RAD ( ) . , , , , .
- RUP (Rational Unified Process) — , 2-6 , . : , , ; ; , ; , .
- RAD (rapid application development, ) — , . 3-5 , . . , . RAD- ( ) , , , , GUI, .
- Cleanroom Software Engineering ( « ») — . , , . , .
- MSF (Microsoft Solutions Framework) — , Microsoft. , , . , , . MSF , , : , , . , , -. MSF () , .
Often, the leaders of development companies, even large ones, in response to a question about the development methodology, have their shoulders and either keep silent or tell something about the tools with which they work. Obviously, management may consider adherence to a particular methodology as a waste of time and bureaucratization of the process, but this is not the case. Working with the methodology, the company receives a number of advantages: an organized work, a team that shares values, the experience of the best practices of those who have already implemented this or that methodology.
In fact, each software company already adheres to a specific model and methodology: from a rigorous and lengthy cascade to extreme programming. Things are easy: set rules for yourself and learn from the best that development management practices use. Try it - you will like it.
We are looking for partnersWe are not greedy and ready to share our experience in developing and managing it. We have something to tell and have something to share. We are still open to partners who want to sell, or better yet, refine our Ruli24 system . Who cares - we have already written about the platform in our blog.
Who are we looking forward to working with?
- With those who will lead implementation projects in the regions.
- With integrators.
- , Ruli24 .
- -, .
, . !
Source: https://habr.com/ru/post/274947/
All Articles