TDD vs BDD

Tak trochę w nawiązaniu do ostatniego wpisu Michała Bartyzela na temat świętej trójcy Szybko-Dobrze-Tanio. I tego co w czasie tegorocznej Confitury padło w czasie bodajże pierwszego keynota, że:

Soft tworzymy przede wszystkim dla biznesu

czy jakoś tak (sorry nie pamiętam dokładnie, będzie nagranie, to poprawię).

Otóż to tak do końca nie działa. Moim zdaniem, można wyróżnić dwie osie przy tworzeniu projektów. Wszystko to, co robimy, będzie gdzieś na płaszczyźnie przez nie wyznaczonej.

TDD – Technology Driven Development

Jak sama nazwa wskazuje na tej osi „mierzymy”, jak bardzo potrzeby techniczne są ważne w projekcie. To tutaj będą siedziały wszystkie problemy związane z pisaniem testów, infrastrukturą CI/CD, ogólną jakością kodu (cokolwiek to znaczy), czy wykorzystywanymi rozwiązaniami.

Projekty, które bardzo mocno stawiają na zagadnienia technologiczne, najprawdopodobniej będą miały bardzo wysoką kulturę inżynierską. Dobrze zdefiniowane, poukładane i przemyślane procesy związane z produkcją i wdrażaniem kolejnych wersji. Do tego worka trafią też wszystkie projekty, które wymagają wysokich standardów out-of-box, bo np. muszą spełniać bardzo wyśrubowane normy. Mogą to być projekty bardzo proste, gdzie łatwo zadbać o jakość, ale mogą to też być bardzo skomplikowane i złożone systemy.

Na drugim końcu tej osi są projekty, w których nie tyle nie dba się o technologię, ile nie jest ona aż tak istotna. To tutaj wylądują wszystkie projekty, które ograniczają się do zakupu i instalacji gotowego rozwiązania. W tym przypadku jakość techniczna jest rzeczą wtórną. Zazwyczaj jest oddelegowana do dostawcy.

Gdzieś pomiędzy leży „ciemna strefa za dwunastnicą”, czyli typowe korpo-projekty. Niekoniecznie są złe, ale technologia nie jest w nich najważniejsza. To oznacza, że będą tam używane narzędzia, które co prawda są nieodpowiednie, ale pasują do korporacyjnego standardu. Może tam nie być dobrze zdefiniowanych procesów (ręczne wrzuty na PROD), albo brakuje odpowiedniego dbania o jakość.

BDD – Business Driven Development

Na drugiej osi znajduje się „wartość biznesowa”, a tak naprawdę to ile „biznes” ma do gadania. Przy czym biznes, to sfera finansowa/ekonomiczna projektu, a nie „domena biznesowa”.

Projekty mocno stawiające na biznes będą chciały sprzedawać. Tutaj liczą się przewaga konkurencyjna i dotarcie do klienta. Znajdziemy tutaj zarówno startupy, jak i „pewne inwestycje”. Celem jest zarobienie (normalne przedsiębiorstwa) lub eliminacja konkurencji (startupy).

Drugi koniec osi okupują badania podstawowe i projekty społeczne. Takie projekty z natury nie mają zarabiać. W przypadku niektórych z nich jest szansa, że wykluje się z nich jakiś produkt. To przede wszystkim projekty badawcze. Niestety w ostatnich dziesięcioleciach system grantów zmienia podejście do badań podstawowych. W efekcie największe wsparcie dostają projekty mające szansę na zarobek, a nie na odkrycie czegoś sensownego. Co z projektami, które nie mają szans na zarobek? To projekty społeczne. Ich cele są poza finansowe i trudno mierzalne. Jednak są albo konieczne z punktu widzenia prawidłowego funkcjonowania i rozwoju społeczeństwa, albo z powodów etycznych.

Pomiędzy nimi będą wszystkie te „małe i średnie, ale stabilne biznesy”, które oferują usługi ograniczone geograficznie (lokalne jedzenie), kulturowo (wydłużanie szyi) czy skierowane do specyficznego odbiorcy (np. kolekcjonerzy Lamborghini). Oczywiście na swoim lokalnym rynku mogą one konkurować, tak jak firmy z pierwszej grupy, ale zazwyczaj lokalny rynek w przypadku takich usług jest stabilny.

Szybko, Tanio, Dobrze

A jak ma się to do św. Trójcy Projektowej? To zależy. Odpowiednio ustawiając swój projekt w obu tych osiach, można spróbować oszacować, w jakim stopniu będziemy mieli Szybko, Tanio, Dobrze.

Projekty czysto biznesowe, o niskim poziomie technologii, będą mocno ciągnęły w kierunku „Szybko”. To czy będzie „Tanio” i „Dobrze”, zależy od tego jak bardzo zaangażujemy się w dobór technologii.

Projekty czysto techniczne, będą kierowały się ku „Dobrze”. A ich „Tanio” zależy od tego czy są to badania, które mają szansę na zwrot, czy też projekty społeczne, które nie dają szansy na zarobek. „Szybko” jest uzależnione od celu. W przypadku projektów społecznych zazwyczaj są jakieś deadline’y.

Projekty silnie biznesowe i techniczne zarazem będą na pewno drogie i powolne. Sama ich specyfika powoduje, że „Szybko” skończy się katastrofą (patrz katastrofy Boeingów 737 MAX).

Z drugiej strony projekty mało biznesowe i mało techniczne, mogą być bardzo szybkie w realizacji. Ich koszt i jakość będzie uzależniona od ich specyfiki, ale mówimy to o projektach w stylu kanał komunikacyjny do umawiania się na piwo z sąsiadami.

Tyle.

Napisz odpowiedź

Twój adres e-mail nie zostanie opublikowany.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax