Miesięczne archiwum: Październik 2017

Podejście Waterfall raz jeszcze

W sumie poruszałem już ten temat we wpisie Agile vs Waterfall – jak przekonać zarząd i klienta, ale ponieważ znowu odbyła się ciekawa dyskusja na ten temat, to chciałbym jeszcze raz do tego wrócić może na bardziej konkretnym poziomie. Bo czasami zbyt wysoki poziom abstrakcji powoduje trudności w zrozumieniu tematu.

Początkiem dyskusji była opinia, że mimo wszystko czasami lepiej jest przygotować projekt z góry, opisać architekturę, wymogi itp. Takie podejście powinno pomóc uniknąć pułapek, które mogą pojawić się w trakcie tworzenia systemu, zaprojektować architekturę, przewidzieć technologię …

CC BY-NC-ND 2.0

Czytaj dalej

Szacowanie – story point i velocity

Chciałbym podsumować trochę wiedzę zdobytą w trakcie rozmów z trenerami Scrum na temat szacowania. Dyskusja z zespołami dostarczyły następnych ciekawych przemyśleń. A generalnie wiąże się to również z powszechnymi próbami przeliczania story pointów na dni robocze i odwrotnie. Wiadomo, że nie powinno się tak robić ale uzasadnienie i zrozumienie dlaczego jest trudniejsze.

Z punktu widzenia logiki jak i statystyki jest to jak najbardziej uzasadnione. Jeśli przeliczmy story pointy na dni to tak naprawdę przestajemy już estymować tylko dokonujemy wyceny czasochłonności. A estymaty służą do czegoś innego – ocenienia jak dużo pracy trzeba wykonać w konkretnym user story. Przecież warunki będą się zmieniać, istnieją urlopy, zwolnienia, może się zmieniać skład zespołu i tak można by wymieniać.

Czytaj dalej

Potyczki z Selenium część 2

W drugiej części wpisu chciałbym dodać trochę szczegółów technicznych, które pominąłem w pierwszej części (patrz Potyczki z Selenium część 1) dla przejrzystości. Więc zaprezentuję jak wyglądają niektóre pliki konfiguracyjne i skrypty, których używamy do resetowania testowych node’ów. Forma jest bardzo skondensowana ale mam nadzieję, że w połączeniu z pierwszą częścią nie powinno być problemów ze zrozumieniem.

Jeszcze tytułem wyjaśnienia – testy automatyczne wykonują się podczas uruchomiania procesu build-a na TFS, a resetowanie node’ów następuje przed wykonaniem testów jak i po ich zakończeniu. To dlatego, że lokalnie podczas uruchamiani testów również czasami używamy node’ów. Po wykonaniu paczki testów automatycznych wykonujemy również podczas nightly build-a przywrócenie bazy danych do pierwotnego stanu, aby system na środowiskach testowych był wyczyszczony z danych testowych produkowanych przez testy automatyczne.

Czytaj dalej