Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32122 > unrolled thread

Agile / Scrum w korporacjach

Back to article view | Back to pl.comp.programming

Contents

  Agile / Scrum w korporacjach queequeg@trust.no1 (Queequeg) - 2018-12-17 11:43 +0000
    Re: Agile / Scrum w korporacjach Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-18 04:23 -0800
    Re: Agile / Scrum w korporacjach Wojciech Muła <wojtek.mula@gmail.com> - 2018-12-20 23:21 -0800
      Re: Agile / Scrum w korporacjach godek.maciek@gmail.com - 2018-12-21 01:45 -0800
        Re: Agile / Scrum w korporacjach Wojciech Muła <wojtek.mula@gmail.com> - 2018-12-21 03:36 -0800
          Re: Agile / Scrum w korporacjach Mateusz Bogusz <mabakay@o2.pl> - 2018-12-21 14:28 +0100
          Re: Agile / Scrum w korporacjach Adam M <amorawski@magna-power.com> - 2018-12-21 07:52 -0800
            Re: Agile / Scrum w korporacjach Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-01 12:20 -0800
        Re: Agile / Scrum w korporacjach Maciej Sobczak <see.my.homepage@gmail.com> - 2018-12-26 15:28 -0800
    Re: Agile / Scrum w korporacjach Mateusz Bogusz <mabakay@o2.pl> - 2018-12-31 11:24 +0100
      Re: Agile / Scrum w korporacjach Wojciech Muła <wojtek.mula@gmail.com> - 2019-01-01 12:34 -0800
        Re: Agile / Scrum w korporacjach Mateusz Bogusz <mabakay@o2.pl> - 2019-01-02 21:42 +0100

#32122 — Agile / Scrum w korporacjach

Czy obecnie w korporacjach metodologia Agile jest de facto standardem? 
Jeśli pracujecie w korpo -- stosujecie tę metodologię, łącznie z daily 
scrumami, sprint planningiem i sprint review? Jak to u was wygląda?

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

[toc] | [next] | [standalone]

#32123

> Czy obecnie w korporacjach metodologia Agile jest de facto standardem?

Agile jest tak szerokim pojęciem, że nie sposób tego nazwać standardem, nawet de facto. Wielu ludzi (w korporacjach) sądzi, że robi agile tylko przez to, że gadają codziennie na stojąco - trudno to jednak określić jako jakikolwiek standard. Niemniej, chyba wszędzie jest widoczna promocja tego podejścia i jeśli jest to robione dobrze, to dobrze.

> Jeśli pracujecie w korpo -- stosujecie tę metodologię, łącznie z daily 
> scrumami, sprint planningiem i sprint review? Jak to u was wygląda?

Pewnie wygląda tak, jak napisałeś. :-)

Ze strony EDC:

https://bulldogjob.pl/articles/750-agile-bez-spiny
https://edc.pl/aviation/agile-day-took-place-at-edc/

a nawet, jeśli ktoś chce w okolicy agile'a budować swoją karierę:

https://careers.edc.pl/available-jobs/adt-sat/

-- 
Maciej Sobczak

[toc] | [prev] | [next] | [standalone]

#32132

On Monday, December 17, 2018 at 12:43:28 PM UTC+1, Queequeg wrote:
> Czy obecnie w korporacjach metodologia Agile jest de facto standardem? 
> Jeśli pracujecie w korpo -- stosujecie tę metodologię, łącznie z daily 
> scrumami, sprint planningiem i sprint review? Jak to u was wygląda?

Agile to modny termin, coś jak Big Data albo "dynamiczny zespół".
Ze SCRUMa -- o który pytasz -- można robić szkolenia (płatne), zdobywać
certyfikaty danego obrządku SCRUMa (też płatne, chyba że w cenie
szkolenia). To się potem ładnie układa w Excelach i różni ludzie są
zadowoleni (szczególnie ci, którzy dostali kasę za szkolenia).

Praktyka jest taka, że wyciąga się z agile, to co działa w konkretnym
przypadku. I tak np. jestem w zespole, gdzie mamy daily, ale nie ma
zespołowego planowania, ani review, są tylko retrospektywy. Zamiast
review są sesje demo, gdy jest co pokazać użytkownikom. Bo tak jest
efektywniej.

w.

[toc] | [prev] | [next] | [standalone]

#32133

W dniu piątek, 21 grudnia 2018 08:21:37 UTC+1 użytkownik Wojciech Muła napisał:
> On Monday, December 17, 2018 at 12:43:28 PM UTC+1, Queequeg wrote:
> > Czy obecnie w korporacjach metodologia Agile jest de facto standardem? 
> > Jeśli pracujecie w korpo -- stosujecie tę metodologię, łącznie z daily 
> > scrumami, sprint planningiem i sprint review? Jak to u was wygląda?
> 
> Agile to modny termin, coś jak Big Data albo "dynamiczny zespół".
> Ze SCRUMa -- o który pytasz -- można robić szkolenia (płatne), zdobywać
> certyfikaty danego obrządku SCRUMa (też płatne, chyba że w cenie
> szkolenia). To się potem ładnie układa w Excelach i różni ludzie są
> zadowoleni (szczególnie ci, którzy dostali kasę za szkolenia).
> 
> Praktyka jest taka, że wyciąga się z agile, to co działa w konkretnym
> przypadku. I tak np. jestem w zespole, gdzie mamy daily, ale nie ma
> zespołowego planowania, ani review, są tylko retrospektywy. Zamiast
> review są sesje demo, gdy jest co pokazać użytkownikom. Bo tak jest
> efektywniej.

Słowo "agile" oznacza w języku angielskim "zwinny".
Słowo "scrum" oznacza "przepychankę" i jest zapożyczeniem
od formy rozgrzewki w futbolu amerykańskim.
Odpowiednikiem słowa "review" w języku polskim jest "recenzja".

Czasem, kiedy brakuje odpowiedniego tłumaczenia, używa się
oryginalnego słowa, ale nie widzę żadnego reasonu żeby robić
tak w tym przypadku.

Kurczowe trzymanie się oryginalnego słowa w sytuacji, kiedy
istnieją dobrze utarte polskie odpowiedniki, które są całkowicie
równoważne znaczeniowo, może świadczyć o wielu rzeczach,
ale na pewno nie o zwinności.

Być może usprawiedliwieniem dla używania słowa "agile" jest
chęć podkreślenia odniesienia do "agile manifesto", ale nawet
on jest przetłumaczony na język polski jako "manifest
programowania zwinnego":

http://agilemanifesto.org/iso/pl/manifesto.html

Również określenie "metodologia agile" jest oksymoronem.
Albo "metodologia" (czyli trzymanie się "procesów i narzędzi")
albo "programowanie zwinne" (czyli stawianie ludzi i interakcji
ponad procesy i narzędzia).

[toc] | [prev] | [next] | [standalone]

#32134

On Friday, December 21, 2018 at 10:45:50 AM UTC+1, godek....@gmail.com wrote:
> Słowo "agile" oznacza w języku angielskim "zwinny".

I jest przymiotnikiem, a Queequeg użył go jako rzeczownika --
właściwie nazwy własnej.

> Słowo "scrum" oznacza "przepychankę" i jest zapożyczeniem
> od formy rozgrzewki w futbolu amerykańskim.

A nie "młyn"? Bo stąd już prosta droga do "mistrza młyna". :)

> Odpowiednikiem słowa "review" w języku polskim jest "recenzja".

Good to know. Więc mówisz "recenzja sprintu"? To byłbyś
pierwszą osobą, która używa takiego określenia.

w.

[toc] | [prev] | [next] | [standalone]

#32135

> Good to know. Więc mówisz "recenzja sprintu"? To byłbyś
> pierwszą osobą, która używa takiego określenia.

Może "recenzja zmagań"? Brzmi już sensowniej :-)

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [next] | [standalone]

#32136

On Friday, December 21, 2018 at 6:36:39 AM UTC-5, Wojciech Muła wrote:
> On Friday, December 21, 2018 at 10:45:50 AM UTC+1, godek....@gmail.com wrote:
> > Słowo "agile" oznacza w języku angielskim "zwinny".
> 
> I jest przymiotnikiem, a Queequeg użył go jako rzeczownika --
> właściwie nazwy własnej.
> 
> > Słowo "scrum" oznacza "przepychankę" i jest zapożyczeniem
> > od formy rozgrzewki w futbolu amerykańskim.
> 
> A nie "młyn"? Bo stąd już prosta droga do "mistrza młyna". :)

Podoba mi się ;-D - stąd już prosta droga do wiatropędu trójpniakowego i zwisu męskiego ozdobnego.
> 
> > Odpowiednikiem słowa "review" w języku polskim jest "recenzja".
> 
> Good to know. Więc mówisz "recenzja sprintu"? To byłbyś
> pierwszą osobą, która używa takiego określenia.
> 
> w.

[toc] | [prev] | [next] | [standalone]

#32199

On Friday, December 21, 2018 at 4:52:01 PM UTC+1, Adam M wrote:
> > A nie "młyn"? Bo stąd już prosta droga do "mistrza młyna". :)
> 
> Podoba mi się ;-D - stąd już prosta droga do wiatropędu trójpniakowego i zwisu męskiego ozdobnego.

Zwis męski to znam, ale wiatropęd trójpniakowy? Za trudne. :)

w.

[toc] | [prev] | [next] | [standalone]

#32159

> Odpowiednikiem słowa "review" w języku polskim jest "recenzja".

Przegląd. W tym kontekście przegląd. Albo inspekcja.

Recenzja to wyrażenie swojej osobistej opinii, np. na temat filmu albo książki. Natomiast w technice robi się przeglądy i inspekcje. Inspekcje bardziej dotyczą czegoś fizycznego (np. można zrobić inspekcję komory spalania albo innego łożyska), natomiast przeglądy dotyczą też metod, osiągnięć, wykonanej pracy, itd.

Wtedy sprint review to przegląd przyrostu produktu. Tak, brzmi to kwadratowo, dlatego normalni ludzie mówią sprint review.

> Czasem, kiedy brakuje odpowiedniego tłumaczenia

Jak widać, wcale nie musi być zgody co do tego, jakie tłumaczenie jest odpowiednie.

> Być może usprawiedliwieniem dla używania słowa "agile" jest
> chęć podkreślenia odniesienia do "agile manifesto"

Nie. Agile to słowo. Agile to takie słowo jak np. snowboard albo rower. Tak, istnieje taki utarty wyraz, jak bicykl, ale akurat ja mam rower. Biorąc pod uwagę coraz większą szybkość zachodzących zmian (w każdej dziedzinie), można uznać, że agile to jest polskie słowo, tak jak snowboard albo rower.

> Również określenie "metodologia agile" jest oksymoronem.

Nie, nie jest. Niektórzy uważają, że agile to brak metodologii albo procesu, ale prowadzi to do sytuacji, kiedy firma niemająca procesu usprawiedliwia swój brak procesu hasłem "agile" a potem obwinia agile za porażkę projektu.

> "programowanie zwinne" (czyli stawianie ludzi i interakcji
> ponad procesy i narzędzia).

Etam. Interakcje są tym procesem, a rytuały (np. scrumowe) są tymi narzędziami.

Widać to wyraźnie, gdy projekt poleciał w krzaki, management obwinia agile, a obrońcy agile twierdzą, że to nie wina agile, po prostu ktoś ten agile źle praktykował. Takie tłumaczenia wskazują na istnienie metodologii - bo gdyby nie istniała, to by nie można było jej źle stosować.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#32191

A jak to wygląda u Was? - jeżeli ktoś stosuje.

U mnie, "sprinty" są tygodniowe. W poniedziałki i środy punktujemy 
zadania w "backlogu" (wszyscy, czyt. 20 programistów, punktacja: 1, 3, 
5, 8, 13, 20). W czwartki układamy kolejnego "sprinta", gdzie zawsze coś 
zostaje na koniec tygodnia i w poniedziałek rano jest przerzucane z 
poprzedniego do kontynuacji. Ogólna zasada głosi, że jak oddajesz 
zadanie do testów, to zanim weźmiesz kolejne to przetestuj chociaż jedno 
inne oddane do testów - średnio to działa, bo znalezienie błędu powoduje 
cofnięcie zadania do zrobienia, którym jego autor zajmie się po 
skończeniu aktualnego zadania więc coś co było oddane do sprinta, często 
jest "wykonane w miarę działające" trzy tygodnie później.

Ja już wolałem waterfalla z harmonogramem.

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [next] | [standalone]

#32200

On Monday, December 31, 2018 at 11:24:46 AM UTC+1, Mateusz Bogusz wrote:
> U mnie, "sprinty" są tygodniowe. W poniedziałki i środy punktujemy 
> zadania w "backlogu" (wszyscy, czyt. 20 programistów, punktacja: 1, 3, 
> 5, 8, 13, 20).

Zespół scrumowy ma 20 programistów?

> W czwartki układamy kolejnego "sprinta", gdzie zawsze coś zostaje na
> koniec tygodnia i w poniedziałek rano jest przerzucane z 
> poprzedniego do kontynuacji.

Ile czasu wam to wszystko około-sprintowe zajmuje? Z tego co piszesz
macie w 5-dniowym sprincie trzy dni z planowaniem -- to wygląda na
potężny narzut czasowy. (Nie mówiąc, że spotkania zwykle rozwalają
cały dzień.)

> Ogólna zasada głosi, że jak oddajesz 
> zadanie do testów, to zanim weźmiesz kolejne to przetestuj chociaż jedno 
> inne oddane do testów - średnio to działa, bo znalezienie błędu powoduje 
> cofnięcie zadania do zrobienia, którym jego autor zajmie się po 
> skończeniu aktualnego zadania więc coś co było oddane do sprinta, często 
> jest "wykonane w miarę działające" trzy tygodnie później.

Przecież w ten sposób sami strzelacie sobie w głowę. :)
Priorytetem powinno być zadanie rozpoczęte wcześniej.

BTW testujecie ręcznie?

w.

[toc] | [prev] | [next] | [standalone]

#32222

>> U mnie, "sprinty" są tygodniowe. W poniedziałki i środy punktujemy
>> zadania w "backlogu" (wszyscy, czyt. 20 programistów, punktacja: 1, 3,
>> 5, 8, 13, 20).
> Zespół scrumowy ma 20 programistów?

Nikt nie używa terminu scrum, tylko że pracujemy "zwinnie". Projekt ma 
oczywiście pod projekty, ale założenie jest takie żeby każdy "umoczył 
palec wszędzie" (technologicznie realne, najwyżej się "douczy, to będzie 
na plus w razie urlopów") z czego ma wynikać "ogólne zrozumienie 
projektu i potrzeb kolegów w zespole". Także na spotkaniu część jest 
biznesem dla innych, potem w innym obszarze na odwrót...

>> W czwartki układamy kolejnego "sprinta", gdzie zawsze coś zostaje na
>> koniec tygodnia i w poniedziałek rano jest przerzucane z
>> poprzedniego do kontynuacji.
> Ile czasu wam to wszystko około-sprintowe zajmuje? Z tego co piszesz
> macie w 5-dniowym sprincie trzy dni z planowaniem -- to wygląda na
> potężny narzut czasowy. (Nie mówiąc, że spotkania zwykle rozwalają
> cały dzień.)

Za dużo jak dla mnie.

>> Ogólna zasada głosi, że jak oddajesz
>> zadanie do testów, to zanim weźmiesz kolejne to przetestuj chociaż jedno
>> inne oddane do testów - średnio to działa, bo znalezienie błędu powoduje
>> cofnięcie zadania do zrobienia, którym jego autor zajmie się po
>> skończeniu aktualnego zadania więc coś co było oddane do sprinta, często
>> jest "wykonane w miarę działające" trzy tygodnie później.
> Przecież w ten sposób sami strzelacie sobie w głowę.:)
> Priorytetem powinno być zadanie rozpoczęte wcześniej.

Masz na myśli, że jak tylko zrobione wcześniej zadanie zostanie 
"odbite", to traktować to tak samo jak wysypany build w CI?

> BTW testujecie ręcznie?

Jest ciągła integrację i deployment. Kilkadziesiąt jednostkowych i kilka 
integracyjnych, ale wiadomo że to kropla do potrzeb.

Po nich i tak jest etap testu funkcjonalnego przez kolegę, który nie 
pisał tego zadania + etap code review (przez osobę trzecią) = można 
zintegrować kod na gałąź stabilną. Największy problem jest z "ciągłym 
dostarczaniem".

-- 
Pozdrawiam,
Mateusz Bogusz

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.programming

csiph-web