GoldenLine
Zaloguj się

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Czy ktoś moze napisać, czym jest to, co zawarłam w tytule wątku? Prosytmi, nieskompliklowanymi słowami, bo nie jestem informatykiem, ni programistą. Proszę mnie nie odsyłac do google, bo już zaglądalam i - szczerze powiedziawszy - wyniki nic mądrego mi nie powiedziały.

Bedę wdzięczna za informacje.
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Wedlug lekkiej metodyki nie bazujesz na zamknietej specyfikacji i zamknietym projekcie tylko projekt ciagle zyje - czesto w cyklach. Do tego (i stad wziela sie nazwa ze sa lekkie) nie tworzysz ogromnej ilosci dokumentacji jak w przypadku metodyk ciezkich...

Dobrym przykladem jest tu metodyka Scrum (ang. Mlyn), w uproszczeniu:

1. Ustalasz cykl, powiedzmy na 1 miesiac
2. Zbierasz wymagania i priorytety od klienta
3. Ustalasz z zespolem co jest wykonalne w danym cyklu
4. Przez 1 mc tworzysz, testujesz itp
5. Pokazujesz klientowi i jezeli zostalo cos do zrobienia wracasz do Pkt 2

Oczywiscie jest jeszcze w tym kilka szczegolow i bywaja modyfikacje zaleznie od preferencji zespolu/klienta itp - to sa tylko wskazowki jak dzialac a nie sztywne wytyczne.

A tak przy okazji jak to Tadek Golonka powtarza: Metodologia to nauka o metodykach, a metodyka... :)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Dziękuję.
Czy dobrze zatem rozumiem, że to coś, co stale się rozdubowuje, poprawia, ulepsza, zmienia, etc. np. żeby dopasowac do zmiennych potrzeb klienta, zmieniającego się otoczenia konkurencyjnego, etc.?

czy za tym stoi jakaś fachowa wiedza, tak jak np. jest w przypadku zarzadzania projektem???

Rafał Ziółkowski:
Wedlug lekkiej metodyki nie bazujesz na zamknietej specyfikacji i zamknietym projekcie tylko projekt ciagle zyje - czesto w cyklach. Do tego (i stad wziela sie nazwa ze sa lekkie) nie tworzysz ogromnej ilosci dokumentacji jak w przypadku metodyk ciezkich...

Dobrym przykladem jest tu metodyka Scrum (ang. Mlyn), w uproszczeniu:

1. Ustalasz cykl, powiedzmy na 1 miesiac
2. Zbierasz wymagania i priorytety od klienta
3. Ustalasz z zespolem co jest wykonalne w danym cyklu
4. Przez 1 mc tworzysz, testujesz itp
5. Pokazujesz klientowi i jezeli zostalo cos do zrobienia wracasz do Pkt 2

Oczywiscie jest jeszcze w tym kilka szczegolow i bywaja modyfikacje zaleznie od preferencji zespolu/klienta itp - to sa tylko wskazowki jak dzialac a nie sztywne wytyczne.

A tak przy okazji jak to Tadek Golonka powtarza: Metodologia to nauka o metodykach, a metodyka... :)
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
czy za tym stoi jakaś fachowa wiedza, tak jak np. jest w
przypadku zarzadzania projektem???
Nigdy nie słyszałem nazwy "lekka metodologia"... Ale zakładam, że chodzi o agile itp. Powinno być bardzo dużo dostępnych publikacji.

Jedna z bardziej znanych stron które to zaczęły, to chyba http://www.extremeprogramming.org/ jeśli chcesz coś ogólnego.
Ale wystarczy wygooglać agile methods. Tego jest od groma i trochę - szczególnie w ostatnich 2-3 latach. Szczególnie że nikt nie zdefiniował tego konkretnie i teraz się wszyscy mogą kłucić, że wszystko robią bardziej agile od innych ;)Stanisław Pitucha edytował(a) ten post dnia 02.04.09 o godzinie 22:09
Link do wypowiedziLink
Maurycy Mikulski

Maurycy Mikulski programista
C++(MS,QT),C#-MVC,SO
AP,AJAX-REST,SQL

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
żeby dopasowac do zmiennych
potrzeb klienta

Nie do końca chodzi o zmienne potrzeby.
Problem leży w tym, że klient zwykle nie zna i nie podejrzewa swoich potrzeb.
Nie wiem jakby ktoś się starał to nie opisze tego co klient jeszcze nie wyśnił.
No a potem koncert życzeń jak projekt się kończy. To prosta droga do klęski.
I nikt nie jest zadowolony. Klient jest przekonany ,że nie dostał tego co zamówił i za co zapłacił a wykonawca siedzi w dokumentacji i w systemie i przerabia, przerabia i przerabia ..
Jest jednak jedno ale. Produkt finalny wyjdzie lepiej dopasowany do wymogów klienta,a realizacja projektu nie będzie polegała na ciągłych zmianach. Do tego można lepiej zagospodarować zespół.
Analizy, projektowanie,programowanie i testy się przeplatają lub występują równolegle a nie następują faza po fazie.
To jedno "ale", to problem wyceny i szacowania zasobów potrzebnych do wykonania projektu. Nie zna się wszystkich zagrożeń i wymogów.
Mając pełną dokumentację łatwiej dokonać wyceny.
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
Dziękuję.
Czy dobrze zatem rozumiem, że to coś, co stale się rozdubowuje, poprawia, ulepsza, zmienia, etc. np. żeby dopasowac do zmiennych potrzeb klienta, zmieniającego się otoczenia konkurencyjnego, etc.?

czy za tym stoi jakaś fachowa wiedza, tak jak np. jest w przypadku zarzadzania projektem???

Tak jak napisal to Maurycy, czesto klienci nie wiedza czego tak na prawde chca, czesto wymagania sa wzajemnie sprzeczne - metodyki agile pomagaja zjesc ten tort w malych kawalkach.

Oczywiscie ze jest mnostwo wiedzy na ten temat. Sa opracowane szkielety metodyk takie jak:
- XP (eXtreemeProgramming)
- Microsoft Solution Framework for Agile
- Scrum

Tak jak napisalem sa to wskazowki jak dzialac zeby doprowadzic wszystko szczesliwie do konca.
Link do wypowiedziLink
Dariusz Macina

Dariusz Macina Technology Manager,
Making Waves Polska

Temat: lekka metodologia wytwarzania oprogramowania

Dlatego metodyki lekkie najlepiej sprawdzaja sie w projektach, w ktorych cena nie jest stala i z gory okreslona ale oparta o realne zuzycie zasobow (time&material).
Jest to zupelnie logiczne, bo skoro nie do konca wiemy jak bedzie wygladal produkt finalny to jak dokonac jego wyceny.
Wszystko wyglada fajnie ale w rzeczywistosci to.... konia z rzedem temu kto potrafi przekonac do tego klienta.
Mozna tez zalozyc staly budzet ale wtedy istnieje zagrozenie, ze po ktorejs tam iteracji, zasoby sie skoncza a oczekiwania klienta zupelnie odwrotnie ;)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

tak jak piszecie, z tym ze dodam swoje:
- scrum dostosowany do polskich wymagan (pisac, spisywac i uzywac ton papieru - koniecznie z podpisem klienta - jedna i druga strona bedzie chronionia)
- przeszlismy jakis kamien milowy - klient u nas, my u niego - jakkolwiek - ocenic, porownac z oczekiwaniami, spisac roznice (i znow w formie protokolu...) - i idziemy dalej lub poprawiamy (jesli zespol jest wiekszy to i poprawki i "idziemy dalej" spokojnie moze isc do przodu
- do planowanego terminu wykonania i tak dodaj wspolczynnik poslizgu, bo nawet jesli ryzyko zaistnienia problemow jest mniejsze niz 10% - to nie da sie go wykluczyc (zgodnie z prawami Murphy'ego). A jesli skonczysz wczesniej - dobra twoja.
- komunikacja, komunikacja, komunikacja - "stary, sluchaj - mam problem, bo to nie dziala tak jak chce. Siadzmy, pomyslmy - co 2 glowy to nie jedna."
- nie szukajmy tłumaczenia za pomocą powodu istnienia kłopotów - te były, są i będą - szukajmy sposobu ich rozwiązania :)

i na podsumowanie jeszcze 2 małe cytaty:
"Niemożliwe jest zbudowanie niezawodnego urządzenia - głupcy są zbyt pomysłowi."
"Prawo Liebermana: Aby oszacować czas potrzebny na wykonanie jakiegoś zadania należy przewidywany czas pomnożyć razy dwa i przyjąć jednostkę o rząd wyższą."Piotr Jędrkowiak edytował(a) ten post dnia 02.04.09 o godzinie 21:02
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Chłopaki,

Bardzo dziękuję za wszystki wypowiedzi, jesteście fantastyczni. Jestem bliżej niż dalej w swojej (nie)wiedzy na ten temat. :-) Znam wdrożenia od strony klienta - tzn. byłam nim, wewnętrznym lub zewnątrznym - więc wiem w praktyce jak wygląda stworzenie rozwiazania zamknietego.

Ale nie pracowalam nigdy na systemach, które z założenia są otwarte i do stalego przebiania (tu akurat z założenia chodzi o zmienne rynkowe i potrzeby klientów). Więc jeśli pracuje na takim systemie stale zmiennym, to bedąc klientem na co powinnam uważać np. podpisując umowę??? Podpisanie umowy z kimś z zewnątrz i potem stały development postrzegam jako spore ryzyko (spotkałam sie z tym w 1 firmie i system stworzony 15 lat temu blokował połowę działań innowacyjnych firmy, bo 1 manday kosztował tyle, ze nikt nie chciał wziąć za żaden odpowiedzialnosci), ale nie wyklaczam, ze coś takiego możę funkcjonować dobrze przy dobrze zbudowanej umowie.

Darek, piszesz o zasobach po obu stronach - na co tu zwrócić uwagę bedąc klientem?
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Stanisław Pitucha:
Nigdy nie słyszałem nazwy "lekka metodyka"...

Ja też :-)
Jedna z bardziej znanych stron które to zaczęły, to chyba http://www.extremeprogramming.org/ jeśli chcesz coś ogólnego.

po przejrzeniu wykresu stwierdzam, że jednak przy czymś takim pracowałam, tylko nie wiedziałam, że się tak mądrze nazywa. :-)

Nadal jednak nie wiem nic o kwestiach formalnych - tj. umowy, bo development poszczegolnych CRów i papierologia do poszczegolnych etapów wiem jak wygląda.
Link do wypowiedziLink
Stanisław P.

Stanisław P. Software designer

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
Stanisław Pitucha:
Nigdy nie słyszałem nazwy "lekka metodyka"...

Ja też :-)

Miało być "lekka metodologia ..." - pozajączkowało mi się ;)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Taka ciekawostka ktora moze Cie zainteresowac:
http://www.wrike.com/projectmanagement/11/27/2007/Scru...
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Rafał Ziółkowski:
Taka ciekawostka ktora moze Cie zainteresowac:
http://www.wrike.com/projectmanagement/11/27/2007/Scru...

Rafał,

Dzięki!
CZegoś lepszego chyba nie mogłam się spodziewać! :-)

Off topic: jak można się nauczyć lewitowania kul śnieżnych? :-)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Off topic: jak można się nauczyć lewitowania kul śnieżnych? :-)
Na poczatek trzeba znalezc odpowiedni snieg, niestety taki maja tylko w Norwegii :) A potem to juz prosta sprawa, wystarczy wmowic kazdej sniezynce z kulki ze jest chmurka, co pomijajac istnienie czasu jest oczywiscie prawda, wiec same sie garna do gory :)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

az tak bardzo sniezne kule podatne sa na perswazje? :) cos w tym jest :)
Link do wypowiedziLink
Przemek T.

Przemek T. Szef Zespołu
Technologii Online

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
[cut]
Ale nie pracowalam nigdy na systemach, które z założenia są otwarte i do stalego przebiania (tu akurat z założenia chodzi o zmienne rynkowe i potrzeby klientów). Więc jeśli pracuje na takim systemie stale zmiennym, to bedąc klientem na co powinnam uważać np. podpisując umowę??? Podpisanie umowy z kimś z zewnątrz i potem stały development postrzegam jako spore ryzyko (spotkałam sie z tym w 1 firmie i system stworzony 15 lat temu blokował połowę działań innowacyjnych firmy, bo 1 manday kosztował tyle, ze nikt nie chciał wziąć za żaden odpowiedzialnosci), ale nie wyklaczam, ze coś takiego możę funkcjonować dobrze przy dobrze zbudowanej umowie.
[cut]

Hej,
Jakiś czas temu rozmawialiśmy na temat "Scrum vs Kontrakty" na spotkaniu Scrum User Group Poland.

Dosyć ciekawe wprowadzenie Andy'iego do tematu:
http://www.scrum.org.pl/2009/02/24/po-czwartym-spotkan...

Może Ci się przyda.
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Piotr Jędrkowiak:
az tak bardzo sniezne kule podatne sa na perswazje? :) cos w tym jest :)
Taki juz snieg 8)
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:
Więc jeśli pracuje na takim systemie stale zmiennym, to bedąc klientem na co powinnam uważać np. podpisując umowę??? Podpisanie umowy z kimś z zewnątrz i potem stały development postrzegam jako spore ryzyko (spotkałam sie z tym w 1 firmie i system stworzony 15 lat temu blokował połowę działań innowacyjnych firmy, bo 1 manday kosztował tyle, ze nikt nie chciał wziąć za żaden odpowiedzialnosci), ale nie wyklaczam, ze coś takiego możę funkcjonować dobrze przy dobrze zbudowanej umowie.

Po pierwsze powinnas wziac pod uwage na ile ufasz firmie i osobom, ktorym to zlecasz. Z prostego powodu - to od nich zalezec bedzie dzialalnosc Twojej firmy i nie mozesz pozwolic sobie na "5 o'clock cut time".

Jezeli myslisz powazniej mozesz umowic sie na inwestycje za udzialy, wtedy stajesz sie czescia firmy swiadczacej Ci uslugi. Ma to niezaprzeczalne zalety, ale jest tez kosztowne czasowo i finansowo.

No i najwazniejsze - wazni sa ludzie, z ktorymi bedziesz pracowac. Firma moze chwalic sie swietnymi projektami i slowem nie wspomni, ze programisci i PM ktorzy je stworzyli juz dawno w niej nie pracuja (np. bo kiepsko zarabiali jak na swoje umiejetnosci) i prezes wymienil ich na innych "takich samych". A Ci "tacy sami" nie zrobili pewnie zadnego projektu od a-z tak, zeby klient byl zadowolony.

Sama forma zalezy juz od polityki firmy. Najgorsze opcja to taka, ze dostajesz oprogramowanie i pozniej placisz za man-day jak to ujelas. Duzo lepsza jest stala umowa serwisowa. W przypadku tej ostatniej dobrze jest upewnic sie ile osob bedzie prowadzilo support i na ile klientow (z nazwami firm) jest on rozlozony. Referencje warto potwierdzic u zrodel (czyli innych klientow firmy). Bardzo wazna zaleta jest tutaj przewidywalnosc wydatkow (i dochodow po drugiej stronie).

To podstawowe ogolne zasady.
Link do wypowiedziLink

konto usunięte

Temat: lekka metodologia wytwarzania oprogramowania

Sebastian Pienio:
Po pierwsze powinnas wziac pod uwage na ile ufasz firmie i osobom, ktorym to zlecasz. Z prostego powodu - to od nich zalezec bedzie dzialalnosc Twojej firmy i nie mozesz pozwolic sobie na "5 o'clock cut time".

No coż... wyznaję zasadę, że tylko pańskie oko konia tuczy. :-)

A co do reszty - bardzo to wszystko cenne co napisałeś i co inni napisali. Bardzo Wam wszystkim dziękuję. Teraz jak będę mieć problem, to zawsze będę się Was pytać. :-)

Życzę Wam wesołych, pogodnych Świąt :-)Ewelina Kitlińska edytował(a) ten post dnia 08.04.09 o godzinie 23:32
Link do wypowiedziLink
Dariusz Macina

Dariusz Macina Technology Manager,
Making Waves Polska

Temat: lekka metodologia wytwarzania oprogramowania

Ewelina Kitlińska:

No coż... wyznaję zasadę, że tylko pańskie oko konia tuczy. :-)

To moze w takim razie pomyslec o dobraniu do zespolu np. PM'a od strony klienta. Sam bralem w kilku takich projetach udzial i rozwiazanie dobrze sie sprawdzalo.
Na przyklad:
- PM ze strony klienta badz osoba nie zwiazana z wykonawcami
- analiza jedna firma,
- development druga firma
- caly projekt prowadzony u klienta

Pozdrawiam
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

SZKOLENIA DOFINANSOWANE W R...




Wyślij zaproszenie do
Anuluj