Pokazywanie postów oznaczonych etykietą IT. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą IT. Pokaż wszystkie posty

piątek, 7 listopada 2014

Jak zacząć mówienie na konferencjach?


Czy jesteś zainspirowany/zainspirowana moją poprzednią notką >> dlaczego warto mówić na konferencjach<<? Świetnie! Teraz pora na parę rad jak zacząć mówić :)

Wybierz strategię

Strategia 1
Znajdź wymarzoną konferencję na której chcesz mówić, przeglądnij tematy z poprzednich edycji, spróbuj znaleźć coś co pasuje do Twoich zainteresować. Możesz też spróbować czegoś odrobinę kontrowesyjnego. Napisz abstrakt i... wyślij zgłoszenie.

Strategia 2
Znajdź temat który Cię pasjonuje, napisz abstract i… znajdź konferencję. Kiedy już uda Ci się wypatrzeć konferencję, dostosuj do niej temat i wyślij swoje zgłoszenie.

Brzmi prosto? Bo jest proste! A teraz zobaczmy jak wykonać poszczególne kroki.

Jak znaleźć temat?

Jeśli kochasz czytać i jesteś na bieżąco z trendami, to znalezienie rzeczy którą chciałbyś/chciałabyś podzielić się z innymi, nie będzie trudne. Możesz podzielić się swoim doświadczeniem w wdrażaniu nowinek, skrytykować/pochwalić trendy które są popularne albo zaprezentować coś kompletnie nowego, co udało Ci się odkryć!
Podziel się swoją pasją z innymi!

Jak napisać abstrakt?

Przeglądnij abstrakty z konferencji które znasz. Zwykle wystarczy jeden paragraf wprowadzenia do tematu oraz jeden paragraf z informacją czego nauczą się od Ciebie inni ludzie.

Jak znaleźć konferencje?

Możesz szukać po tagach „CFP” lub „C4P” na twitterze, zobacz też http://lanyrd.com oraz poszukaj w google. Jeśli masz swoje ulubione konferencje, to obserwuj je poprzez sieci społecznościowe.

Ostatnio, Studencki Festiwal Informatyczny otworzył CFP: http://sfi.org.pl/2014/11/startujemy-call-for-papers/
Zobacz i zgłoś swoją prezentację!





czwartek, 26 czerwca 2014

ACE vs. PAM summit part 2

>> Tu<< możecie znaleźć pierwszą część tekstu.
Tymczasem pora kontynuować wywód o ACE i PAM :) Tym razem może być bardziej kontrowersyjnie niż poprzednio. Dajcie znać w komentarzach co sądzicie!

6.       Stoiska sponsorów
ACE: Tylko rollup bez ludzików.
PAM summit: wystawki z losowaniem nagród, możliwością zabrania gadżetów itp.
Podobał mi się minimalizm ACE! i fakt że po prostu dostałam gadżety bez nagabywania o moje dane osobowe... A zdrugiej strony na PAM wygrałam książkę, co było bardzo miłe!

7.       Kawa
ACE: kawa sponsorowana przez CodeSprinters, obok były ulotki i zainteresowani mogli się nimi częstować. Uważam, że mega dobry pomysł marketingowo!



PAM summit: kawa płatna

8.       Scena
ACE: minimalistyczna i pusta. W stylu TEDa moim zdaniem :) Nic nie zakłócało mojego odbioru.
PAM Summit: załadowana różnymi dziwnymi rzeczami. Jedna konstrukcja się przewróciła w trakcie przemówienia. Można załadować scenę sympatyczniej (patrz Railsberry). W przypadku PAM summit mi się średnio podobało. Może dlatego że zobaczyłam, że można zrobić scenę bez reklam zakłócających mój odbiór?

9.       Organizacja ‘zmian’ speakerów na scenie
ACE: osoba podpinała się z komputerem z boku a nie na scenie. Była gotowa już przed wyjściem.
PAM Summit: ogromne zamieszanie na scenie, bo prelegenci podpinali się na scenie. Mało płynnie, chaotycznie.

10.   Nagłośnienie
Kiepskie w obu przypadkach - zwłaszcza z tyłu sali.

11.   Jedzenie
Przekąski
ACE: elegancko pokrojone owoce (zaleta dla ludków z aparatem na zębach) i ciastka
PAM summit: całe owoce i ciastka

Lunch:
ACE: standard lunch
PAM summit: kanapka... poprawili to potem gulaszem...



12.   Feedback
ACE! tablica do feedbacku i świetne ankiety. Organizatorzy reagowali na „skargi” na bieżącą.
PAMsummit – jestem ciekawa, czy gdybym się nie zapytała gdzie można zostawić feedback (hehe narosła moja frustracja, chciałam o tym gdzieś napisać ;)) to czy w ogóle by on był... Podobno ma zostać wysłany na maila – ale jeszcze go nie mam, a je dwa dni po konferencji.

CDN

środa, 25 czerwca 2014

ACE vs. PAM summit część 1


Ostatnio byłam pod rząd na dwóch konferencjach, które odbywały się w tym samym miejscu – Stara Zajezdnia tramwajowa. 

source: http://aceconf.com

Jedną z nich było ACE! (Agile Central Europe) a druga to PAM Summit (Project & Analysis Management Summit). Obie to konferencje płatne, obie dwu dniowe (przynajmniej w teorii), więc z uwagi na te podobieństwa spróbuję je porównać pod względem „organizacyjnym” . Dlaczego? Bo nigdy nie jest idealnie i trzeba dążyć do doskonałości :) Może innym organizatorom konferencji posłuży to jako inspiracja.

1.       Identyfikator - Twoja tożsamość :)
Identyfikator mówi o Twojej tożsamości jako uczestnika. Bardzo podoba mi się że w ACE! postawili na ekspozycje imienia, że zadali sobie trud aby wyszukać logo firmy w której pracuje uczestnik i że zapytali mnie czy chce coś specjalnego na moim identyfikatorze – duży plus :)
Czy identyfikator jest drukowany czy jest naklejką –to nie robi wielkiej różnicy wg mnie.


2.       Smycze vs. Sznurki
Jak łatwo zauważyć na ACE! były sznurki zamiast smyczy. Super pomysł! Ludzie fantastyczne rzeczy z nimi wyczyniali, a dzięki odpowiedniej długości – identyfikator był łatwo widoczny. Na smyczy niestety wisi „za nisko” (hehe przynajmniej w przypadku osób mojego wzrostu ;)). Świetna rzecz odnośnie sznurka – można go „customizować”, wybrać sobie kolor, długość i zrobić samodzielnie coś z jego kształtem. Nie sądziłam że to może być taka mega zabawa ;)

3.       Torba konferencyjna
Sama torba na ACE! niestety słabo wykonana. Materiał nie szczególny a i nadruk wydaje się kiepskiej jakości. Na PAM summit torba jest super dopracowana.

Torba ACE!

Torba PAM Summit

Torba PAM Summit


4.       Materiały konferencyjne
Tu będzie kontrowersyjnie... zobaczcie:
Ulotki z PAM Summit 

To jest sterta ulotek z PAM. Nie podoba mi się ten „SPAM”. Drodzy sponsorzy – czy moglibyście zacząć szanować środowisko i nie dawać mi tych śmieci? Zostawcie trochę ulotek na stoiskach i jak ktoś jest zainteresowany – to podejdzie i weźmie. Zastanawia mnie czy ktoś robił badania nad tym czy ulotki w ogóle działają na ludzi z IT... Jeśli nie, to po co na nie marnować kasę?
Dla porównania w ACE było minimalistycznie – nie dostałam żadnej ulotki. Mogłam sobie sama zabrać rzeczy które chce ze stolika z rejestracją.

5.       Gadżety konferencyjne
Na ACE! Dostałam torbę + koszulkę + długopis + notes.
Gadżety z torby ACE!

Na PAM Summit dostałam torbę z masą ulotek, notes, długopis, piłeczkę antystresową i zegarek. 

Gadżety z torby PAM Summit

Można było zabrać gazety i karty do planning  pokera ze stolika z rejestracją. Można też było zabrać trochę gadżetów ze stoisk sponsorów.

Gadżety "zdobyczne" PAM Summit


W obu przypadkach zabrakło podstawowej rzeczy: naklejek na laptop. Cierpię :(

C.D.N.

sobota, 21 czerwca 2014

Etyka/sumienie w IT

W ostatnich dniach było bardzo głośno o lekarzach, którzy (w dużym skrócie) postanowili odmawiać wykonywania zabiegów niezgodnych z ich sumieniem (więcej można poczytać >>tu<<). Tak sobie myślę, jak fajnie by było, gdyby w IT też tak można było...

Wracając do sedna sprawy, zastanówcie się ile razy spotkaliście się z wymaganiami przez które chciało się wam płakać? 

Czy kiedyś implementowaliście coś, co wiedzieliście że wprowadzi użytkownika w błąd? Czy kiedyś implementowaliście funkcjonalność która była nielogiczna? Czy kiedyś implementowaliście coś, co było tylko stratą pieniędzy, a mimo to klient się uparł i trzeba było zrobić?


Jeśli choć na jedną z tych pytań odpowiedzieliście TAK, to znacie ten ból... Smutne jest to, ze w IT próbujemy przekazać tzn. ‘biznesowi’, ze to co chcą zrobić nie jest roztropne, etyczne, dobre czy jakkolwiek sensowne ale ... oni nam nie ufają! I jesteśmy przymuszani robić rzeczy, z którymi wewnętrznie się nie zgadzamy. Wygląda to źle, ale oczywiście tu trochę przesadzam – bo jednak takie rzeczy zdarzają się rzadko. Mimo to, fajnie pomarzyć o sytuacji w której można powiedzieć „nie zrobię Ci tej funkcjonalności, bo nie jest ona zgodna z moim sumieniem” ;) Tym bardziej że my ludziki IT jesteśmy pasjonatami i lubimy tworzyć wielkie dzieła, a nie buble ;) 

A wy co myślicie? 

piątek, 20 czerwca 2014

Video

Wideo z ACE jest już dostępne! Konferencja skończyłą się 3 dni temu, a wideo jest już dostępne online. Wow - to się nazywa ekspres :) 


Kasia Mrowca - The Art of Saying NO from ACE! Conferences on Vimeo.

Zobacz: 
Slajdy z ACE!
Konferencyjny zawrót głowy!

czwartek, 19 czerwca 2014

ACE!

Zobacz moje slajdy z ACE!




Wrażenia po konferencji:


  • Świetni prelegenci
  • Fajnie zaprezentowane różne punkty widzenia na ten sam temat (można wyrobić sobie własną opinię)
  • Świetne dyskusje 
  • Super miejsce
Bawiłam się świetnie. Do zobaczenia za rok!



niedziela, 15 czerwca 2014

Konferencyjny zawrót głowy!

Muszę przyznać się do winy… Nie miałam czasu na pisanie na blogu!

Muszę się usprawiedliwić – ostatnio sporo jeżdżę po konferencjach plus kończę studia doktoranckie. Obiecuje się poprawić i przy okazji w końcu napisać relacje z konferencji na których byłam :)



Tymczasem zachęcam do przyjścia jutro na ACE! (Agile Central Europe!). Może są bilety „Last Minute”? Zachęcam, bo konferencja zapowiada się wyśmienicie!



wtorek, 25 marca 2014

Kongres kobiet, misja: podzielić się pasją!


Razem z koleżankami z PTI oraz z Hacker Space Kraków, reprezentowałam "kobiety w IT" podczas I Małopolskiego Kongresu Kobiet. Podczas naszego panelu dyskusyjnego próbowałyśmy zachęcić panie młodsze i starsze do wkroczenia na techniczną ścieżkę zawodową ;) Odkryłyśmy też nieznane oblicza IT, które zostały entuzjastycznie przyjęte przez publikę :) Pełną relację można przeczytać tu: http://pti.krakow.pl/?p=1360

Zapraszam od obejrzenia paru zdjęć :)



source: https://www.facebook.com/acelinskaphoto


source: https://www.facebook.com/acelinskaphoto

source: https://www.facebook.com/acelinskaphoto

poniedziałek, 24 marca 2014

Zabiegany marzec

Cześć!

Miło mi was poinformować, że będę mówiła na dwóch konferencjach w tym tygodniu :)

Najpierw mówię na konferencji "Kompleksowe Systemy Informatyczne" (GigaCon) a potem prowadzę warsztat na Studenckim Festiwalu Informatycznym. Oba wydarzenia są tego samego dnia - 27.03.2014

13:10 - "Kompleksowe Systemy Informatyczne" (GigaCon) - Jak wybrać systemy IT wspierające działalność przedsiębiorstwa?
Rejestracja:  http://gigacon.org/ksi/krakow/rejestracja 

15:30 - Studencki Festiwal Informatyczny - Sztuka wojny wg analityka IT, czyli metody współpracy z wymagającym klientem
Rejestracja:
1. Wyślij e-mail na adres: warsztaty@sfi.org.pl
2. Tytuł maila: [27.03] Sztuka wojny wg analityka IT, czyli metody współpracy z wymagającym klientem
3. Maile można wysyłać do północy 26.03
4. Zapis należy potwierdzić do 30 min przed rozpoczęciem warsztatu przy recepcji Studenckiego Festiwalu Informatycznego
fot. Agnieszka Celińska

sobota, 15 marca 2014

In-house made software vs. External vendor software


Miałam przyjemność pracować w wewnętrznym dziale IT, który dostarczał aplikacje wspierające działalność biznesową firmy (która nic z IT wspólnego nie miała). Obecnie mam przyjemność pracować w firmie, która jest dostawcą rozwiązań IT - więc końcowy klient aplikacji jest "na zewnątrz". Tak się zastanawiałam - czy są znaczące różnice w produkcji aplikacji w przypadku tych dwóch modeli?

Komunikacja
Po pierwsze, jeśli jesteś dostawcą - nie masz bezpośredniego kontaktu z klientem. Czasami IT nie ma kontaktu z klientem wcale (cała komunikacja jest kierowana przez określone proxy). Jeśli pracujesz jako wewnętrzny dostawca, to zawsze możesz złapać swój "biznes" na korytarzu, w kuchni tudzież w innym miejscu - i zadać pytania ;) To sprawia, że praca jest znacznie prostsza!

Elastyczność
Oczywiście elastyczność jest mocno związania z komunikacją. Filozofia agile pozwala na łatwe i szybkie dostosowanie planów do szybko zmieniającej się rzeczywistości. Czyli jeśli IT ma dobre stosunki z biznesem, to wszystko pięknie funkcjonuje. A co gdy komunikacja nie zachodzi wcale? (To pytanie pozostawiam jako retoryczne ;))
Agile nie jest lekarstwem na wszystkie bolączki. Jeśli klient zmienia zdanie ciągle, przykładowo: podczas pierwszej iteracji chciał czołg, podczas drugiej helikopter aż finalnie w trzeciej okazało się że chce łódź podwodną, wtedy produkt finalny będzie wyglądać jak mały (albo ogromny) potworek. Elastyczność jest ważna, ale powinna mieć swoje granice!

Odpowiedzialność
Jeśli pracuje się dla wewnętrznego klienta, to chce się mu umożliwić "zarabianie", bo przecież dzięki temu jest wstanie zapłacić za wykonaną pracę. Proste, nieprawdaż? Doprowadzenie własnego pracodawcy do bankructwa jest podcinaniem gałęzi na której się siedzi, więc nikt o zdrowych zmysłach tego nie chce. Jeśli jest się zewnętrznym dostawcą, to presja jest nawet większa - "firma-matka" zarabia na dostarczaniu aplikacji, więc jak jakość aplikacji jest niska, to nikt jej nie kupi. Jeśli natomiast wdrożenie aplikacji "zbije" firmę klienta, to nikt inny na rynku nie pokusi się o kupienie*.

*wyjątek stanowi SAP, który "zabił" jednego ze swoich klientów (FoxMeyer), a mimo to ma się świetnie. Więcej o FoxMeyer można poczytać >>tu<<

Cel
Wracając do pierwotnie zadanego pytania - oczywiście różnice istnieją, ale w obu przypadkach cel jest jeden. Stworzyć super oprogramowanie :) Programiści to pasjonaci, który lubią pisać porządny kod (tak, są geekami i zwykle są z tego dumni :)).


Źródło: http://geek-and-poke.com/geekandpoke/2014/3/4/hr-is-key

środa, 18 grudnia 2013

Sztuczki w Balsamiq


Uwielbiam makiety w rozumieniu prototypów aplikacji. Dlaczego? Bo to świetny sposób na pokazanie użytkownikowi jak aplikacja będzie wyglądać zanim jej kodowanie się zacznie (pozwala to też przedyskutować zbyt abstrakcyjne dla 'biznesu' rzeczy na "żywym" przykładzie).

Balsamiq jest programem, dzięki któremu możemy stworzyć pliki pdf w które da się klikać. Nawet najbardziej oporny użytkownik nie pomyśli, że to jest już 'prawie' gotowa aplikacja (więc nie ma niebezpieczeństwa, że poprosi o jej wdrożenie... jutro!). Makiety robione w narzędziach typu 'Just in mind' są łudząco podobne do aplikacji, co może być mylące i... użytkownik może pomyśleć, że aplikacje jest prawie gotowa ;)

Mam nadzieję, że udało mi się was zachęcić do prototypowania. Poniżej kilka wskazówek jak zabrać się za robienie makiety w Balsamiq:

  • zaplanuj jak wygląda "flow" w aplikacji
  • wybierz opcje które chcesz pokazać (lepiej wybrać parę różnych niż takich które wyglądają bardzo podobnie do siebie)
  • zastanów się na sekwencją, którą użytkownik powinien podążać klikając w prototyp
  • przygotuj sobie szkielet dla wszystkich ekranów (obrazy które pokazują stan aplikacji)
  • przygotuj ekrany które odpowiadają zaplanowanej sekwencji (jedna akcja - jeden obraz)
  • stwórz linki między ekranami
  • zapisz jako Pdf
  • gotowe :)


Zajrzyj do innych notek o prototypowaniu!

sobota, 14 grudnia 2013

Kanban-ish

Wiecie co jest najlepszą częścią meetup'ów i innych spędów dla pasjonatów IT? Nieformalne dyskusje po! 

Ok, ale może zacznę od początku i małego wprowadzenia. W zeszłym tygodniu byłam na spotkaniu ALE Kraków - warsztat prowadziła +Oana Juncu, a mówiła o Innovation@Games. Warsztat był podzielony na część teoretyczną i praktyczną (i jak podejrzewacie, ta praktyczna najbardziej mi się podobała ;)). W czasie tej krótkiej sesji grupom warsztatowym udało się stworzyć projekty w formie papierowych mockup'ów bardzo ciekawych aplikacji. Nie mogę się już doczekać, aż zastosuję tą metodę w pracy :)

Oczywiście po zakończeniu szkolenia, była dyskusja. Dla mnie szczególnie inspirująca ponieważ Oana pracowała w Eurosporcie, więc mogłyśmy wymienić opinie na temat wyzwań jakie stawia IT 'klient' jakim jest telewizja. Bardzo inspirujące! Ale nie o tym dziś. Dyskusja była też o innych ciekawych trendach związanych z IT. Bardzo podobała mi się dyskusja o Kanbanie, który stanowił przykład 'przestrzegania zasad metodyki'. Dużo ludzi używa Kanbanu, ale pytanie brzmi: czy używają tego poprawnie? Jak użyć Kanbanu efektywnie? Oczywiście zdania były podzielone, ale konkluzją było:

  • metodyka (Kanban i każda inna) jest dla ludzi, a nie na odwrót,
  • ludzie mogą (i powinni!) dostosowywać ją do swoich potrzeb,
  • przestrzeganie reguł od A do Z nie koniecznie przyniesie oczekiwane rezultaty, 
  • nie ma nic złego w używaniu czegoś Kanbano-podobnego dopóki to działa - to dotyczy także innych metodyk!  





Przykład tablicy Kanbanowej. Źródło: http://www.iddblog.org/?p=1150


A tak przy okazji - pamiętacie o moim jutrzejszym warsztacie? Do zobaczenia! 

wtorek, 10 grudnia 2013

Świąteczne warsztaty

Już w następną niedzielę prowadzę kolejny warsztat dla Analityków, Product Ownerów i nie tylko! (Spokojnie, jak masz z tą działką nie wiele wspólnego a temat Cię interesuje - zapraszam, na pewno będzie coś interesującego i dla Ciebie). 
Tym razem przedstawię tajniki zbierania wymagań... w formie świątecznej baśni :) Będzie świetna zabawa! 

Temat: Aplikacja od początku do końca - czyli skąd programiści wiedzą co pisać?
Koszty: Za darmo, ale wymagana rejestracja: http://swietaggc.evenea.pl/ 
Kiedy: 15.12.2013, 17:00
Gdzie: Pauza In Garden, Rajska 12, 31-124 Kraków

View Larger Map

Do zobaczenia! 

wtorek, 19 listopada 2013

Prototypy w Visual Studio?




Śmiała myśl, czyż nie? Dla programisty pewno oczywistym jest stworzenie prototypu w Visual Studio albo innym IDE. Dla mnie VS było ostatnim narzędziem, które wybrałabym do robienia makiet… Jednak kolega zasugerował aby spróbować tego narzędzia.

I tak zaczęła się przygoda. Aplikacja była mobilna, więc czyste VS wydawało się nie wystarczające (kobieta jestem, więc wygląd ma znaczenie). Tak, Microsoft Blend był tym czego potrzebowałam… albo takie pozory przynajmniej sprawiał ;) Jak się domyślacie, okazało się że idealną parą do Blenda jest… PhotoShop. Niestety moja licencja na PS wygasła dawno temu. Finalnie powróciłam do VS.

Po tym przydługim wstępie, pora na najciekawszą część – moje odkrycia ;)

Wady prototypowania w VS:
-          trzeba trochę znać programowanie
-          standardowe gui jest brzydkie… więc jak nie masz umiejętności aby podgładzić interfejs, to makieta jest brzydka
-          wygląda jak prawdziwa aplikacja (użytkownik może nie pojąć, że to tylko atrapa)
-          kuszące jest dążenie do zrobienia idealnego narzędzia od razu… powoduje to spędzenie masy czasu nad dopieszczeniem makiety, która z założenia ma się zmień… (user na pewno powie że chciał przecież co innego, czyż nie?)

Zalety:
-          Zdecydowanie szybciej można zrobić prototyp w VS niż w narzędziach “klikalnych” (jeśli znasz się ciut na programowani I nie popłyniesz z perfekcją za bardzo ;))
-          Limitem jest tylko Twoja wyobraźnia (można zrobić absolutnie wszystko jeśli umie się… programować ;))

Tak… lepiej zostanę przy moim ulubionym balsamiq :)


środa, 23 października 2013

wtorek, 8 października 2013

Zmiana: jedyna pewna rzecz w IT


Zmiana jest naturalną rzeczą jeśli chodzi o organizacje. Rynek zmienia się często i szybko. Chyba już nie istnieją sektory czy branże, które są "stabilne" (czasami się zastanawiam czy takie kiedykolwiek istniały, może to tylko miejska legenda?). IT ma za zadanie wspierać biznes, więc powinno być elastyczne. Systemy powinny pozwalać na szybkie zmiany. Oczywiście łatwo powiedzieć, ale czy równie łatwo zrobić? 

Nowoczesne metodologie pozwalające na zarządzanie projektami/produktami IT pozwala na szybką reakcję na zmiany (Scrum i generalnie cały agile, lean oraz inne), niemniej jednak sama metodyka to nie wszystko.


Elastyczne założenia

Brzmi dziwnie, nieprawdaż? Podczas zbierania wymagań, trzeba zrobić założenia. Skoro to założenia to powinny być przecież stabilne! Praktyka brutalnie uczy, że założenia wyglądające jak skały tatrzańskie albo i nawet same Tatry także mogą zostać ruszone w rozumieniu zmienione (znacie powiedzenie o przenoszeniu gór? pasuje tu!). Myślę, że nawet założenia związane z teorią grawitacji mogą zostać podważone na gruncie IT ;)


Ok, co można zrobić aby oswoić zmianę?

Architektura - małe moduły/funkcjonalności którą są niezależne (na tyle ile to możliwe)

Plan - długoterminowe plany są ok, ale tylko gdy nie są zbyt szczegółowe. Długoterminowa wizja jest ważna, ale szczegółowy plan powinien być wytyczony tylko dla krótkiego okresu. Trzymanie się kurczowo planu długoterminowego, podczas gdy rzeczywistość się zmieniła, nie jest dobrym pomysłem (chyba że naszym celem jest dostarczenie bezużytecznego narzędzia). 

Wymagania - bądź pewny że się zmienią w czasie. Napisz je tak aby umożliwiały nagłe zmiany (zwłaszcza w strategicznych obszarach).

Założenia - sprawdzaj od czasu do czasu czy się nie zmieniły. Niestety, do końca świata nie zostaną takie jak były na początku :(

Metodologia - nie jest to koniecznie Twoja brożka, ale jak możesz to wybierz taką która jest elastyczna, lekka i wspomagająca zmiany. 

Jest mnóstwo innych rzeczy pomagających adaptować się do zmiany: continuous delivery, continuous integration, całe mnóstwo metodyk testowania itp. Zatrzymam się jednak tu. Może kiedyś napiszę o tym z punktu widzenia analityka ;) Może być interesująco! 

Pamiętaj! Do not underestimate the power of change!