To naprawdę nie ma wiele wspólnego z Agile, ani nawet z inżynierią oprogramowania. Dotyczy to po prostu każdej firmy w dowolnym biznesie: musisz przeznaczyć czas na szkolenie. Kropka.
Agile ma ideę „trwałego tempa”, co oznacza, że w żadnym momencie zespół nie powinien pracować ciężej niż mógł wytrzymać przez czas nieokreślony. Tj. Brak „czasu crunch”. Trzeba to również uszanować poprzez szkolenie. Tak więc, zrównoważone tempo dla twojego zespołu to „nie więcej niż 5 godzin bez przerwy, nie więcej niż 9 godzin dziennie, nie więcej niż 40 godzin tygodniowo”, a ty chcesz zapewnić 10% czasu na trening, wtedy musisz zaplanować swoje projekty na 36 godzin tygodni.
Ale znowu, to nie ma nic wspólnego z Agile, to tylko zdrowy rozsądek i matematyka w szkole podstawowej.
Osobiście uważam, że coś w rodzaju zwolnienia na pół godziny dziennie, pół dnia na tydzień i jeden pełny tydzień na kwartał pozwoliłoby zespołowi na zdobycie kawałków wiedzy różnej wielkości szybko i w stałym tempie.
Istnieją również pewne zwinne praktyki, które pomagają w transferze wiedzy, tj. Niwelują różnice w poziomie wiedzy między zespołami:
- codzienne retrospektywy
- retrospektywy na sprint
- retrospektywy na projekt
- programowanie par
- parowanie ping-ponga (zamiana sterownika i nawigatora po każdym etapie cyklu refaktora czerwono-zielonego)
- rozwiązane parowanie (brak ustalonych par, pary są przypisywane losowo i zmieniane każdego ranka i lunchu)
- nieparzysta liczba członków zespołu (jeśli programujesz w parach, jeden członek zespołu może się uczyć)
- programowanie mobów (wariant programowania parami, w którym cały zespół używa jednego komputera i ekranu, wyznaczony członek zespołu jest po prostu „maszynistą”, a inni mówią mu, co pisać)
- rozwiązłe drużyny (programiści są losowo przydzielani do zespołów każdego dnia / każdego sprintu)
Programowanie parami i programowanie mobów zapewnia nie tylko ciągły przegląd kodu, ale także ciągłe dzielenie się wiedzą. Parowanie ping-ponga zapobiega „zaczepianiu się” klawiatury przez jedną osobę. Rozwiązane parowanie rozpowszechnia wiedzę w całym zespole, rozwiązłe zespoły rozpowszechniają wiedzę w całej firmie i zapewniają, że każdy programista zna każdy projekt i każdą bazę kodów; doprowadzi to również do wysokiego stopnia standaryzacji w bazie danych. Podczas gdy retrospektywy koncentrują się przede wszystkim na przekazywaniu informacji zwrotnych na temat procesu opracowywania i odpowiedniego dostosowywania, można je również wykorzystać do przekazania rzadkiego problemu i sposobu jego rozwiązania.
Nie trzeba dodawać, że pracodawca powinien zapewnić obszerną bibliotekę, płatne subskrypcje ACM, Springer, IEEE itp., A także ciche pokoje do nauki w i większe pokoje do nauki. Wiele tablic i tablic flipboard, a także projektory na całym świecie są oczywiście sensowne, nie tylko do szkolenia.