Цепков Максим Александрович
IT-архитектор, бизнес-аналитик, эксперт и навигатор по миру Agile и бирюзовых организаций. Проектированием корпоративных и банковских систем занимаюсь 20+ лет, а всего IT 30+. Я убежден, что автоматизация открывает новые возможности для развития, а создавая IТ-системы, мы открываем путь прогрессу и делаем мир лучше. Работа в больших проектах позволяет сравнивать классический и гибкий подходы. Я знаком с Agile с 2008 года и вижу, что это - способ менеджмента будущего. Я активно участвую в профессиональном IT-сообществе, веду блог на своем сайте http://mtsepkov.org/, вхожу в программные комитеты конференций SECR и Analyst Days, открыт к общению с коллегами на различных площадках и в соцсетях.
How to create vision of future and your way to it - schemes for self-determination
The modern world assumes that a person is looking for an image of his future and way to it. Standard career ladders are not relevant, the technology renovation demand to change specializations and learning. Unlike in the past, a job becomes not just a source of money, but also a professional activity that provides drive, self-realization, energy and happiness. A person himself must be active, serve as a driver of his own changes and make a choice, and not give control of his life to others: then you will get happiness and drive only with luck.
The talk includes approaches and schemes that allow technologically solving the problems of building an image of the future and its own trajectory. Previous versions of the report "How to build your professional path" https://mtsepkov.org/SelfDet2 focused on building a path to the image of the future, this one is expanded with approaches to building such an image of the future, which will give meaning to life, drive, self-realization and energy.
Q&A: session with experts
Our experts Maksim Tsepkov, Grigory Pechenkin, Alexander Baikin and Dmitry Bezugly will answer your questions.
Design practice in different development cultures, technologies and paradigms
There were several cultures of developing software projects. Each of them generate not only its own methods of project management but also its own ways of maintaining requirements and designing software. Programming paradigms changed: OOP came to replace the procedural approach, DDD appeared, and later the focus shifted to interfaces, usability and UX.
The architecture of the application also changed: first, they switched from client-server to three-tier, then the desktop client was replaced by the web with the concepts of MVC, MVVM and many others, then mobile applications appeared, reactive programming approaches appear, the application consists of many services, and the user switches between devices. All this required new approaches to design, new books appeared on the implementation of new concepts, while the old ones remained relevant.
The talk will be devoted to the logic of the development of methods and actual modern design problems that has no books and courses yet.
Test design in a service architecture. Case study
At last SQA Days, I told about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-SQA). This model allows you to design scenarios for checking asynchronously communicating services, including checking complex cases to ensure application resilience under various failures.
The talk will continue with a workshop in which the model's application will be explored using specific cases from the participants. Those whose cases are reviewed will get solution ideas, while others will see the model's practice, evaluate it and think about applying it to their work.
Design an application in microservice architecture. Case study
At last Analyst Days, I talked about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-AD). Such a model is consistent with the code and allows you to design changes as the application evolves and measures them against the complexity of the model's changes.
The talk will continue with a workshop in which the model's application will be explored through specific cases of the participants. Those whose cases are taken apart will receive ideas for solutions, while others will see the practice of working with the model, evaluating it, and thinking about applying it in their own work.
Application models for different programming paradigms
For a long time, most applications were developed as large monoliths or systems of large modules, in which the processing of user requests could be represented as a procedure. And for testing, it was enough to check the application response for the user and the changes in the database. Based on this model, you can write test cases or checklists.
Today we see in use microservice architecture or the actor model with asynchronic messages, that can be lost during transmission or double operated and produce various complex effects. In this case, the classic application model is no longer sufficient for developing application testing - it does not provide an idea of the problems that arise. Other models are needed that are adequate to the applied programming paradigms, based on which it is possible to develop scripts for checking complex cases that ensure the stable operation of the application in complex situations. Such models will be discussed in my talk.
Domain models for various programming paradigms
During a long time, the main development approach was OOP. In this case, the construction of the object model of the subject area in the form of structures of references and documents and business logic in each object is a suitable design method for the analyst, and the developer easily transfer it to the code and the developer can change the model during realization if choose different way. Therefore, the model reflects the code, and complexity of model changes due to new requirements allow to evaluate the cost of development. However, other paradigms for the implementation of high-load applications, such as microservice architecture or the actor model, are becoming quite popular. In this case, analysts need different methods to describe the requirements and domain model, that they are adequate to the programming paradigms. I talk about some of them in my speech.
How long does the tech spec remain?
On the one hand, the Requirements Specification cannot die. The specification of requirements is a direct expression of the essence of a systematic approach and thinking. The more complex the system, the more accuracy and care required when making any changes. And the created systems do not become easier...
On the other hand, the Facts are a stubborn thing - honest process/architectural work with a cascade of formed specifications, classic As-Is To-be transitions come across much less often, from start-ups unicorns are born, and certainly there weren't any specifications in them...
We invite you to a discussion at the round table:
- Influence of two paradigms on Business and System Analysis: design and product.
- How to move from one paradigma to another with minimal personal and organizational losses.
Visual models of corporate application
When designing complex enterprise applications, it is effective to use models that describe the subject area and the application itself in accordance with the Domain Driven Design approach. At the same time, good visualization is an indispensable attribute of the model. We will exchange experience in building an application architecture using three main models: a domain model, represented by a class diagram, a resource movement model, represented by accounting diagrams, and a workflow model based on a state diagram. All this is complemented by a business process model based on the activity diagram (activity diagram) and combined by the Archimate enterprise architecture model, and complemented by a system metaphor when it comes up to be invented. We will show examples of diagrams from real projects.
Spiral dynamics model for multicultural communication of analysts
Analysts work between the cultures of customers and the dev team. Even in one company, the cultures in divisions often vary dramatically. Analysts must have the competence to recognise the culture of users and customers quickly and align to it because the culture sets an implicit context and defines the meanings of concepts. Later they should transfer the meanings and implications to the development team based on their culture. Also, the sensation of the culture is significant during the maintenance of software to provide joint activities of people of different cultures.
For fast and effective operations in various cultures, we can’t explore the corporate culture of a company or a division separately. We need to have cultural models in our kit. I'll talk about the spiral dynamics model that describes and operates with the values and culture of people and organisations. This talk continues and develops my lectures and articles about it, with a focus on the activities of the analysts.
Solving the client’s problem rather than blindly doing the task
Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.
demonstrates how it can be done and provides the examples of how
the immersion into the business plan of the project
changes the ways of solving the problem.
Tester and DevOps: Can you effectively resolve incidents using interface of your system?
of the tester's tasks is to look on the system through the
helpdesk's eyes, to check whether the interfaces of the system can
effectively resolve incidents according to SLA. Good resolution of the incident is not only to localize the error
in the system, but also to help the user solve his business problem,
find a workaround "here and now." Even in the case, then the cause of the problem is situated in the another system. Experience shows that this is often a weak point and requires the
involvement of developers to directly analyze the data and correct it
directly in the database.
Based on my experience, I will tell you what functions are useful in the system for the effective resolution of incidents of inter-system integration, as well as incidents related to processing of special business situations and deals not provided for in the system. I think the story will help listeners look at their system in terms of compliance with the SLA.
Agile: what does the analyst need to know for action?
Quite regularly you hear questions like the following: "We have a Scrum project, I need to write test cases for the testers, and I do not understand where I get information from." When you start to discuss, it turns out often that the word "Scrum" in the project they know some original design, while the inquirer is precisely sure that this is exactly Scrum. Meanwhile, Scrum and other Agile methods are a normalized model, about which you can read the documents, and from which you can get answers to this and other questions. But I will not provide the documents. I will show how to think in the logic of Agile mindset, get answers to this and other issues. Of course, as long as such values of the Agile Manifesto as working software, cooperation with customers and others do not seem to be a mere sound. I will show everything on real cases from listeners, solving their problems.
Technology for Self-determination
The problem of self-determination, planning and building own future becomes more and more actual nowadays, comparing to the past, when you determine only ~2 times, when define your profession and create your family, and moreover, this was pre-defined by your family.
Today you should do that regularly, moreover - in fast changing world, we see that especially in the IT-world, when technologies change rapidly.
I've built and prepared a bunch of schemes helping to do that. I'll tell about them in my talk, and then I'm ready to solve your cases in the bar camp format.
Methods of requirements processing and design: what is the best for your project?
Methods of design and requirements processing should ensure effective communication between team members and provide agile development of software with the possibility of further modernization. In the course of evolution, IT has accumulated a rich set of practices for projects with different complexity, scale and purpose: user story, use case, BDD, TDD, FDD, DDD, architectural work in SAF, and more traditional approaches. As it always happens with a wide range of tools, the problem of choice appears. Well-known tools or methods' comparision on model tasks are mostly preferred. But what's good for small tasks, not always suits long project.
The report provides an overview of various practices that help to solve communication problems and the conceivable models of labour division within the team. The presentation also considers approaches to support the product development and modernization on a long life cycle. This report develops the ideas of my "Agile Engineering practices" post.
Essence of Responsibility for Quality in Different IT-Projects and Sharing Principles
Many QA professionals are convinced that IT industry has perfect vision of the quality and the means of its achievement. Therefore, the situation, when you switch to another company this ideal appears to be different, most values are being challenged, and common ways of working are very distinguishing, becomes an unexpected shock.
The fact is that understanding of the quality criteria in IT-projects has come a long way from orientation to the perfect engineering product to meeting the steak-holders’ interests and providing prospects for business. Currently the awareness appears that different projects require different quality, and its criteria vary during the project.
The report considers the space of quality criteria description and shared responsibility in the projects, which are to be examined for detailed examples.The speech develops my preceding reports (http://mtsepkov.org) about the evolution of quality criteria (AgileDays-2015) and sharing responsibilities (AnalystDays-2015).
Communication with different MindSet: Taxonomy vs Folksonomy
An analyst starts his work with building a hierarchical structure of terms, where all clears and understandable for all stakeholders. This is a scientific mindset. However, there is an alternative - a tag cloud of concepts with associative chains. Therefore, thinks the child, when still cannot create logical structures. Previously we believed that a professional’s mindset should be based on hierarchical structure, but now comes the understanding that second mindset also works effectively: marketing, political technologies and media follows by this way.
There was even a special word – folksonomy – contrary to the taxonomy for logical classification. Imagine that you describe a clear hierarchical architecture to a colleague and it seems he knows all the words. Only in his head instead of taxonomies - cloud folksonomy in which your design will fall quite differently.
The analyst must be able to work with it, and in the talk, I will give a few methods based on schemes of SMD-methodology.
Sharing responsibilities in the custom development
Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing. The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.
Spiral Dynamics: understand values - and act
Last autumn my range of vision was extended by such model as Spiral Dynamics. It gave me systematic viewpoint of many trends such as community development or IT (as well as not IT) management.
I spoke about the Spiral Dynamics itself on Agile Days conference. Here I’m going to explain how it influences on understanding of processes used in the company, in the industry and in the world in general. Also I'll unfold how it might give you knowledge about how you can find proper place in these processes and how to make decisions more wilfully.
I’m going to do it from Software Test Engineer point of view. Precisely from Software Test Engineer who is going to grow into Manager. I’ll consider some important questions and provide Spiral Dynamic’s answers on them.