Jak radzić sobie w projektach, gdzie brak inżynierii wymagań?
Więcej na ten temat w moim artykule: Inżynieria wymagań wychodzi z ukrycia (http://www.computerworld.pl/artykuly/395371/Inzynieria.wymagan.wychodzi.z.ukrycia.html)
W wielu projektach i wielu firmach, inżynierii wymagań jest za mało, albo wręcz nie ma jej wcale. To oczywiście niedobrze, ale zwykle nie jest aż tak źle, jak może się wydawać. Gdyby inżynierii wymagań nie było wcale, znaczyłoby to, że nikt nie ma pojęcia o budowanym produkcie IT, ani o celu projektu, to niczego by w ogóle nie zrobiono.
Ta pozorna sprzeczność tłumaczy się tym, że inżynierię wymagań często uprawia się pod innymi nazwami, jako element innych zadań w projektach. Uprawia się jako-tako, ale można by lepiej!
Rozwiązanie właściwe to oczywiście ulepszenie procesu tak, aby inżynieria wymagań znalazał w nim należne jej miejsce, co jednak wymaga rewolucji, organizacyjnej i mentalnej. Rozwiązaniem krótkoterminowym jest ulepszanie inżynierii wymagań i jej praktyk od ręki, niezależnie od tego, pod jakimi pseudonimami się ukrywa.
W tutorialu będziemy trenować, jak to zrealizować w praktyce.
[ reszta opisu zostaje po angielsku – w końcu tutorial też będzie po angielsku ;-) ]
1. Requirements engineering as part of practical project management
Since project managers are responsible for project resources and deadlines, they must of course be responsible for its scope as well. Therefore, they must often take care of all requirements engineering activities. How can this be improved without changing processes too much? There are many good RE practices hidden in PMI and PRINCE 2, for example.
2. Requirements engineering in agile
Agile framework is very requirements-centred, and creates huge potential for extremely well-focused and disciplined development, but this fact is sometimes hidden behind the façade of little documentation, networking, self-organizing and funny terminology.
Agile can be made sharper still by more consciously following the best practices of “traditional” RE, and there is plenty of room in agile for great RE practices.
3. Requirements engineering in design and programming
Many great RE practices are already implemented in methods better known as programming practices such as DDD, BDD, FDD and TDD, and their full potential can be enhanced if we exploit their RE-related powers fully. But even without these methods, practical RE issues have always been, still are, and will always be solved by programmers, especially by great programmers, who seem to perform their RE-chores on the fly, on their way to great code. We’ll study how it works, and how it can work better still.
Then, of course, RE is to some extent done together with design modelling, and we’ll have a look at this option, too.
4. Requirements engineering in business analysis
Business analysis is an important part of RE, but I have seen many projects, where it seemed to replace complete RE altogether. In these cases, there was a huge yawning gap between business analysis and programming. We’ll try to bridge this gap.
5. Requirements engineering in testing
[więcej na ten temat: http://qualitology.blogspot.com/2014/05/continuoaus-requirements-engineering.html]
Testing and requirements engineering are sister (or brother) activities in many respects, but in this part of the tutorial we’ll focus on how test analysis and design are in essence very much requirements elicitation and analysis by other means. Seen this way, both RE and testing can be much improved, and projects can achieve much better results if they are aware of this. We’ll try to discover how.
6. Exploratory testing as ersatz requirements engineering
In many-a-project exploratory approach to testing has managed to find and help remove bugs that other test approaches have failed to identify. Apart from its other good practices, such as continuing test design during test execution, and still more apart from often hysterical and ideological (not to say “religious”) aspects of the popularity of exploratory testing, its real power is in being a very effective complement to, or even replacement for requirements elicitation and analysis, which could not have achieved the same.
Great results can be achieved if we learn how to put these two unwilling allies to co-operation.
7. Requirements management is in everything
Now it seems that the author of this tutorial has caught excessive proselyting fever, but it is actually true: even in most trivial, every-day misunderstandings and failures, the principles well known from RE are at work. We’ll study a number of communication, organizational, group dynamics and other psychological issues for the point of view of RE and discover, how it may help improve not only our IT projects, but virtually all projects, including daily lives.