Pewna krótka rozmowa
Czytelnik: Dzień dobry : ) Co sądzi Pan o tym, żeby publikować swoje codzienne wpisy także po angielsku/niemiecku ? Myślę, że w polskim Internecie ma już Pan duże zasięgi bo dosyć często wyświetlają mi się ciekawostki od Pana, szkoda by było, żeby ten potencjał zmarnował się tylko na klientów z Polski. Co sądzi Pan o tym, żeby publikować we wpisach typy projektów/produktów, gdzie:
- agile będzie lepszy od super-analityka-projektanta
- agile będzie gorszy
Jarosław Żeliński: Kilka wyjaśnień:
- agile jest formalnie definiowane jako praca zespołowa koderów i użytkowników, to podejście jest znane z gier i małych produktów na rynek konsumencki, nie ma tu etapu analizy i projektowania
- agile w j. angielskim to “zwinny, sprawny”, i jest słowo to, w angielskojęzycznej literaturze jest dość powszechnie używane w tym ogólnym znaczeniu
- obrzędy plemienne SCRUM i Kanban nie mają nic wspólnego z inżynierią oprogramowania jako taką, dotyczą po prostu sprawnej pracy z realizacja projektu mającego zakres, etapy, pośrednie produkty itp.,
Skąd te produkty? To komponenty dostarczanych systemów. I teraz problemy jaki widzę u klientów i dyskutantów:
- traktowanie systemów biznesowych jak prostych systemów konsumenckich lub start-up’ów.
- przykrywanie braku pomysłu na system mnożeniem ról i spotkaniami z przyszłymi użytkownikami w celu przerzucenia na nich 100% odpowiedzialności za efekty.
Z perspektywy tworzenia/dostarczania oprogramowania mamy dwie role:
- Software engineers evaluate client or company needs in conjunction with those of the user and methodically conceptualize a systematic solution.
- Programmers write code and debug errors in programs and software based on instructions from software engineers. They are involved in a single stage within the development lifecycle and concentrate on one component at a time.
To czy nazwiemy tego pierwszego analitykiem, czy inżynierem systemów, nie ma znaczenia, znaczenie ma to jak zdefiniowano jego role i metody (patrz linkowany artykuł). Ww. agile to po prostu usunięcie z projektu roli 1. i rozkmina problemu w gronie 2. To sie nie ma prawa udać w rozsądnym czasie i kosztach (w porównaniu z zaangażowaniem roli 1. Tak wiéc jeżeli projekt sie kwalifikuje do kategorii “mały system konsumencki” to można próbować eliminować, rolę 1. w żadnym innym przypadku nie … A to jak to nazwiemy nie ma znaczenia, agile od lat jest krytykowanym i szkodliwym buzzwordem, a dla koderów metodą pozbywania się projektantów (rola 1.) , Dlaczego? Tu zacytuje klientów, są zgodni: w celu (świadomego lub nie) maksymalizowania pracochłonności projektów.
Czytelnik: A kiedy mamy średniej wielkości projekt/produkt, wg jakich kryteriów można stwierdzić, czy jest bardziej małym systemem konsumenckim, czy systemem biznesowym?
Jarosław Żeliński: Nie ma prostej granicy, ale osobiście zgadzam się z dość prostą definicją: tam gdzie nie ma rzeczy oczywistych należy analizować by zrozumieć a potem zaprojektować aplikację, należy też zrozumieć komu ona tak na prawdę służy (np. komu służy system rejestracji czasu pracy, z kim należy uzgodnić mechanizm jego działania?). Np. MIRO czy Slack to konsumenckie produkty, ale już nawet prosty task manager nie koniecznie. Systemy dla biznesu raczej nigdy, bo mamy to informacje, jej utrwalanie w postaci danych, i mniej lub bardziej wyrafinowane przetwarzanie. Wkraczają takie pojęcia jak ontologie, dokumenty, reguły biznesowe, algorytmy. To jest potrzebna rola 1. inżynier, a potem rola 2. koder.
Co się mówi i pisze na świecie
Warto wiedzieć, że ten problem nie jest nowy:
Ta prezentacja została nagrana podczas GOTO Aarhus 2012. http://gotocon.com, wygłosiła ją Gabrielle Benefield. Streszczenie:
Nie chodzi o budowanie właściwego produktu, chodzi o budowanie właściwego produktu. Zespoły Scrum i Agile mogą działać szybko i dostarczać wysokiej jakości kod, ale produkt wciąż zawodzi. Kiedy tak się dzieje, ludzie rozglądają się za nowym frameworkiem, tylko po to, by zobaczyć, że on również zawodzi. Zamiast tworzyć więcej kodu szybciej, musimy przyjrzeć się systemowym przyczynom niepowodzeń. Są one związane z brakiem dogłębnego zrozumienia przyczyn i skutków problemu, który ma zostać rozwiązany lub możliwości, które mają zostać wykorzystane, niejasnymi i nieokreślonymi celami oraz brakiem potwierdzonego uczenia się poprzez szybkie testowanie przez użytkowników”. Nie ma znaczenia, czy korzystasz z tradycyjnych metod, scrum czy lean, jeśli nie wyznaczysz właściwego kierunku, nie będzie miało znaczenia, z którego frameworka korzystasz.
Inny ciekawy referat:
Zach (autor referatu) jest niezależnym konsultantem, który niedawno opublikował prowokacyjny artykuł pt: “The Subversion of Agile: Agile is a Cancer” (“Obalenie Agile: Agile to rak”). Omówiliśmy jego post, rozmawialiśmy o tym, czym jest rak w społeczności, który należy usunąć, o postach innych członków społeczności na temat “śmierci Agile”.
Na zakończenie ciekawy wpis na LinkedIn, jego początek:
Czy Twój projekt cierpi, jest ranny lub umiera? Czy używasz wszystkich modnych słów, technik zarządzania i uroczych małych karteczek samoprzylepnych, ale nadal czujesz się poza kursem? Czy ukrywasz się na spotkaniach “strategicznych”, ale w głębi duszy wiesz, że nie masz pojęcia, jak uratować ten tonący statek? Czy używasz frazesów takich jak “Pracuj mądrzej, a nie ciężej” jako ostatniej deski ratunku, aby wydawać się autorytatywnym?
Po seminarium i certyfikacji poczułeś, że możesz podbić świat i że twoja amorficzna rola “menedżera” ma teraz kierunek. Co poszło nie tak?
To, co poszło nie tak, to fakt, że sprzedano ci “Techniki zarządzania i rozwoju”, a tak naprawdę otrzymałeś techniki planowania i śledzenia.
To, że prowadzisz spotkanie, nie oznacza, że prowadzisz projekt. Problemem Agile i Scrum nie są same techniki, których część może być przydatna. Problemem jest to, że metody te udają zarządzanie, pozostawiając prawdziwą rolę zarządzania projektem wolną (https://www.linkedin.com/pulse/how-agile-scrum-destroying-your-project-gabriel-valles/)
