Software Craftsmanship w polskich firmach?

0

Czy są w Polsce firmy, które np. otwarcie przyznają się, że wyznają idee związane z Software Craftsmanship?

0

Spartez

0

Ocado Technology, Sonalake, UBS?

2

Ja bym zadała pytanie, czy są takie, które działają w dany sposób. Przyznawanie się do wyznawania idei nie implikuje faktycznego postępowania w zgodzie z nią.

0
ness napisał(a):

Ja bym zadała pytanie, czy są takie, które działają w dany sposób. Przyznawanie się do wyznawania idei nie implikuje faktycznego postępowania w zgodzie z nią.

Też chcialbym to wiedziec, ale może byc trudno z jakakolwiek odpowiedzia.

Niestety wszyscy są Agile, głównie marketingowo...

0

@ness
Prawda. Ale według mnie to jest własnie problem z powierzchownym wdrożeniem Agile poprzez np. dostanie certyfikatu itp. Przeciez na pewno twórcom manifestu nie chodziło o to, żebyśmy siedzieli na meetingach i marnowali czas. Przecież to nie jest ani trochę pragmatyczne.

Dlatego właśnie napisałem, że wszyscy są teraz Agile ale marketingowo, znaczy powierzchownie. I dl mnie to 1 punkt programu, że firma nie jest naprawdę Agile to właśnie siedzenie na bzdurnych meetingach.

Agile/Software Craftmanship to są dobre idee, szkoda tylko, że łatwo wypaczane. Bo takie rzeczy szybko podchwytuje 'biznes' i pozniej sprzedaje scrumy, agile hurtem byle jak, byle komu.

1

bo wielu ludzi mysli, ze implementacja takiego agile'a np. w postaci scruma to odsiedzenie d*pogodzin na mityngach. Metodyka ma nam pomagać, a nie jeszcze utrudniać życie. Jesli widzisz, ze mityngow jest za duzo i zaczynaja one kolidowac z Twoja produktywnoscia, a same nic nie wnosza to rozwiazanie jest jedno :-).

Co do firm to ja sie zgodze - do tej pory spotkalem sie tylko z marketingowym agilem. teraz to jest na topie, wiec kazdy to "robi", bo to przyciaga pracownikow. A pozniej wiadomo - kaszana

0

Czesto jest tez slepo sie trzymanie jakis zasad mimo, ze w pewnych warunkach moga nie miec zastosowania.

Np. Ja sie nie zgadzam, zeby caly zespol uczestniczyl w review. Starczy jak np. Te osoby beda sie wymieniac.

W poprzedniej firmie jeden team leader zrobil certyfikat ze Scruma... I szczerze powiem, ze byla to ostatnia osoba jaka powinna cos takiego zrobic. Po prostu wiedzialem, ze 'metodologia pracy' tego goscia nigdy sie do agile nie zblizyla, a wrecz temu zaprzeczala... Ale oczywiscie chwalenie sie scrum, agile i jakich to mamy super specjalistow...

0

Jak juz ktoś ma certyfikat to nie ma dyskusji ;-)

0
koner napisał(a):

Jak juz ktoś ma certyfikat to nie ma dyskusji ;-)

Ogolnie to nie wiem skad wsrod ludzi ten pociąg do certow i niby-wyzszych stanowisk.

Ja tam chce byc programista ;)

0

@koner
Powiem to wszędzie gdzie będzie trzeba, aż natrafię na odpowiednią firmę.

Te hierarchie są złe dla naszej pracy, na zachodzie ponoć to się zmienia.

0

Czyli, zeby pracowac w takiej firmie to trzeba szukac gdzies za granica?

5

Software craftmanship, to zapewne taki sam bełkot jak agile. Dobre firmy robią po prostu dobry soft w dobry sposób i nie potrzebują żadnych manifestów ani wzniosłych haseł do tego. I takie fajne, przyjazne programistom modele pracy i organizacji spotka się raczej w firmach, które nie mają wzniosłych haseł na każdej ścianie, konferencji i ofercie pracy. Więc jeśli chcesz pracować w firmie, w której praktykuje się software craftmanship, odrzuć najpierw te, które się tym głośno chwalą.

0
somekind napisał(a):

Software craftmanship, to zapewne taki sam bełkot jak agile. Dobre firmy robią po prostu dobry soft w dobry sposób i nie potrzebują żadnych manifestów ani wzniosłych haseł do tego. I takie fajne, przyjazne programistom modele pracy i organizacji spotka się raczej w firmach, które nie mają wzniosłych haseł na każdej ścianie, konferencji i ofercie pracy. Więc jeśli chcesz pracować w firmie, w której praktykuje się software craftmanship, odrzuć najpierw te, które się tym głośno chwalą.

Uważam, że agile i software craftsmanship same w sobie mają sens, ale łatwo to zamienić w bełkot. Ponieważ wiele z tych rzeczy jest na tyle miękkich, że rozumieja to ludzie nietechniczni i wypaczają to. Myślę, ze nie oceniałbyś tych rzeczy w takich sposób gdyby rynek tego nie wypaczał. W sensie ci którzy glośno krzyczą , że są Agile i SC to najczęściej takimi firmami nie są.

Więc tak, chciałbym pracować w takiej firmie co działa w duchu SC ale niekoniecznie głośno o tym krzycząca.

Nikt mi nie powie, że łatwo jest wybrać dobrą firmę , zwłaszcza w swojej lokalizacji w której będzie kult uczenia się i co jakiś czas nowe wyzwania a ludzie wokół sami seniorzy.

0
Zimny Młot napisał(a):

@ness
Przeciez na pewno twórcom manifestu nie chodziło o to, żebyśmy siedzieli na meetingach i marnowali czas.

Tutaj opinia jednego z twórców manifestu:
(Video) https://m.youtube.com/watch?v=a-BOSpxYJ9M
(Tekst) https://pragdave.me/blog/2014/03/04/time-to-kill-agile/

Tutaj trochę bardziej radykalna opinia :D

1

Process:

  1. I made a list of shit to do
  2. I did that shit
  3. I checked that it was good shit
  4. Repeat
0

Sorry za brak cudzysłowy.

Mimo wszystko uważam, że książki jak Pragmatyczny Programista albo ostatnia Software Craftsman(ship) warto przeczytać. Tylko nie można dać się zwariować ;)

3
Złoty Młot napisał(a):

Uważam, że agile i software craftsmanship same w sobie mają sens, ale łatwo to zamienić w bełkot.

One są bełkotem w samej swojej idei. Może ich twórcy mieli szlachetne intencje, ale w tym wszystkim chodzi o to, jak ludzie, którzy nie mają pojęcia o programowaniu, mają zarządzać programistami.

Ja pracowałem w firmie, która była "value dirven" i "agility" było jedną z tych wartości. Agile był na każdym kroku, aż do porzygania. Efektem było to, że 1/3 czasu pracy była spędzana na spotkaniach, bo tyle wymaga agile. Codzienny standup około 30 minut, raz na tydzień standup wszystkich teamów, to kolejna godzina. Obowiązkowe triangle z BA i QA kilka razy w tygodniu. Planowanie sprintu trwało 1 dzień, z powodu niezwykle drobnego podziału user story na taski. Podział był nieraz tak absurdalny, że planowanie i estymowania zadania trwało dłużej niż jego implementacja. A "customer collaboration" w praktyce wyglądało tak, że ludzie dziwili się, że wolę zrobić coś sam w 3 minuty, zamiast zepchnąć to na klienta, bo zgodnie z kontraktem to coś należało do jego odpowiedzialności. Do tego w firmie zatrudnieni byli nawet oddzielni scrum masterzy i agile coachowie. Naprawdę - oddzielne stanowisko dla gościa, który nie robi nic poza drapaniem się po jajach i prowadzeniem bzdurnych szkoleń.

I to nie jest jakiś jednostkowy przypadek, takich firm jest więcej. Są nawet gorsze przypadki - manager przeczyta coś o agile, i od następnego dnia wszyscy nagle mają pracować w parach i estymować sprinty. Nawet jeśli zajmują się łataniem bugów na produkcji.

Dla porównania, teraz pracuję w firmie, w której nie ma estymowania, nie ma scrum masterów, standupy trwają 10 minut, w parach ludzie pracują, gdy mają trudne zadania, i w ogóle, wszyscy rozumieją, że ich celem jest rozwój oprogramowania, nie trzymanie się jakiś tam procesów. W ogóle wszystko jest tak bardzo agile, jak tylko się da, tylko jakoś nikt nie czuje potrzeby pałowania się tym słowem na każdym kroku.

0

To faktycznie masakra. Z tego co slyszalem to allegro ma osobnych scrum masterow. Ogolnie nie wiem jak mozna slepo stosowac np. Scruma.

Ze software craftsmanship raczej bedzie ciezko zrobic cos jak z agile.

Ksiazka Software Craftsman uwazam natomiast, ze byla fajna i inspirujaca, ale nie ze wszystkim tam bym sie zgodzil. Ale sporo rzeczy jest tam opisanych co mnie boli.

Teraz coraz czesciej sie slyszy kogos jak narzeka 'ide do domu poprogramowac' ... Bo w pracy meetingi, szkolenia i siedzenie na jira i w mailu.

2
Krzywy pomidor napisał(a):

Ze software craftsmanship raczej bedzie ciezko zrobic cos jak z agile.

Założymy się? :)
Nie istnieją idee, których korporacje nie są w stanie wciągnąć, splugawić i przekształcić na swoją modłę.

0
somekind napisał(a):
Krzywy pomidor napisał(a):

Ze software craftsmanship raczej bedzie ciezko zrobic cos jak z agile.

Założymy się? :)
Nie istnieją idee, których korporacje nie są w stanie wciągnąć, splugawić i przekształcić na swoją modłę.

No dobra. Nie założyłbym się ;) Nadużywać wszystkiego jest wybornie łatwo... np.:

  • wspomniane programowanie w parach
  • mówiąc korpo, że programista powinien być bliżej klienta... może okazać się tragiczne w skutkach
  • w Software Craftsman jest dobry rozdział o rekrutacji... ale nie wiem czy byłoby dobrze pokazywać to korpo, ponieważ nauczą się jak udawać dobre rekrutacje... albo sprawią, że zatęsknimy za starym rodzajem rekrutacji...
  • powstanie coś jak Scrum 2.0...

Niestety chyba wynika to z tego, że korpo chcą mieć kontrolę nad programistami, a my chcielibyśmy mieć swobodę.

0

. Planowanie sprintu trwało 1 dzień, z powodu niezwykle drobnego podziału user story na taski. Podział był nieraz tak absurdalny, że planowanie i estymowania zadania trwało dłużej niż jego implementacja.

Bo Scrum to taki krypto waterfall. Wszystko zaplanować dobrze od A do Z, zanim się przystąpi do roboty. A potem tylko zaklepać zaplanowane rozwiązanie.

Dlatego może Scrum tak dobrze się przyjmuje w firmach, ponieważ pozwala na wprowadzenie waterfalla tylnymi drzwiami.

Dla porównania, teraz pracuję w firmie, w której nie ma estymowania, nie ma scrum masterów, standupy trwają 10 minut, w parach ludzie pracują, gdy mają trudne zadania, i w ogóle, wszyscy rozumieją, że ich celem jest rozwój oprogramowania, nie trzymanie się jakiś tam procesów. W ogóle wszystko jest tak bardzo agile, jak tylko się da, tylko jakoś nikt nie czuje potrzeby pałowania się tym słowem na każdym kroku.

Agile jest jak Tao, jesteś Agile dopóki o tym nie mówisz. W momencie, kiedy ktoś zaczyna używać słowa Agile, na ogół następuje już korupcja i wycieranie sobie gęby tym słowem dla zwykłego lansu czy łechcenia ego (także ego firmowego - nasza firma jest taka fajna, że używa Edżajlów). Tudzież dla samooszukiwania siebie i swoich przełożonych (prezesie, nie bój żaby - przyjęliśmy Edżajl! Teraz projekty będą szybciej szły, bo Edżajl jest magiczną bronią na opóźnienia!). Trochę jak propaganda zachęcająca do wejścia do UE przed 2004 rokiem... Też miał być raj na Ziemi.

0

Podejście do scruma jest mocno indywidualne, w poprzedniej firmie mieliśmy jednego agile coacha na 2k pracowników, zero dedykowanych scrum masterów (każdy zespół miał jednego człowieka, który dodatkowo był SM). Pracownikom to pasowało, pomimo tego, że planning to było pół dnia, do tego sporo bezowocnych meetingów, wnioski z retro bez żadnych wdrożeń, a demo musi być bo musimy się lansować na super zajebisty zespół.

Teraz w aktualnej robocie demo+review+planning zamykamy w 2h, daily nie jest daily, bo jest 2-3 w tygodniu. SM jest z innego zespołu. Co ciekawe poza mną nikomu to nie odpowiada, wszyscy narzekają.

Różnica polega na tym, że w firmie A agile/scrum jest od zawsze, a w firmie B został narzucony super polityką.

Scrum jest sprzedawany jako panaceum dla każdej firmy, podoba się każdemu menadżerowi, natomiast IMHO pasuje tylko dla części zespołów. Jeśli zespół ma produkt, zero produkcji to scrum jest ok, po kawałku dzielimy duże moduły, nikt się nie przeciąża. Jeśli zespół ma produkcję to woli naprawić bugi np do 15.00 i o 16.00 iść do domu, a tak idzie po 18.00 bo błąd musi być naprawiony do X godzin, a w międzyczasie jest jakieś spotkanie.

0

Ogólnie sprzedawanie metodologii zarządczych jako silver bullets znane jest we wszystkich branżach.

Pewne rzeczy to powtórka rzeczy spisanych 20-30 lat temu tylko inaczej, często dostosowane do języka branży X.

0
sarin napisał(a):

Scrum jest sprzedawany jako panaceum dla każdej firmy, podoba się każdemu menadżerowi, natomiast IMHO pasuje tylko dla części zespołów. Jeśli zespół ma produkt, zero produkcji to scrum jest ok, po kawałku dzielimy duże moduły, nikt się nie przeciąża.

No właśnie SCRUM ani trochę nie pasuje do produktów, to metodyka stricte projektowa.
Drugim dużym problemem jest też to, że dla większości fanatyków Agile == Scrum.

0

SCRUM jest jak sznur, można można się przy jego pomocy wspiąć na drzewo, ale można się też na nim powiesić.

To, że większość PMów pojęcia nie ma co się z tym sznurem powinno robić, i starają się nim gwoździe wbijać to już inna sprawa.
To jest smutne, ale większość PMów nawet nie wie po co to jest, ani jak to działa i kończy się to wciskaniem jak największej liczy historyjek do sprintu, a to, że później połowa z nich spada na następny niczego ich nie uczy.
Są goście co burnout traktują tylko jako rytuał. Nie wiadomo po co, ale tak było na szkoleniu.
Taki kult cargo.

Jeżeli PM jest nawet nie techniczny, ale jest rozsądny, inteligentny i logicznie myśli, to będzie umiał używać sznura, oraz wiedział kiedy sznur nie jest rozwiązaniem.
Sam pracowałem z 2. PMami mającymi niby certy z prince2 i jakieś scrumowe, ale oni wiedzieli, że te certy są tylko dla prezesa żeby kasę dostać.
Jeden z nich był zupełnie nie techniczny, ale pomimo tego bardzo dobrze kierował zespołem i umiał rozwiązywać problemy.
Jeżeli były kontrowersje techniczne, to on wiedział o co kogo zapytać i pomimo tego, że sprawiał silne wrażenie, że nie rozumie odpowiedzi, to decyzje podejmował racjonalne i przeważnie słuszne.

Przyjmując terminologię Seligi, to ten PM był A-playerem.

0

Polecam w kontekście tych wszystkich rzeczy poczytać o Theory of Constraints - Goal 1 (book) .

0

Co do Agile (Scrum konkretnie) - jest daleki od idealu, ale sa projekty (w produktach chyba waterfall jest lepszy, ew. agilefall czyli mamy milestony fazy etc. ale prace rozkladamy na sprinty) gdzie to dziala i ma sens. Mozna pojsc w skrajnosc i spedzac wiekszosc czasu na spotkaniach, a mozna dostosowac do swoich potrzeb i nie wydluzac spotkan bardziej niz trzeba. Stand upy - nie lubie (bardzo), ale pracuje w zespole rozproszonym i dzieki temu ma sie synchronizacje co, jak, jakie sa priorytety co sie zmienilo etc. Grooming - najwazniejsze spotkanie, ustala sie o co tak naprawde chodzi w zadaniach, czasami tez estymuje. Planning - formalnosc po dobrym groomingu. Retrospektywa - bardzo wazne ale jesli robiona dobrze czyli ustalamy co nas boli i co mozemy zmienic z przypisaniem akcji do konretnych osob, dzieki temu z iteracji na iteracje mamy latwiej. Pracuje bezposrednio z klientem i jest to o wiele lepsze niz chaos ktory byl wczesniej. Zwlaszcza to ze jesli ustalilismy zakres sprintu i nagle trzeba cos na wczoraj, to ok bierzemy i robimy, ale wywalamy cos innego, w ten sposob odpadaja darmowe wieczory i weekendy.
Jeszcze jedna rzecz lepiej poswiecic pol godziny na spotkanie i dogadac co tak naprawde ma byc zrobione, po co to jest potrzebne (bo moze da sie zrobic latwiej/inaczej/lepiej?) niz spedzic tydzien i dostarczyc zupelnie cos innego niz bylo potrzebne.

0
WhiteLightning napisał(a):

Co do Agile (Scrum konkretnie) - jest daleki od idealu, ale sa projekty (w produktach chyba waterfall jest lepszy, ew. agilefall czyli mamy milestony fazy etc. ale prace rozkladamy na sprinty) gdzie to dziala i ma sens.

No Scrum poza projektami właśnie w ogóle sensu nie ma. A działać może tylko, jak się go używa z głową, a nie jak się wyśle PMa na szkolenie, z którego wyniesie jedynie książkę i zacznie wdrażać wszystkie rozdziały po kolei.

Nie wiem jakim cudem waterfall miałby być chociażby dobry w produktach, jak wtedy wygląda reakcja na potrzeby rynku? Czekanie, aż konkurencja przegoni? Taki model biznesowy to chyba tylko w firmach powstałych za dotacje z UE. :P

0

Scrum jest passe, teraz tylko Kanban :D (chociaż może nie jestem na czasie bo o Software Craftsmanship nawet nie słyszałem). Nawiasem mówiąć sama nazwa wskazuje, że to jakiś marketingowy bullshit.

1 użytkowników online, w tym zalogowanych: 0, gości: 1