This text assumes that the reader is familiar with the so-called. agile manifest software development and its so-called. underlying principles .
At the moment there are a huge number of people who accept this "manifesto", agree with it, and even try to use it. But for me personally, it looks like a joke that has dragged on.
We are constantly discovering more advanced software development methods, developing ourselves directly and helping others. Thanks to the work done, we were able to realize that:
Concept is more important than new requirements
Quality is more important than speed
Doing the right things is more important than doing what they are asked
That is, without denying the importance of what is right, we still more value what is left.
The highest priority for us is the fruitful and productive work of the programmer, thanks to a well-thought-out plan and following the software development technology. And, as a result of all this, satisfaction with the results of their work.
Changing requirements is possible, but new requirements must go through the same stages of understanding that all old requirements have gone through. The customer must be aware that changing the requirements may entail processing the product.
The product should be released only when it reaches the required level of quality. No, there can be no fixed periodicity.
Everyone must understand what he does and try to do it well. Unsuccessfully done work on sales or planning should not turn into an endless stream of amendments to the requirements or deadlines, that is, passed on to engineers.
The project should work motivated professionals. To get the job done, create the conditions, provide support and trust them completely.
Direct communication should not interfere with immediate work. Meet when they are needed by the work process.
Quality product - the main indicator of success.
No one should work "for wear". You need to work calmly, without following unreasonable "rhythms" and "cycles". Recycling is not allowed.
Constant attention to the process improves the quality, reliability and flexibility of the system.
The best requirements, architectural and technical solutions are born from teams that work closely on requirements, architectural and technical solutions.
It is useful to conduct reports and seminars in order to increase the general professional level and degree of involvement in the overall process.
Before you start developing software, you need to do two things:
If the customer suddenly resorts with new requirements, then you need to be not “ready for changes”, but ready to compare the new requirements with the old concept.
If the requirements fall on the existing model and architecture - fine. Put the task in the queue. If they do not fall, then you need to either adjust or discard the new requirements, or change the model and architecture so that the requirements for them are laid down. And this is a new planning, a possible rework of what has already been done, that is, time and money.
If the customer does not understand this, then he needs to patiently explain it, and not rush to the first call to run in the direction indicated by the fleeting wave of his royal hand. Otherwise, instead of the software comes a bunch of stinking garbage.
In other words, the technical process is more important than the timing.
At construction go helmets. Why? Because it requires safety.
Software developers write tests and documentation. Why? Because such is the software production technology.
Numerous offices dump tons of idle or poorly working, ahem, software, instead of spending a little time to bring it all to mind. And then they start to fix bugs.
With alarming regularity, there are signals that the next application (or even the whole OS) after the next update stops working. What about weekly "technical" updates that improve "overall stability and reliability"? Familiar?
We ourselves create this vicious circle: everyone is in a hurry, so we are in a hurry, so everyone is in a hurry. It's time to stop and think.
. , X
. , , X
, , , , , , , A
, B
, , C
.
— "" " ", , " ", "", " ". , — , .
, . , , , , , , X
, , Y
, . , , ? ?
.
, , , "".
… , , — , ...
powerman
— . :)
DexterHD
Source: https://habr.com/ru/post/431064/
All Articles