Workflow en structuur

[mpol]

Hoi,
Ik ben nu bezig met mijn eerste grote opdracht, waar ik nu zo'n 2 maanden aan werk en zeker nog wel een maand. Mijn deelopdracht is een html/css ontwerp in een CMS zetten.
Nu was mijn structuur van werken zo dat ik eerst een groot deel van de php code geschreven heb, widgets en pagina templates. Daarna een groot deel van de inhoud geplaatst heb en nu bezig ben met het afstylen ervan. Er waren momenten dat ik moeite had met overzicht houden en perspectief blijven zien, en ik kreeg van collega's te horen dat ik beter in deelopdrachtjes kon werken. Dus een onderdeel programmeren, zoals een widget, en deze dan ook volledig afstylen.

Hebben jullie een structuur in je werken, en hoe pak je dit aan? Wat zijn de voor- en nadelen van elke manier?

Nu had deze opdracht ook met meerdere mensen gedaan kunnen worden, ik bijv. om de php te programmeren, en iemand anders om de css daarop aan te laten sluiten. Maar dat is niet gebeurd en daar is het nu te laat voor.

[Styxxy]

Het is moeilijk te zeggen wat je eerst moet doen. Het hangt wat van de situatie af, maar als ik een "all in one" project doe, volg ik meestal volgende stappenplan.
- Creëer volledige template (dus volledige slicing en verschillende pagina's maken in HTML/CSS).
- Alle PHP zaken afhandelen zodat dat werkt.
- Template volledig integreren.

Nu moet ik wel zeggen dat ik vaak stap 2 en 3 samen doe. Echter, ik probeer er altijd voor te zorgen dat de lay-out toch al klaar is vooraleer ik begin te "programmeren". Op die manier kan ik me tijdens het programmeren eerder focussen op de functionaliteit in plek van op de lay-out.

Zoals eerder gezegd, ik ben geen professional, maar ik heb toch al wel wat ervaring in webdevelopment. Tot nu was bovenstaande structuur erg aangenaam om binnen te werken (voor mij!). Er zullen zeker nog andere methodologiën zijn, en ik denk dat de meeste wel goed is. Het belangrijkste van al is, dat je je vast houdt aan de structuur. Probeer niet té veel verschillende jobs door elkaar te gooien. Zo verlies je al snel het overzicht en loopt alles wat in een soepje.

[mpol]

Bedankt. Dat is eigenlijk ook wel hoe ik het gedaan heb, eerst de belangrijke divs in een template, daarin de functionaliteit van de php en daarna integreren.
Alleen tijdens het php programmeren werd ik wel vaak afgeleid ook door de css, en sprong ik een beetje van hier naar daar, wat niet handig was.

[MueR]

Ik gooi deze even over de schutting naar Programming, daar past het m.i. wat beter.

[Camulos]

Ik denk dat je een fase vergeten bent

Mijn workflow is meestal zo:
- Analyseer probleem / taak
- Specificeer oplossing met requirements (kan een functioneel ontwerp zijn maar kan ook een opsomming zijn van een aantal belangrijke punten)
- Verdeel werk, met deadlines (met koppeling aan eerder gespecificeerde requirements)
- Werken werken werken ^^
- Terugkoppeling + samenstellen
- Afwerken van oplossing/eindresultaat (eventueel opnieuw dit proces opnieuw doorlopen).

Het belangrijkste imo is dat je afspraken maakt over hetgeen dat je moet opleveren (in jouw geval HTML/CSS ontwerp omzetten). Wanneer je specificeerd wat er gevraagd wordt, helpt dit met de algehele workflow. Zeker zodat er achteraf niet gezegd kan worder dat je niet het juiste op hebt geleverd (of anders had moeten doen).
Een ander voordeel is dat jij je kunt focussen om wat belangrijk is zonder dat je meteen afdwaald naar onnodige/niet gevraagde features.

In principe is het aan de programmeur hoe je het aanpakt ^^ zolang je het maar gedaan krijgt.

In jouw geval zou ik zijn begonnen met een algemene template die de be-oogte functionaliteit ondersteund. Daarna deze voorzien van een back-end (in PHP).. nu het algemene gedeelte af is kun je de widgets/modules bouwen

[ Voor 9% gewijzigd door Camulos op 24-01-2011 10:48 ]

[Verwijderd]

Ik werk vaak zelf in een opzet die grotendeels op scrum le, ook voor de projecten die ik alleen doe. Een project verloopt dan meestal zo :

- probleem/taak analyse -> opdelen in backlog items / user stories , dit zorgt in feite al voor een functioneel ontwerp. Ook worden hierbij de prioriteiten gedefinieerd.

- definieren van fasen (sprints genaamd), iedere sprint bestaat uit het oplossen/verwerken van een aantal backlog items, aan het eind van een sprint zou het de bedoeling moeten zijn een werkend geheel te hebben, al heeft het dan niet alle features die het zou moeten hebben.

- na iedere sprint wordt er een tussentijdse evaluatie gedaan meestal door de klant, de feadback hierop wordt omgezet naar nieuwe/gewijzigde backlog items en er wordt weer een nieuwe sprint gedefinieerd.

Dit systeem is erg simpel en helder, of je nu alleen of in teams werkt. Ook het inzichtelijk maken van vooruitgang en uitloop is vrij eenvoudig door het maken van een burndown chart.

Mijn ervaring is door een aantal simpele regels te handhaven er minder fouten gemaakt worden en minder dingen vergeten zijn omdat die tussen neus en lippen afgesproken worden, of doordat een klant tijdens de productiefase opbelt om te vragen of X 'nog even' aangepast kan worden.

[Guldan]

Als je meer wilt weten over scrum kan je deze video goed bekijken:

http://www.youtube.com/watch?v=Q5k7a9YEoUI

[Verwijderd]

@Guldan ... erg goede video .. kende ik nog niet.

YouTube: Agile vs. Waterfall: A Tale of Two Teams (Agile vs Waterfall) laat goed zien waarom de waterval techniek niet altijd even geschikt is.