Która metodologia programowania byłaby dla nas odpowiednia?

Niestety, ktoś nauczył naszego wyższego kierownictwa słowa „Agile” i teraz chce, abyśmy się do niego zbliżyli. Mam peryferyjne rozumienie zwinności (w zasadzie), ale nigdy nie korzystałem z niej w praktyce. Z tego co wiem, nie będzie dobrze pasować do naszej organizacji. W tej chwili rzeczy są dość grungeowe. Oto jak to jest;

Jesteśmy bardzo małym zespołem - dwóch programistów, jeden DBA, jeden projektant. Firma, w której pracuję, zarabia nieproporcjonalnie duże pieniądze w stosunku do swojej wielkości, a prawie 95% z nich to czysta sprzedaż internetowa.

Z perspektywy rozwoju jesteśmy poddawani wielu inwazjom na biurko w typowy dzień (jesteśmy zarówno wsparciem technicznym, jak i deweloperem), praca może regularnie po prostu wypadać z nieba w mgnieniu oka, jeśli członek zespołu sprzedaży obiecuje coś komuś . Podejmujemy się również większych projektów, które są koszmarem z ciągłymi zakłóceniami. Niektórzy z nas zaczynają odrywać włosy! Plany projektów są opracowywane przez kierowników nietechnicznych w arkuszach kalkulacyjnych Excela, w których próbują rozbić zadanie na małe zdania, które mogą zrozumieć i umieszczają datę obok każdego z nich. Te daty są zawsze okropnie nierealne i często pomijane, a nasze spotkania (które odbywamy co tydzień) są regularnie wypełniane niezręcznymi chwilami z pytaniami „dlaczego jeszcze tego nie zrobiono”.

Jestem prawie pewien, że Agile nie jest dla nas tym. Teraz, biorąc pod uwagę, że (i próbowałem) ta firma nie zmieni swoich działań , a tylko zespół deweloperów jest skłonny to zmienić, czy istnieje metodologia rozwoju, którą moglibyśmy zastosować, która jest odpowiednia dla uratowania nam zdrowia psychicznego?

Zwinność została zaprojektowana tak, aby rozwiązać wiele problemów, które masz. Jeśli kierownictwo naprawdę się wkupiło i nie wypaczy procesu, można zauważyć znaczną poprawę. Pozwól mi rozwiązać twoje problemy punkt po punkcie. Mam doświadczenie w scrumie, więc będę mówić z tego punktu widzenia, ale jestem pewien, że inne implementacje mają podobne zalety.

• praca spadająca z nieba Te historie są umieszczane na dole zaległości, dopóki właściciel produktu i zespół nie spotkają się, aby zgodzić się na jego zwiększenie. Jego priorytet ustala się w stosunku do wszystkich innych zobowiązań twojego zespołu, a priorytet ten jest widoczny dla każdego interesariusza, który jest zainteresowany spojrzeniem. Dodanie nowej funkcji w trakcie sprintu powinno być niezwykle rzadkie, a tylko błędy o najwyższym priorytecie powinny mieć możliwość przerwania sprintu. To zdumiewające, jak wiele „sytuacji kryzysowych” może czekać do końca przyszłego tygodnia, kiedy oczekuje się tego regularnie.
• podejmowanie większych projektów Zobaczysz, w jaki sposób priorytety krótkoterminowe wpływają na Twoje projekty długoterminowe. Jeśli ludzie będą nieustannie przenosić historie użytkowników przed Twoimi długoterminowymi projektami, jest to w porządku, ale aby podjąć tę decyzję, każdy będzie wiedział, jaki będzie to miało wpływ na harmonogram długoterminowego projektu.
• plany projektów są opracowywane przez menedżerów nietechnicznych Historie użytkowników powinny być pisane z nietechnicznego punktu widzenia, ale zespół scrumowy powinien być uprawniony do dokonywania szacunków i określania szczegółów wdrożenia.
• daty są strasznie nierealne Twój zespół obsługuje wszystkie prognozy, ponieważ to ty wiesz, co robisz. Jeśli te szacunki są nie do przyjęcia dla firmy, muszą zdecydować, w jaki sposób ustawić priorytety funkcji. Jeśli potrzebują więcej pracy niż jesteś w stanie znieść, potrzeba zatrudnienia większej liczby osób będzie wyraźnie widoczna.
• daty są często pomijane Po pierwsze, twoje prognozy będą bardziej realistyczne, co powinno pomóc. Ponadto gryziesz mniejsze fragmenty i faktycznie je kończysz , co pomaga firmie poczuć się, jakbyś wyprodukował coś przydatnego, nawet jeśli nie jest kompletny.
• spotkania wypełnione niezręcznymi momentami Agile ma lepszą widoczność i znacznie szybszy cykl opinii, z dużym zaangażowaniem właściciela produktu. Twoje problemy z blokowaniem i przyczyny opóźnień nie powinny być zaskoczeniem.
• także zapewnianie wsparcia technicznego Wbrew powszechnemu przekonaniu, zwinny nie jest niezgodny z podzielonym harmonogramem. Czynniki Scrum wpływają na twoje zakłócenia w prędkości twojego zespołu. Jeśli zwykle spędzasz połowę czasu na pomocy technicznej, po prostu będziesz mieć połowę prędkości.

Zorientowanie i sprzedaż muszą uświadomić sobie, że zwinność nie jest sposobem na ściślejszą kontrolę nad zespołem programistów, daje zespołowi większą autonomię w robieniu tego, w czym jest dobry, pomagając firmie realistycznie rozważyć wszystkie jej priorytety przy przydzielaniu pracy do drużyna.

Powiedziałbym, że skorzystaj z kaprysów waszego kierownictwa! Wygląda na to, że wyświadczają ci przysługę i dają ci siłę, by ulepszyć twoje metody pracy.

Powiedz im OK, że osiągniemy zwinność, co wymaga między innymi:

• oddzielenie rozwoju i wsparcia
• proces formalnego zbierania wymagań - pod kontrolą zespołu IT. „Historie” itp. Brzmią bardzo niejasno - ale w rzeczywistości jest to „formalna” metoda ubrana tak, by wyglądać nieformalnie.
• harmonogram jest kontrolowany przez zespół IT.

Jeśli nie zaakceptują tego, powiedz im, że nie możesz zwinnie.

Agile nie jest metodologią programowania, Agile jest metodologią zarządzania projektami. Jeśli kierownictwo naprawdę chce, abyś wypróbował nowe hasło, które znaleźli, musi być w stanie zrozumieć, że metoda Agile zaczyna się od góry i obejmuje zarządzanie na każdym etapie. Jeśli chcesz dać im twardą dawkę rzeczywistości, może zorganizuj 30-minutową prezentację Powerpoint na temat Agile, aby dać im trochę edukacji. Menedżerowie uwielbiają Powerpoint.

Jeśli jednak, jak mówisz, zespół deweloperów jest jedyną osobą chętną do zmiany, żadna metodologia rozwoju nie będzie w stanie ci pomóc. Bez złagodzenia pozostałych obowiązków nadal będą występować przerwy i będziesz proszony o dotrzymanie terminów, których po prostu nie możesz dotrzymać.

Radzę w tym scenariuszu, aby edukować, a nie krytykować zarządzanie, jak naprawdę jest na pierwszej linii frontu.

Żadna metodologia opracowywania oprogramowania i zarządzania projektami nie może pomóc w organizacji, w której sprzedawcy dyktują codzienny harmonogram. Jak masz zarządzać projektem w tak chaotycznym i rozproszonym tygodniu pracy?

Tak wielu menedżerów wyższego szczebla dostrzega wartość Agile i chce z tego korzyści, ale prawie nigdy nie są w stanie wprowadzić wewnętrznych zmian niezbędnych do zapewnienia pomyślnego przejścia. Jedyne odnoszące sukcesy sklepy Agile, o których wiedziałem, zaczęły się w ten sposób. Nie mogę sobie przypomnieć ani jednego przykładu z mojego doświadczenia zawodowego, gdy sklep z oprogramowaniem do zarządzania sprzedażą lub wodospadem przeprowadzał ten ruch, ponieważ wymaga to fundamentalnej zmiany w kulturze.

Czy ta zmiana kultury jest możliwa? Tak, ale w twoim przypadku prawie na pewno nie.

Zmiana kultury jest zwykle konieczna przez konkurenta, który zagraża istnieniu firmy lub sytuacji marki lub break lub innej podobnej sytuacji w celu uzasadnienia ponownej organizacji. W twojej sytuacji Twoja firma znajduje się na drugim końcu spektrum, gdzie pieniądze są teraz łatwe i wszyscy przytyją.

Firmy NIGDY nie zmieniają się od wewnątrz, gdy pieniądze są łatwe. Dlaczego mieliby odnieść sukces pomimo niepowodzeń w tworzeniu oprogramowania, a nie z powodu sukcesów w tworzeniu oprogramowania.

Moja ostatnia rada jest taka, że ​​gdybym był tobą, szukałbym czegoś lepszego. Ludzie tutaj mają świetną radę, ale widziałem tę piosenkę i tańczyłem wcześniej i po prostu to nie działa w twojej sytuacji.

spójrz na extremeprogramming.org - XP jest formą Agile z łatwo zrozumiałymi aspektami, które możesz wybrać i wybrać z koszyka; bardzo dobre miejsce na początek

zobowiązanie klienta, aby nie zmieniać zdania podczas rozmowy, byłoby dobrym początkiem dla twojego środowiska, od samego jego dźwięku ;-)

Jeśli weźmie się pod uwagę krajobraz metodologii, zarówno tradycyjnych, jak i współczesnych, zdamy sobie sprawę, że „zwinny” jest bardziej „anty-metodologią” niż metodologią. Wzorce mają na celu przedstawienie „najlepszego przypadku” rozwiązania danego problemu w określonym kontekście. Próby bezpośredniego naruszenia takiego rozwiązania lub wzorca są na ogół określane jako „anty-wzorce” lub praktyki o gorszym przypadku. Podobnie, podczas gdy prawdziwe metodologie opracowywania oprogramowania próbują zalecać najlepsze praktyki tworzenia rozwiązań, „Agile” (Scrum, XP itp.) Próbują bezpośrednio naruszać dowolną strukturę w procesie tworzenia oprogramowania, na korzyść przypadkowego, chaotycznego podejście - które (ostatnio) wydaje się również wymagać oklasków od (naiwnych) gapiów.

To powiedziawszy, należy pamiętać o kontekście, w którym powstała filozofia Agile. Chociaż w tym czasie istniały wyrafinowane metody iteracyjne (np. Unified Process), podstawową metodologią było wciąż stare podejście typu „wodospad”, które określało „najlepszą praktykę” pełnej analizy wymagań, następnie kompletnego projektu, a następnie opracowania / kodowania rozwiązania, a następnie wdrożenia rozwiązanie. Najwyraźniej to inżynierskie podejście do tworzenia oprogramowania było niewskazane - i spowodowało mnóstwo papierkowej roboty przed (a czasem nawet nigdy) zobaczeniem wykonalnego rozwiązania.

Jednak nadal nie gwarantuje to wyrzucenia dziecka z kąpielą, tak jak w przypadku przywoływaczy Agile. Podejście zwinne prawie wymusza bezpośrednią negację wszystkiego, co było wcześniej używane - z wyjątkiem może faktycznego kodowania rozwiązania. Oczywiście jest to oznaką ograniczonego wglądu ze strony jej twórców, a może po prostu przypadek „nie ma tak ślepych, jak ci, którzy nie chcą widzieć”.

Niemniej jednak zaletą zwinności jest to, że zachęca do usprawnienia procesów i koncentruje się na kodzie wykonywalnym - co jest nieuchronnie twoim ostatecznym rezultatem.

TERAZ, aby bardziej bezpośrednio odpowiedzieć na twoje pytanie:

Biorąc pod uwagę przegląd środowiska, sugeruję najpierw wybrać implementację Agile (tj. Scrum, XP itp.). Następnie dostosuj podejście do swojego środowiska, określając jasny proces pracy zespołu, np .:

• Otrzymuj żądanie od użytkowników;

• Priorytetyzuj żądania użytkowników;

• Ocenić wpływ ulepszenia na istniejący system (może podczas codziennych / cotygodniowych spotkań stand-up);

• Oszacuj czas opracowywania każdego rozszerzenia - i przekaż je z powrotem różnym żądającym użytkownikom;

• Wykonaj rzeczywiste ulepszenia w istniejącym systemie (tj. Kodowanie).

• Przeprowadź testy użytkowników - i uzyskaj od użytkowników oświadczenie (np. E-mailem), że żądane zmiany zostały pomyślnie wdrożone.

To powinno zapewnić pewną strukturę (i porządek), a jednocześnie zachować pozory podejścia zwinnego.

Mając powyższe na uwadze, pamiętaj, że stara angielska postać mowy „Zwinny jak małpa” nie została wymyślona bez powodu!

Powiedziałbym, że potrzebujesz metodologii takiej jak Agile, która jest niezbędna dla Twojego zespołu. Ponieważ Twoja firma jest tak zdezorganizowana, musisz być lepiej zorganizowany w ramach własnego zespołu programistów. Nie sądzę jednak, żeby twoi nietechniczni kierownicy mieli z tym coś wspólnego.

Jeśli zamierzasz naciskać na sprzedawców i domagać się realistycznych terminów, musisz to uzasadnić zorganizowanymi planami.

Również na osobnej notatce, jeśli przyjdą do ciebie z szacunkami bez konsultacji technicznych, po prostu odmów im.

Być może skupienie się na aspektach przyrostowych / iteracyjnych jest tym, co zarówno Twój zespół, jak i zainteresowani interesariusze muszą być w stanie dostarczać regularnie i konsekwentnie. Z czasem zespół sprzedażowy i kierownictwo zyskają wiarę w to, że kiedy złożą nową prośbę o nowe funkcje, mogą być pewni, że Twój zespół dostarczy w odpowiednim czasie.

Oczywiście musisz zainwestować w testy jednostkowe / systemowe / regresyjne, automatyczne kompilacje, karmienie psów itp., Aby się tam dostać, jeśli jeszcze tam nie jesteś.

Najpierw sugeruję zebranie niektórych danych. Usiądź w ciszy i dowiedz się, czym tak naprawdę jest status quo - jak się to robi. Jeśli kierownictwo zależy na wdrożeniu czegoś, co można nazwać zwinnym, to wymyśl coś, co zadziała dla Twojego zespołu, przygotuj dokument, uderz „Agile” w nazwę i gotowe. Należy pamiętać, że jedyną rzeczą, którą naprawdę wiedzą o zwinności, jest słowo i niejasne skojarzenie z szybkością jego zwykłej definicji w języku angielskim. Dlatego opowiadam się za tym, aby Twój zespół zajął się problemem, znalazł smak, który Ci odpowiada, a następnie przedstawił go kierownictwu w sposób zwinny (tm). W przeciwnym razie jakiś PHB podniesie książkę i spróbuje wpasować kwadratowy kołek w okrągły otwór i nikt nie będzie szczęśliwy.

Jeśli wybierzesz „czystą” formę zwinną, może to być trudne, ponieważ twój zespół musi również spełniać rolę wspierającą. Spójrzmy prawdzie w oczy, szefowi może być trudno zaakceptować członków zespołu odpowiadających na prośby działu pomocy technicznej, mówiąc: „pozwól, że utworzę element zaległości, przejdę do tego w ciągu tygodni (przed końcem sprintu)”.

Największą przeszkodą są pieniądze. Jeśli wszystko jest zielone sos, o wiele trudniej jest powiedzieć, że coś jest nie tak i musi się zmienić.

Powodzenia.

Przeciwnie, wydaje mi się, że metoda Agile jest dokładnie tym, czego potrzebujesz, aby poradzić sobie z przekroczonymi terminami, nierealistycznymi oczekiwaniami i źle zaplanowanymi projektami.

Kierownictwo wskazało, że jest zainteresowane tym nowym słowem Buzz. Najprawdopodobniej będą chcieli go wykorzystać, aby podburzyć marketing Twoich produktów. niekoniecznie jest to zła rzecz, ale trzeba bardzo ostrożnie zarządzać, jeśli chcesz, aby metoda Agile działała dla Ciebie.

Połowa bitwy to wpisowe z zarządzania. Utrzymanie ich wrażliwości na samą ideę Agile to większość bitwy. Resztą jest upewnienie się, że ich oczekiwania są spełnione, aby nadal chcieli, abyś był zwinny, i aby uniknąć rozczarowania, kiedy i jeśli Twoi menedżerowie czują się tak, jakby ich kontrola nad zarządzaniem projektami w dużej mierze wymyka się im z palców.

Zanim Twoja firma zdecyduje cokolwiek, polecam wsiadanie do trenera Agile na półdniowe seminarium i warsztaty. Spraw, abyście wszyscy myśleli jako zespół - zarówno menadżerowie, jak i programiści - o tym, co jest w Agile, które według ciebie będzie dla ciebie działać, a co nie. Z drugiej strony, jeśli kierownictwo ufa osądowi, musisz bardzo dobrze zapoznać się z szeregiem zwinnych praktyk i metod oraz stworzyć własne lub seminarium. Osobiście chciałbym dostać się do doświadczonego trenera, abyś nie marnował dużo czasu i aby utrzymał tempo. W międzyczasie weź kopię kilku dobrych książek Agile jako referencje, przeczytaj je dokładnie, ale zostaw także wisi na biurku, gdzie kierownictwo może je zobaczyć. Psychologia podprogowa może zdziałać cuda w sytuacji takiej jak ta, którą opisałeś.

Poleciłbym przynajmniej przeczytać następujące:

• Lean Software Development - Mary & Tom Poppendieck
• Zwinne tworzenie oprogramowania - Robert C. Martin

i dla dodatkowego uznania (ponieważ uważam, że jest to świetny towarzysz dla innych książek, o których wspomniałem):

• Czysty kod - Robert C. Martin