User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Wprowadzenie

O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.

Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:

Proces MBSE powstawania systemu
(more…)

Continue ReadingUser Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Regulamin Usługi jako Wymagania – projekt

Why is this happening? The methods of project execution by most IT vendors haven't changed in 30 years: talks, interviews, coding, expensive tools (C++, Java). We've known for 20 years that writing a program in C++/Java is twice as much work compared to an identical result achieved with scripting languages (Prechelt, 2003; 2000). The continuing popularity of C++/Java has its origin: most of the large systems in the fin/tech industry were created in the 1990s, and they are not being upgraded and only added functionality despite the fact that it is no secret how to migrate to newer technologies and architectures (Laigner, Kalinowski, Diniz, Barros, Cassino, Lemos, Arruda, Lifschitz & Zhou, 2020). The reasons are quite mundane: as long as there is demand, technology suppliers have no interest in upgrading their products and are selling a permanent technological debt (Rosoff, 2011).

Continue ReadingRegulamin Usługi jako Wymagania – projekt
Read more about the article Diagram aktywności UML c.d. – algorytmy
David Harel. (2001). Rzecz o istocie informatyki. Algorytmika. (Zbigniew Weiss & Piotr Carlson, Trans.; Wydanie trzecie). PWN.

Diagram aktywności UML c.d. – algorytmy

Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.

Continue ReadingDiagram aktywności UML c.d. – algorytmy
Read more about the article Diagram aktywności UML c.d. – modelowanie kodu
David Harel. (2001). Rzecz o istocie informatyki. Algorytmika. (Zbigniew Weiss & Piotr Carlson, Trans.; Wydanie trzecie). PWN.

Diagram aktywności UML c.d. – modelowanie kodu

Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.

Continue ReadingDiagram aktywności UML c.d. – modelowanie kodu