Zdecydowanie nie zgadzam się z odpowiedzią Jasona. Cały sens Scrum jest pozbycie się metody, w której projektanci najpierw "robią swoje", a następnie przejść do innych rzeczy. To całkowicie i w 100% wbrew wszystkim zasadom lean / Scrum!

Sposób na włączenie projektantów w proces Scrum? Wrzuć je do miksu! Upewnij się, że nie tylko owijasz projekt wodospadu w Scrum, ponieważ jest to najlepszy sposób na porażkę! Scrum działa tylko wtedy, gdy jest zaimplementowany bez wyjątki. "Scrum, ale..."jest najgorszym modelem projektu. Zorganizuj pracę tak, aby możliwe było jednoczesne projektowanie i rozwijanie. Nie przesadzaj z początkowym projektem, ale zrób z niego sytuację push-pull, w której obie strony monety wpływają na drugą. Celem Scruma jest iteracja, iteracja i iteracja, więc w pełni z tego skorzystaj.

Poza tym, całkiem chude jest unikanie tradycyjnego projektu opartego na Photoshopie. Możesz przeczytać więcej na ten temat z tego doskonałego wpisu na blogu w Sygnał a szum: http://www.37signals.com/svn/posts/1061-why-we-skip-photoshop

Robiłem to już wcześniej, gdy projektanci robili swoje rzeczy we wczesnych iteracjach, a ich produkt roboczy był używany przez zespół programistów w późniejszych iteracjach. Gdy zespół programistów rozpoczął pracę, projektanci przeszli do innych części projektu lub ewentualnie do innych projektów.

Myślę, że przywykliśmy do oglądania dużych obraz i jazda w jego kierunku

Nadal możesz to zrobić. Twoi projektanci mogą wykonać większy projekt z przodu, a zespół programistów może użyć Scrum / align = "left" /

Do części projektowej w sprint 0 możesz użyć techniki takiej jak Styletyles ( http://styletil.es ) w celu określenia stylu graficznego potrzebnego dla projektu. Więc nie trzeba duży projekt z góry i nadal być zwinny podczas sprintu.

It ' s easy peasy! :) No to podzielę się jak to robimy.

Pierwszy Sprint

1) Product owner tworzy wire-frames i dodaje do Backlogu (używamy Yodiz, www.yodiz.com) 2) nasz grafik tworzy makiety i umieszcza je w narzędziu do udostępniania makiet (www.concept.ly) 3) nasi programiści pracują nad konfiguracją serwerów. Jeśli wszystko jest już gotowe, mamy całkiem inteligentnego Product Ownera, zawsze będziesz mieć przedmioty w zaległościach do wyboru.

Sprint 2

1) programista rozpoczyna pracę na ukończonych makietach, które zostały ukończone na 2) praca projektanta na innej ramce drucianej dodanej przez product owner w Backlogu.

Mówiłem, że to proste!

Chciałbym się podzielić . Jestem mistrzem scrum dla zespołu programistów przyszłej aplikacji społecznościowej. Ten zespół ma w nim 1 User Interface designer, 1 User Experience designer(me), 1 Front end developer (css,ajax itp.) i 3 programistów.

To nasz pierwszy projekt wykorzystujący framework SCRUM, więc był to dość trudny projekt. Trend podczas naszych codziennych spotkań scrum polega na tym, że nasze prace projektowe nigdy nie są do końca wykonane, ponieważ nasze początkowe zaległości produktowe miały historie takie jak " użytkownik chce być przekonani do rejestracji", a następnie dodaliśmy do tej historii "sposób na demo", więc stamtąd możemy określić, co należy zrobić (tj. musimy zrobić wireframe, mieć copywriting zrobione, itp...)

To, można zrobić lepiej. Wyszczególnij każde zadanie na podstawie tej historii i oszacuj czas dla każdego zadania. Na przykład, podczas zaległości produktu, możemy stamtąd tworzyć je w kolejności: mapy witryny > przepływy Zadań > Wireframes

Teraz pytanie, czy robimy to wszystko w sprincie? A może powinniśmy to nawet przed każdym sprintem? Pokonuje cel scrum, jeśli zrobimy z sprintów, prawda?

Ci, którzy wykonali user experience design, będą wiedzieć, że przygotowanie tych zadań zajmuje sporo czasu. Więc dlaczego nie zrobić tych wszystkich części sprintu, jak również? Zaangażuj również programistów w te zadania.

Wireframing jest bardzo ważne przez cały czas trwania projektu. To jak plan budynku, gdzie jest używany od początku do końca.

Więc zrób wstępna struktura szkieletowa oparta na zaległościach produktu podczas pierwszego sprintu. I odpowiednio dopasować szkielet podczas każdego innego sprintu. Nasi programiści zaprojektują swój kod w oparciu o przepływ zadań, a następnie stworzą go wizualnie na podstawie szkieletu.

Oh, btw, nie przejmuj się zbytnio tym, jak produkt będzie wyglądał (skoro posiadanie intialnej makiety projektowej jest zawsze dobrą rzeczą). Zamiast tego skoncentruj się na potrzebach i pragnieniach użytkownika i zaprojektuj bardzo zorientowany na użytkownika przepływ, aby osiągnąć tylko to. Nasz projektant później zorientuje się, jaki rodzaj interfejsu zamierza opracować. Jeśli szkielet został wykonany prawidłowo, projektant będzie miał bardzo niewiele problemów z zaprojektowaniem interfejsu użytkownika. To samo dotyczy tworzenia copywritingu.

Podsumowując, pracuj ręka w rękę podczas każdej iteracji. Dla początkujących tam (jak ja) dać szansę SCRUM pracować dla Ciebie. Jeśli może działać dla takich firm jak fantasyinteractive.com , więc może działać dla Ciebie N mnie:)

P. S. za wielkie wireframes, use omnigraffle (mac) tis the shite!

Gdybyśmy mieli wykorzystać metody Scruma, jak przebiegałby ten rozwój?

Chociaż ten post jest dość stary, skłonił mnie do samodzielnych badań. znalazłem "dwanaście wschodzących praktyk" Jeffa Pattona dla projektantów/praktyków UX, które uważałem za trafne do tego pytania i całkiem przydatny zestaw ramek: {]}

1. Drive: praktycy UX są częścią zespołu klienta lub właściciela produktu.
[7]}badania, model i projektowanie z góry-ale tylko wystarczy.
2. Pokaż swoje prace projektowe
3. Użyj równoległego rozwoju toru, aby pracować do przodu i podążać za nim.
4. kup czas projektowania dzięki złożonym historiom inżynierskim.
5. Utwórz grupę walidacji użytkowników do użytku w celu ciągłej walidacji użytkowników.
6. Zaplanuj ciągłe badania użytkowników w oddzielnej ścieżce od rozwoju .
7. Wykorzystaj czas użytkownika na wiele działań.
8. Użyj RITE do iteracji interfejsu użytkownika przed jego rozwojem.
9. prototyp w niskiej wierność.
10. traktuj prototyp jako specyfikację.
[7]}Zostań moderatorem projektu.