Introduction

Recently asked a question:

Is agile evil? Or under what conditions is this winning approach?

The next 2 responses were roughly as follows:

  • " Adjail works only if the customer is ready to work in this way. ... But if the customer is not ready to work like this, then it is better not to get involved." ( response from @Qwertiy )

  • The requirements most often change. "In all the more or less large-scale developments I only worked a couple of times not with Agile ... when the customer gave out really finished TZ. ... In all other works, something was constantly changing (sometimes strongly, ... sometimes weakly ... .) ... "( reply from @avp )

Given the title of this my question, the answers are very much in the subject and very useful. But asking a question, I wanted to know even more. That is, how to organize a project so that a crocodile does not turn out from a product?

Does it not happen that: first, some requirements are implemented -> then new ones come -> a part of what is done -> breaks down - something new is being built on this already curved basis -> and in the end you get a crocodile?

If the output does not produce a product that is suitable both from the inside and the outside, then (I don’t know how to say it), either the Agile approach does not justify itself (or say so) or the project on Agile principles should not have been taken at all.

Question

Advise (options / wisdom / stuffed cones) how to build the code organization process in the Agile approach to fit in with the framework of the approach from t. management (sprints, deadlines, requirements, customers, management), but so that the product can be developed and maintained after delivery ?

Clarification of the issue

  • How to initiate the project structure, what should the project framework look like, including the database? After all, usually the project has a database !!. How to deal with database with varying requirements? That is, how to make a flexible frame of the system in order to increase the performance later (throw out, change, add) but at the same time do not do it all over again every time?

Any advice, thoughts, observations, conclusions from experience are interesting.

Update:

Short descriptions of technical solutions are very interesting. For example, from the available answers: to hide the old functionality behind the Facades . Or use units in the database according to the principles of DDD .

Thank!

Crossed out from the old version of the question. In order that there was one question, not a lot.

  • How to make the product have such an organization code in the future to remain sufficiently "alive" for a long time and serve as a benefit? To meet the new adequate challenges and in an acceptable degree adapt to reality? So that there is no such thing, that the reality has to adapt to the program because of the code structure, because the program does not exactly what is needed, but there is no way to change it (just to make a new product almost from the beginning)?

  • It is clear that there is nothing perfect. It is more likely that the project will not be a failure in the long term.

  • TDD, BDD terms pop up in your mind ... What is their place in the design and implementation?

  • I think there are two extremes. Perfectionism and licking code, when it is not necessary to anyone (on the one hand). And "it works - do not touch it", when everything is confusing inside, but it is necessary to increase the functionality and it is almost impossible (on the other hand). It seems to me that for success both extremes must be avoided. Where is the golden mean? How does the code look like with this golden middle?

  • Even if at first it is clear that the requirements are fuzzy, and the customer is ready to work on the principle of periodic sprints, then this, as I understood only the necessary conditions, but not sufficient ones. Could there be such that if there is no beautiful / good solution for designing the basic basis of the future application (what I called the frame, including the database), then you should abandon the Agile project, or postpone the start of the project (if possible) before clarifying requirements or finding the right design solution?

  • Extended form of the previous paragraph. Suppose there is already a basis from the old software, over which it is necessary to make a new functionality. As is often the case, for good, the old must be concretely, structurally modified, before we build on the new (or even throw out the old). The old is already dead, as it were, but is still in use. The only possibility, as it seems to me, as botanists do, is to stick a small sprig of new to the old trunk so that it will take root and grow into a new tree. That is, with the help of some technical device, use the old system as a black box or as a resource of a new system. If there are no beautiful / good design decisions on modifying or on such ways out of the situation as botanists do, then is this an early sign of a project’s failure in the long term?

  • I understand that this is all theory. In practice, everything is more complicated. Also, I understand that each project has its own situation. Some project will be advantageous even if the organization of the code is tangled, some way around, only if it is not tangled.

  • 3
    Good question, but it seems to me that it can draw a whole book on management ... - pavel
  • @pavel, yes ... So detailed, because I really want to get a detailed answer or different points of view from different angles ... I hope they won't get banned ... - Andrey K.
  • @AndreyK. Unfortunately, the question, although it is interesting, was too extensive. You should leave in the body of the question one real question, and the rest - arrange individual issues. - PashaPash ♦
  • For those who will answer - I will close the question as too extensive. The existing answers seem to be completely directing the topicaster in the right direction. To open from the question is to remove the entire bottom. Leave any item from the bottom at the discretion of the topicaster :) - PashaPash ♦

4 answers 4

A summary of my experience.

I am a Proxy Product Owner / Technical Director for a SaaS project, which is developed by SCRUM. I also engaged in the implementation of SCRUM on the project about 6-7 years ago.

A project with a history (lives for more than 12 years), with several changes of target niches, 2 attempts to rewrite from scratch.

The basic principle when introducing any thing / feature / technology (tests, agile, anything at all) - all interested people (including the customer / PO) should clearly understand what is being implemented and why.

  • The customer must understand that the team writes tests for a reason, and for the sake of reducing the regression
  • The customer must understand exactly what the specific technical debts are about (not generally the fact of technical debt, but each specific remaining debt).
  • The team must understand the motivation of the customer and users. Must step on his throat, and, if necessary, release with bugs.
  • The customer must understand the price of each change (and not only $, but in impact changes to the same product sustainability)

Actually, the main problem is to convey the point of view of each of the parties to the rest.

Otherwise it will not take off.

The choice of tools / approach / moment for thinking about architecture is secondary. The database is a piece of code. There are systems for tracking changes, there are standard approaches for migrating the database to the new version. Use them.

In your question you are trying to cover everything at once. Unfortunately, the things you are asking about are:

  • development process (requirements analysis, planning, people interaction)
  • abstract approach to architecture (TDD / BDD / DDD and other DD)
  • Any specific technical solutions specifically for your problem (old project, black box and all that)

These are orthogonal concepts.

  • You can work on the Falls and at the same time use any solutions you like in the code.
  • You can work on Agile and at the same time use any solutions you like in the code.

Thinking architecture is not tied to the development process. Agile itself, roughly speaking, is not even a process. This is a group of processes, each of which to some extent fits the Agile manifest.

  • Individuals and interactions over processes and tools
  • Working software over Comprehensive documentation
  • Customer collaboration over Contract negotiation
  • Responding to change over Following a plan.

The problem with this manifesto is that it simply voices sound thoughts. Fully applicable in the same waterfall.

How does this manifesto control at what point you need to “make the base” and how to “work with the customer”? Yes, nothing at all.

Software development is the choice of the right process + the right technical solution + the right tools + the right people. No silver bullet. By the way, there is no golden middle either.

  • one
    But what about Evans' deepening refactoring? (I’m talking about " Thinking about architecture is not tied to the development process ") He quite fit the architectural changes in Agile =) - Dmitriy Simushev
  • @PashaPash. Oh how! That is, it all comes down to mutual understanding ... From a technical, tz. - Thank you for mentioning the database migration, you are already the second who said so. And so, in general, thanks, it is useful! All these answers add to the erudition on this topic. Maybe not only useful for me. - Andrey K.
  • Oh, technical debt is a good topic. If the customer agrees to pay for planned technical debt refactoring, this is a huge plus to the process. - Monk
  • The @DmitriySimushev thing is that any process that uses common sense implies changes, both architectural and requirements. Even the waterfall proposed by Winston Royce initially implied iterations , but they simply did not understand it (you need to add a video to the post :) - PashaPash ♦
  • one
    @AndreyK. Agile is not a specific process, so everything that is convenient for the team is combined with it. Technically, each of the Agile processes is a set of practices. If you are not sure, take scrum, it's easier to sell to both the team and customers. From technical solutions, the duration of the project rather affects their choice. Those. a long project -> need tests. The base is more complicated than 2 tables - take migrations. If you are going to host the application at home - think about auto-heating and monitoring. But in general - use what is convenient for you, and try to find and fix problems in the process. - PashaPash ♦

Good day. Judging by the size of the issue, the problem is painful. Unfortunately, Agile is about people. Those. Your question is a little incorrect. You need an architect. Which will develop and fix architectural solutions, system limitations, etc. This process is complex and time-consuming, but it is the right architecture that allows you to further modify and modify the system. Moreover, even the most wonderful architecture in the world will not allow you to make an aircraft carrier from a pleasure boat. To make an aircraft carrier from a helicopter carrier, yes, but not from a boat. The most important thing is this restriction. Agile also talks about this, you just need to hear. For example, in Agile there is a point that it is necessary to postpone decision-making until as late as possible. But not later. If you made the decision to make a boat, then if the customer wishes - an aircraft carrier, you will have to start from scratch. Well, then, when you have identified the main limitations, you start to look in the direction of SOLID, patterns, etc. Adequate architecture will allow you to make changes to the existing solution at a low cost, but if you miss the architectural solution, then you are again at the beginning. Well, for specificity. Your last point about the old system. If there SOLID is observed, then you can adequately transfer many parts of the old system to the new one. If not, then as an option to make adequate facades (design pattern) through which to use the old functionality, gradually replacing it with your own implementations. It is difficult to respond to such a big cry of the soul. If there is something specific, specify, let's try to help.

    I will try to write my own vision, but it is very subjective.

    Advise (options / wisdom / stuffed cones) how to build the code organization process in the Agile approach to fit in with the framework of the approach from t. management (sprints, deadlines, requirements, customers, management), but also so that the product can be developed and maintained after delivery.

    Virtually nothing depends on the code here. The main condition is that the code should not be scary noodles without signs of OOP. Everything else is completely fixable. Make the most of the main plus - feedback. Everything that is being done should be shown as early as possible if not to the users, then at least the analyst \ PO \ customer. All of their feedback - process, deciding which ones are important for the product, and which ones are a whim and are not needed. Well, someone else (PO usually) should always keep in mind the whole product vision. Not every single particle, namely the whole product. To add a new bun did not look like a crutch. To change some little things not out of the general "style" of the program.

    Or how to make the product have such an organization code in the future to remain sufficiently "alive" for a long time and serve as a benefit? To meet the new adequate challenges and in an acceptable degree adapt to reality? So that there is no such thing, that the reality has to adapt to the program because of the code structure, because the program does not exactly what is needed, but there is no way to change it (just to make a new product almost from the beginning)?

    I did not understand what the problem was. Check out DDD, it will quite sensibly explain how to develop programs so that they are not “from programmers to programmers”, but were developed taking into account the needs of users and for users.

    The most interesting thing for me! How to initiate the project structure, what should the project framework look like? After all, usually the project has a database !!. How to deal with database with varying requirements? How to make a flexible frame of the system in order to increase the future (to throw out, change, add) but at the same time not to do it all over again every time?

    DB can always be converted. In the database, there must be "units" in the understanding of DDD, so that they never have to alter them in principle. The unit always exists in this world, and therefore it is understandable to users. Moreover, the aggregate itself should be imposed on you by users, and not vice versa, then it will be expanded rather than copied.

    Regarding the rewriting of the old and everything else: In order to start writing a project or start rewriting a project, you need specialists who can plan / design it and at the same time will understand the subject area at least in large ways. An experienced architect at least at the initial stage is necessary. It is critically necessary to break up the large “product” topic on the timeline as early as possible, and to coordinate it with the customer - all the more. Timeline will help to go on agile - they released a raw product, showed analytics \ PO \ to the customer, received feedback, redid it. A couple of prototypes before all this is also quite a good option.

    If you need some other information, either formulate specific questions or read the literature. By ajaila it is enough.

    • one
      @AndreyK. if you know what is meant by an aggregate in DDD, then any storage of this in the database solves problems with conversion, because it is completely independent and independent. There are, of course, problems, but they are everywhere. There are no perfect implementations and ideas. - Monk

    In my experience, in any case, you need a competent architect / timlid / "wizard". That is, the person who will keep the project in mind and make decisions. He should have enough experience and intuition.

    All questions about "how to create the right base" or "how to organize the project structure" are sent to such a person. Each project is more or less unique and there is no universal solution.

    But in any case, there are "blanks".

    • use version control systems. If something breaks, you can find when and why.
    • use tests. At least for critical areas. If you need to modify the old code - overlay it with tests and forth.
    • make the assembly "one button". Yes, yes, there must be either Jenkins (or any other system), or at least one script that can fully build and test the project.
    • Use migrations for the database.

    How does the code look like with this golden middle?

    and the code looks like that would solve the problem of the customer.

    Could there be such that if there is no beautiful / good solution for designing the basic basis of the future application (what I called the frame, including the database), then you should abandon the Agile project, or postpone the start of the project (if possible) before clarifying requirements or finding the right design solution?

    And why the search for a solution can not be part of the sprints? It is quite possible to divide the team into groups and each saws a minimal prototype. Managers can also work on sprints.

    In general, all your questions arise because you are trying to take over the work of the architect, but there is no experience.