środa, 22 czerwca 2016

Udany PAM Summit

Odbyła się kolejna edycja PAM Summit (http://pamsummit.com/). Udane wydarzenie, około 150 uczestników. Wstępne materiały z warsztatów, prowadzonych przez Bogdana Berezę, są dostępne w http://blogomotion.com/Download/CAB.pdf. Wyniki będą niedługo na blogu: http://wymagania.org.pl/blog.html.

wtorek, 14 czerwca 2016

Ogłoszenie o pracę - wymagania wobec testera

Czy to są trafne wymagania wobec testera? Co sądzicie?

Required competence (need to have)
  1. Minimum bachelor in Engineering
  2. Test knowledge (have good experience of different test stages within a development project, general (test-) process knowledge
  3. Good programming skills (have experience of some programming language like C, C++, C# or Tcl/Tk)
  4. Be able to understand how SW and HW interact, and how it works together.
  5. Be logical and have knowledge of tracing faults to its source (HW or/and SW).
  6. Have experience in executing test cases, both in a PC environment, at target system level and during field test.
  7. Have experience in transferring requirement into executable test cases and also transfer these into test scripts.
  8. Be able to evaluate outcome of an executed test case, and then, if needed report deviations from expected system behavior.
  9. Be able to document results of executed test cases.
  10. Be responsible for documents like Test Specification, Test Environment Specification, and Test Record.
  11. Good English both verbally as in written form
  12. Excellent interpersonal skills
  13. Be able to work in a team together with other team members
  14. Committed, engaged with the ability to prioritize and take ownership of tasks

czwartek, 12 maja 2016

9 rzeczy, których ci fachowiec od remontu nie powie, a chciałby żebyś wiedział

Na podstawie artykułu z portalu foch.pl

O specach od systemów IT zazwyczaj pisze się źle, kpiąco lub z trudem skrywając lekceważenie. Określenia "haker" nie należą do słyszanych rzadko. A gdyby tak posłuchać ich wersji wydarzeń, można byłoby się przekonać, że na jakość ich pracy ma wpływ też zachowanie klientów. Nie zawsze najmądrzejsze.

Klient zadowolony i wykonawca szczęśliwy? Wdrożenie idealne! 


Tworzenie nowego czy modyfikacja istniejącego systemu IT niejedną organizację doprowadził do kryzysu, a wykonawców do szaleństwa. Bo to nie jest wyzwanie tylko dla właścicieli biznesu, ale i dla ekipy budującej oprogramowanie. Klient z piekła rodem to wcale nie taka rzadkość, jak się wydaje. Co zrobić, aby wyjść z projektu zwycięsko i z poczuciem zadowolenia po obydwu stronach?

Oto wybrane sugestie deweloperów:

1. Jeśli wiesz lepiej ode mnie, jak tworzy się system - nie dzwoń. Jeśli święcie wierzysz, że moim priorytetem jest oszukanie ciebie - tym bardziej. Dostęp do narzędzi nie jest utrudniony, a tym bardziej do materiałów. W przypadku ewentualnych niepewności zawsze możesz obejrzeć instruktażowy film na YouTube. Czy to w końcu taka wielka sztuka np. napisać trochę kodu w Java? Pff, ile może zająć skonfigurowanie serwera przy nierównym obciążeniu? Zrób to sam, jeżeli jesteś przekonany, że zrobiłbyś to najlepiej. Jeśli jednak wolisz, aby pracę fizyczną ktoś za ciebie wykonał, wybierz fachowców, do których masz zaufanie albo z polecenia. Ewentualnie żądaj referencji lub zdjęć z poprzednich prac. Wypytaj o wszystkie możliwe kwalifikacje podczas pierwszego spotkania w kwestii wyceny wdrożenia. Bądź drobiazgowy, pytaj o wszystko. To i tak będzie lepsze niż dyszenie w kark fachowcom podczas pracy. Lubisz pracować czując za plecami czyjś oddech lub wysłuchując kolejnych dobrych rad "ekspertów"?

2. Ustal ze wszystkimi interesariuszami, jakiego efektu oczekujesz po wdrożeniu systemu. Przeprowadź analizę biznesową zawczasu, a nie dopiero w trakcie projektu. To radykalnie zmniejszy liczbę konfliktów i niepotrzebnych iskrzeń, a budowlańców uchroni przed wydłubywaniem brokatowych ozdóbek z interfejsu czy wyburzaniem dopiero co postawionych funkcjonalności. Przerobienie interfejsu użytkownika jest do zrobienia, ale zmiana logiki biznesowej - nieco gorzej. Szanuj czas ekipy.

3. Uwierz, że dobra jakość kosztuje. I dotyczy to nie tylko kosztów wynajęcia ekipy, ale i używanych materiałów. Nie oczekuj zatem idealnego interfejsu, jeśli oszczędzasz na jego projektowaniu i nie analizujesz potrzeb użytkowników. Gotowe darmowe formularze w Joomla!, kupione po najniższej cenie mogą zaś okazać się nieco nierówne. Rada: ekipy z wieloletnim doświadczeniem mają często doświadczenie, jak można realizować projekt taniej. Jeśli masz ograniczony budżet, pomyśl o tym, czy musisz realizować wszystkie wydumane i zbędne funkcjonalności.

4. Trzymaj się ustalonego planu pracy i zakresu obowiązków. Nie, fachowiec nie zrobi wszystkiego - "przy okazji". Niekoniecznie naprawi stare, zawodzące od dawna oprogramowanie, czy doda interfejs na urządzenia mobilne - skoro i tak buduje już dostęp do bazy danych. Jeśli jednak w trakcie projektu dojdziesz do wniosku, że chcesz, aby zostały wykonane prace dodatkowe - pamiętaj, że to zwiększy koszt. Kwestia - jakoś się dogadamy - nie jest mile widziana po żadnej ze stron.

5. Jeśli masz autorski projekt architektoniczny - wspaniale, ale skonsultuj go ze mną. Zielone litery na czerwonym tle nie są najlepszym z możliwych rozwiązań. Chyba że lubisz interfejs, który wygląda na jeszcze bardziej zniechęcający, niż jest w istocie. W tym przypadku to bardzo dobry trop. Jeśli masz profesjonalny projekt architektoniczny także omów go z ekipą wykonującą. To ułatwi wybór właściwych rozwiązań technicznych.

6. Szanuj czas ludzi, z którymi chcesz pracować. A i samych ludzi nie zawadzi. Upewnij się przed projektem, że wiesz, że chcesz go przeprowadzić i określ jasno termin. Przekładanie go w nieskończoność niekoniecznie spotka się ze zrozumieniem - zwłaszcza w sezonie. Możesz stracić wykonawcę.

7. Uwierz, że szybko nie zawsze oznacza dobrze. Realny termin realizacji remontu naprawdę powinien być realny. Dobre wykonanie wymaga czasu - dokumentację techniczną trzeba poddać przeglądom, a gotowy kod przetestować. Ludzie pracujący po kilkanaście godzin dziennie także mają swoją określoną wytrzymałość, a nikomu nie zależy na pracy wykonanej w pośpiechu.

8. Zwracaj się do mnie tak, jak sam chciałbyś być nazywany. Mówienie po imieniu czy protekcjonalne poklepywanie po plecach nie zawsze wywołuje euforię. Chyba że ludzie z ekipy też mogą tak się zachować wobec ciebie. Ach, nie życzysz sobie. No właśnie. Jesteś klientem, masz prawo oczekiwać należytego wywiązania się z powierzonych obowiązków. Nie, nie jesteś "panem i władcą".

9. Zapłać w terminie. Ustaloną wcześniej kwotę. Niestety, negocjacje w kwestii wysokości stawek po wykonanej pracy nie należą do rzadkości. Zachowujecie się tak w kinie lub restauracji?

Myślisz, że to wszystko banał, a zasady postępowania w IT identyczne jak w przypadku innych zawodów? Masz rację. Tyle że wciąż tworzenie oprogramowania czy wdrażanie systemów kojarzą się najczęściej z Armageddonem. A można to zmienić. Bardzo łatwo.

niedziela, 10 kwietnia 2016

Film IREB-CPRE na YouTube

Polecam Film IREB-CPRE na YouTube
:

RE-Challenge dopiero jesienią :(

FORUM inżynierii wymagań i analizy
PRZENIESIONE NA JESIEŃ 2016 - zobacz powody





Czemu trzeba przesunąć termin?

Z powodu chaosu, który od ponad pół roku wkradł się w działania Stowarzyszenia Inżynierii Wymagań (szczegóły), muszę przesunąć termin Forum RE-Challenge. Szkoda to wielka, ponieważ po nadzwyczajnym powodzeniu seminariów RE@Agile w styczniu, oraz RE@BPM w marcu - w każdym wzięło udział około 90 uczestników - można było się spodziewać równie wielkiego sukcesu RE-Challenge, co potwierdza kilkadziesiąt dotąd otrzymanych zgłoszeń.

Robię to z ciężkim sercem z powodu wszystkich Was, którzy doznają zawodu i z wyrzutami sumienia tak wobec znakomitych prelegentów, którzy zgłosili chęć wystąpienia, jak i wobec dziesiątek osób, które już zgłosiły chęć uczestniczenia w Forum. Dziękuję Wam i obiecuję, że RE-Challenge 2016 odbędzie się, jeszcze w tym roku!

Bogdan Bereza, Przewodniczący Rady Programowej
Double Power!