Jak definiuje się jakość w zwinnych metodykach wytwarzania oprogramowania (Agile Programming)?
a) jako zgodność oprogramowania ze specyfikacją wymagań
b) jako zgodność oprogramowania z historyjkami użytkowników
c) jako uzyskanie zadowolenia klienta
d) jako zgodność ze standardami oprogramowania
Założyłem się z kolegą o browara, moim zdaniem jest to odpowiedź a, jego - b
b) jako zgodność oprogramowania z historyjkami użytkowników
IMO jest to z góry błędne założenie. Historyjki bardzo często są niekompletne pod kątem wymagań bądź nie przewidują pewnych przypadków.
Powiedziałbym, że A oraz C.
A oraz B wpływają na C,
a zatem C?
pomocy_nie_wiem napisał(a):
Założyłem się z kolegą o browara, moim zdaniem jest to odpowiedź a, jego - b
A co jeśli jedyną specyfikacją są historyjki? Czyli historyjki są szczególnym przypadkiem specyfikacji?
BTW odp c) zrób tak żeby było dobrze
BTW2 coś takiego jak d) w zasadzie nie istnieje
UPDATE oczywiście jak się idzie do sądu to najważniejsza jest umowa
Takie wzorcowe Agile to C:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
https://agilemanifesto.org/principles.html
Oraz D:
Working software is the primary measure of progress. (…) Continuous attention to technical excellence and good design enhances agility.
Z A i B jest o tyle problem, że to wtedy przestaje być Agile, tylko zaczyna być Waterfall albo coś innego, same założenia Agile sa takie, ze specyfikacja/wymagania będą sie zmieniać i trzeba reagować na zmiany
C, przecież o to chodzi. W A i B brakuje takich punktów jak:
Przecież punkty a i b są praktycznie tożsame. Specyfikacja wymagań, to rozwinięcie historyjek użytkowników.
O ile wiem, to pojęcie "jakość" nie występuje w metodykach wytwarzania oprogramowania. Zawsze słyszałem jedynie o koszcie, czasie i zakresie. Jeżeli już miałbym pod coś podciągać tę "jakość", to pod zakres. Przekładając to na język agile, pewnie wyszłoby, że jest to dostarczona funkcjonalność zgodna z wymaganiami klienta i DoD ustalonym przez zespół.
piotrpo napisał(a):
Przecież punkty a i b są praktycznie tożsame. Specyfikacja wymagań, to rozwinięcie historyjek użytkowników.
prawie, to jak z tym obrazkiem z huśtawką: 
ogólnie mam wrażenie, że tworzenie oprogramowania to czasem "głuchy telefon at scale".
Z pewnością C)
D) rozumiem jako naturalną kolej rzeczy bo trudno oddać klientowi coś co nie jest zgodne ze standardami programowania.|
Oczywiście tych standardów można się trzymam ściślej lub luźniej ale im mniej tych standardów się trzymamy tym gorzej świadczy to o jakości samego wykonawcy.
Agile nie znaczy że tworzymy rozwiązania "na odpi...dol" tylko tworzymy bez ścisłych założeń a oprogramowanie ewoluuje w czasie jego budowy i rozwoju.
W praktyce bardzo często projekty i tak kończą jako Agile nawet jeśli założenia początkowe dotyczące wyboru metodologii tworzenia były inne :-)
Na studiach i w pierwszych latach prowadzenia firmy dużo czytałem o projektowaniu, UML'ach, metodologiach itp... W praktyce ciężko było je wprowadzić w życie obsługując małych klientów, którzy technicznie nie mieli wiedzy i nie byli gotowi by dobrze wytłumaczyć co zamawiają i jakie są ich potrzeby. Tym sposobem w większości przypadków zrezygnowałem z rysowania diagramów i omawiania szczegółów technicznych na rzecz przygotowywania wstępnie działających programów. Tylko po to by był punkt odniesienia do dalszej dyskusji z nieogarniętym technicznie klientem... Bo ten jak nie widział to nie było szans żeby sobie wyobrazić. Na swoje potrzeby metodologię tą nazwałem "Wielką improwizacją połączoną z gaszeniem pożaru w burdelu"...
Jak potężne było moje zdziwienie jak około 2004 roku przeczytałem manifest Agile.
Na początku byłem całkowicie przekonany, że jakiś programistyczny żart...
czas jednak pokazał, że to całkiem na serio :-)
katakrowa napisał(a):
Agile nie znaczy że tworzymy rozwiązania "na odpi...dol" tylko tworzymy bez ścisłych założeń a oprogramowanie ewoluuje w czasie jego budowy i rozwoju.
W praktyce bardzo często projekty i tak kończą jako Agile nawet jeśli założenia początkowe dotyczące wyboru metodologii tworzenia były inne :-)
Oczywiście, ze nie chodzi o robienie na odwal. Wręcz przeciwnie. W długim, projekcie waterfall kod, który napiszesz nigdy nie wróci do ciebie, bo jak ktoś już go faktycznie odpali, to jest spora szansa, że będziesz w innym projekcie, firmie, albo nikt się nie zorientuje, że to twój kod. Po co masz go pisać porządnie, skoro do ciebie nie wróci, a jak napiszesz porządnie, to szanse nie wyrobienia się w zaplanowanym na tego taska czasie rosną?
Jak pracujesz w prawdziwym agile, a nie jakiejś wymyślonej przez klaunów atrapie typu scrum, czy nie daj boże SAFe, to kod wróci do ciebie od klienta w ciągu godzin wraz ze zjebkami, że miało działać, a nie działa, więc warto się przyłożyć. W dodatku wiesz, że za chwilę będziesz w tym kodzie grzebać przy ficzerze, którego jeszcze nie znasz, więc znowu - opłaca się robić to dobrze. A pożar w burdelu, to najwyższa forma agile. Trzeba olać wszelkie szacowania, robić to co jest potrzebne na za chwilę, cele są jasne. Jak ktoś przychodzi z problemami typu "jak nasz burndownchart będzie wyglądał", "czy powinniśmy bardziej zwracać uwagę na KISS, YAGNI, czy może na SOLID", to dostaje szybkiego kopa i można pracować dalej. Dla mnie to taka projektowa nirwana.
Jedna rzecz, to nie tak, że tworzymy bez ścisłych założeń, bo to co ma zostać zrobione za chwilę musi być dokładnie zdefiniowane, przynajmniej jako "czego chce użytkownik". Ale faktycznie, im task bardziej odległy w czasie, tym mniej o nim wiadomo.
pomocy_nie_wiem napisał(a):
Jak definiuje się jakość w zwinnych metodykach wytwarzania oprogramowania (Agile Programming)?
a) jako zgodność oprogramowania ze specyfikacją wymagań
b) jako zgodność oprogramowania z historyjkami użytkowników
c) jako uzyskanie zadowolenia klienta
d) jako zgodność ze standardami oprogramowania
Zależy co rozumiesz przez "jakość". Dług techniczny? Ilość błędów, w kontekście bugów/niezgodności wymagań? Błędów w kontekscie erroów/wyjątków? Jakiekolwiek inne kryterium?
a) jako zgodność oprogramowania ze specyfikacją wymagań - to wymagałoby dokładnej specyfikacji wymagań, coś czego prawie żadny klient nie dostarcza.
b) jako zgodność oprogramowania z historyjkami użytkowników - to wymagałoby dobrze spisanych historyjek userów, czyli znowu coś co się prawie nigdy nie zdaża
c) jako uzyskanie zadowolenia klienta - maybe, ale klient nie jest świadomy wielu rzeczy, np złożoności obliczeniowej algorytmów, alternatyw, etc.
d) jako zgodność ze standardami oprogramowania - maybe, ale to coś co techniczni ludzie docenią, nietechniczni nie.
Wszystko się sprowadza do dokładniejszego zadania pytania.
pomocy_nie_wiem napisał(a):
Jak definiuje się jakość w zwinnych metodykach wytwarzania oprogramowania (Agile Programming)?
"Agile Programming"? A gdzie słyszałeś taki termin.
KamilAdam napisał(a):
klient nie jest świadomy wielu rzeczy, np złożoności obliczeniowej algorytmówjak mu produkcja stanie bo złozoność jest 2^n to się dowie co to jest XD
Zauważy że "działa źle", albo "nie działa w ogóle", ale nie skuma co to jest złożoność, jak ją naprawić, albo z czego wynika.
Riddle napisał(a):
ale nie skuma co to jest złożoność (...), albo z czego wynika.
Jeśli aplikacja aplikacja działą coraz wolniej dla coraz większej ilości danych to często bardzo łatwo to wyjaśnić złożoności liniowej -> będzię działać dwa razy wolniej dla dwa razy wiekszych danych.
Dla innych złożoności (za wyjątkiem const) jest prawdą : im więcej danych um dłużej trwa. I to też w miarę ogarnięty klient powinien zrozumieć.
Przynajmniej ja takie problemy mam najczęściej. Na testach klient importuje excela na 1k linii, a na produkcji na 20k linii. I potem jest zdziwienie że nie działa XD
ale nie skuma co to jest złożoność, jak ją naprawić
To jest ciekawe połączenie, bo rozumienie czym jest złożoność a nawet wiedzenie z czego wynika, często i tak nie zmienia tego że bardzo trudno ją naprawić. Lub nawet zmniejszenie złożoności jest niemożliwe (w ramach budżetu np). Albo żyjesz w 2009 roku a klient chce przeszukiwać dokumenty jak jak google, a Elastic Search jeszcze nie istnieje XD a Lucene używało się naprawdę źle
KamilAdam napisał(a):
Riddle napisał(a):
ale nie skuma co to jest złożoność (...), albo z czego wynika.
Jeśli aplikacja aplikacja działą coraz wolniej dla coraz większej ilości danych to często bardzo łatwo to wyjaśnić złożoności liniowej -> będzię działać dwa razy wolniej dla dwa razy wiekszych danych.
Dla innych złożoności (za wyjątkiem const) jest prawdą : im więcej danych um dłużej trwa. I to też w miarę ogarnięty klient powinien zrozumieć.
Przynajmniej ja takie problemy mam najczęściej. Na testach klient importuje excela na 1k linii, a na produkcji na 20k linii. I potem jest zdziwienie że nie działa XDale nie skuma co to jest złożoność, jak ją naprawić
To jest ciekawe połączenie, bo rozumienie czym jest złożoność a nawet wiedzenie z czego wynika, często i tak nie zmienia tego że bardzo trudno ją naprawić. Lub nawet zmniejszenie złożoności jest niemożliwe (w ramach budżetu np). Albo żyjesz w 2009 roku a klient chce przeszukiwać dokumenty jak jak google, a Elastic Search jeszcze nie istnieje XD a Lucene używało się naprawdę źle
No nie, niekoniecznie.
Klienci czasem myślą że to normalne, że jak masz 2x więcej danych to aplikacja działa 2x wolniej, uploadujesz 10x większy plik to się uploaduje 10x więcej. Klienci rzadko kumają róznicę pomiędzy O(n) od O(n^2) np.
Owszem, kumają czym jest performance, optymalizacja, etc. ale tak niskie pojęcie jak "złożoność obliczeniowa", raczej nie.