Module 1 IUT Bobigny : Organisation et Conception

ORGANISATION ET CONCEPTION
Gestion de projet web – Module 1

MODULE 1: ORGANISATION ET CONCEPTION
 ALM

Gestion de projet Web | IUT Bobigny 2012-2013 | Frédéric RIVAIN - frederic.rivain@gmail.com
 Méthodologie Agile, Scrum, Kanban
 Outillage : Git, Jira / Redmine, wiki
 Spécifications : expression de besoins,
normalisation, nomenclature, formalisation
 Conception web : responsive design, mobile first,
frameworks, outils

 Petit rappel : dans un contexte d’entreprise…
Projetez-vous ! 2

ALM : APPLICATION LIFECYCLE MANAGEMENT
 Nous allons globalement parler d’ALM :

 Pour créer une chaîne centralisée d’ingénierie logicielle
et de gestion de projet

3

5
AGILE ?

LES MÉTHODES DE GESTION DE PROJET
TRADITIONNELLES
 Cycle en V (en cascade)

 Cycles en spirale, itératif ou semi-itératif

 xUP (Unified Process) : méthode
définissant le cycle de vie d’un logiciel

 CMMI (Capability Maturity Model
Integration) : modèle de référence, un
ensemble structuré de bonnes pratiques,
destiné à appréhender, évaluer et
améliorer les activités des entreprises
d'ingénierie.

 Notions de MOA (Maîtrise d’ouvrage) et
MOE (Maîtrise d’œuvre)

6

4 FONDAMENTAUX DU MANIFESTE AGILE
1. Priorité aux personnes et aux interactions,

2. Priorité au développement des fonctionnalités,

3. Priorité à la collaboration avec le client,

4. Adaptation au changement.

7

8
LES PRÉCONISATIONS DU MANIFESTE AGILE

DÉCLINAISONS MÉTHODOLOGIQUES AGILE

 Scrum
 Kanban

 XP
(Extreme
Programming)
 RUP

 Ce sont tous des outils, à choisir et adapter au 9
contexte.

SCRUM : PRINCIPE
 Des petites équipes qui passent peu de

temps à construire des petites choses mais
intègrent régulièrement.

 Segmenter l’organisation : petites équipes
 Découper le produit en fonctionnalités
unitaires
 Organiser le temps en cycles court

10

SCRUM : VUE D’ENSEMBLE
 1 Process Model

 3 roles : Product Owner, Scrum Master, Team
 3 ceremonies : Sprint Planning, Daily Scrum, Sprint Review
 3 tools: Product Backlog, Sprint Backlog, Burndown Chart

11

SCRUM : RÔLES
 The Product Owner

 represents the interests of the customers and
other key stakeholders on the project
 is responsible for managing a prioritized list of
requirements and other work to be done by
the team

 The SCRUM Master
 must ensure that SCRUM practices are
correctly applied
 is responsible for helping the team to achieve
its goals

 The Team
 is responsible for implementing the
functionalities
 is self-organizing, self-managing and cross- 12
functional

SCRUM : 3 CÉRÉMONIES
 The Sprint Planning

 The Product Owner presents to the Team his wish
list of product items
 The Team defines and estimates the tasks to
perform for each item
 until it reaches its maximum sustainable workload
 The Team commits to deliver the planned items
for that Sprint

 The Daily Scrum
 Each day, the Team attends to a 15-minute stand-
up meeting
 to follow up the tasks currently undertaken
 to early detect and react to abnormal situations

 The Sprint Review
 The Team demonstrates the delivered features to
the Product Owner
 allows the Product Owner to accept or not the
delivered items
 The Scrum Master conducts a retrospective with
the whole team 13
 allows the Team to enhance its working practices

SCRUM : 3 OUTILS
 The Product Backlog

 List of items that represent the
functionalities to add to the system
 Defined, managed and strictly
prioritized by the Product Owner

 The Sprint Backlog
 Subset of the Product Backlog
expanded in low-level tasks
 estimated in hours (<16h) during the
Sprint Planning by the Team
 Defined and managed by the Team
during the Sprint

 The Burndown Chart
 Chart used to measure Sprint progress
 heavily relies on the definition of “done”
 The same chart can be used to
measure progress at the 14
release level

KANBAN : PRINCIPE
 Visualiser le flux de production

 Limiter le WIP (Work In Progress)
 Mesurer et optimiser le flux

 Issu des méthodologies des chaînes industrielles de Toyota

15

16
EXEMPLE DE KANBAN BOARD

SOURCE CODE VERSIONING
 2 main types:

 Local Version Control Systems: CVS,
Subversion (SVN), Perforce

 Distributed Version Control Systems:
Git, Mercurial, Bazaar

18
 Git platform

SOURCE CODE VERSIONNING BEST PRACTICES
 Commit early and often.

 Use a common project structure and naming
convention.
 Define versioning best practices:
 How to branch
 How to merge
 When to commit

 Setup hooks and scripts to automate repetitive
tasks.

19

PROJECT TRACKING: TOOLS
 Lots of different solutions with various scope:

 Open source solutions:
 Redmine http://www.redmine.org/
 Tuleap http://www.tuleap.com
 Chili project http://www.chiliproject.org/
 Commercial solutions:
 Jira http://www.atlassian.com/fr/
 TFS,by Microsoft
 Many other tools by IBM…

 Bug Trackers:
 Mantis http://www.mantisbt.org/

 Other production tools:
 Trello http://www.trello.com 21
 Phabricator http://phabricator.org/

PROJECT TRACKING: TIPS
1. You need a Project Tracking tool. Set it up and configure it according to your context.

2. Make sure task and bug status are up-to-date.
 For instance, set tasks “in progress” when you start working.

3. Log the work spent on a task daily to allow the Project Manager to track progress.

4. Report any difficulties or changes in your work as soon as possible to avoid delays and
frictions in the development process.

5. After each cycle, improve the capacity planning and the estimate accuracy.

6. Automatically generate release notes.

7. Automate a monthly project report of done tasks and upcoming tasks. Link it to the
general roadmap and schedule. 22

FOCUS ON JIRA

 From Atlassian, lots of features, user-friendly, separate
components (Greenhopper for Agile, Bonfire for testing, 23
Confluence for wiki)

FOCUS ON REDMINE

 Open Source and Free, lots of plugins, built-in Wiki, code
24
viewer, Gantt & Calendar

WIKI: WHAT FOR?
 Useful to:

 Work as a team on documentation
 Quick and Easy editing
 Categorize and relate pieces of information together
 Centralize information
 Share and spread the knowledge
 Available online

 Challenges:
 Keep information up-to-date and relevant
 Structure appropriately
26
 It is only as good as what people put in it!

WIKI: TOOLS
 Built-in wikis: in Jira (Confluence), Redmine,

Sharepoint…
 Mediawiki http://www.mediawiki.org

 Dokuwiki https://www.dokuwiki.org

 Choose your own:
 http://www.wikimatrix.org

27

OTHER USEFUL TOOLS
 Password tool:

 To centralize passwords for the whole team
(Teampass…)
 FTP server with web ftp access:
 To share heavy documents internally and externally
 Instant Messaging:
 IRC
 Skype / Google Talk / Lync

28

WHY DO WE NEED FUNCTIONAL SPECIFICATIONS?

 Good Functional Specifications are key to successful
projects
 To clarify what we want to do 30
 To make sure we took time to think it through
 To give clear requirements to the developers

LIST NEEDS AND REQUIREMENTS

List the needs of all stakeholders:
 What do they want? What do they need?

 What is the reason for those specifications?

31

START FROM A TEMPLATE DOCUMENT
 All specifications should be based on the same

template document (wiki template, Word template…)
This will facilitate your work.
This will make sure you produce consistent
functional specifications and high quality documents to
be shared internally and externally.

 Write in English!

32

DREAM THE IDEAL WORLD

 When writing your specifications, do not restrain
yourself based on technical or business reasons. Design it
as if you had “almost” unlimited budget and time.

 Specification scope will always be reduced, so think big.

 Your specifications should reflect your needs.

…but remain realistic  33

DESIGN USE CASES

 A key part of the functional specifications is to design
use cases: all scenarios where the feature will be used.

Take the tester point of view: try and translate it in
terms of acceptance criteria.
How would you and a tester validate your specifications?
What are all the possible cases? What are the limits and
exceptions?
 This can be done as a list of scenarios, as a tree of
possibilities.
 Provide examples and mockups.
34

35
Review the document with all stakeholders.
REVIEW AND UPDATE

Update.

Share.
1.

2.

3.

IMPLEMENT
 To begin implementation, you do not necessarily need final

specifications, but you do need enough data and you must make
sure all aspects were tackled and problems anticipated (risk
management).

 This is only the start: functional specifications must live and be
updated throughout the production process.

 Once the project is over, you should have a reference
document that reflects what was actually produced. It is your
role to make sure this is the case.

 Keep in appendix for future evolutions what was dropped from 36
the original scope of your dream world.

TECHNICAL DOCUMENTATION
“How is the software built?”

”Why is it built that way?”

 Before starting work on a new feature, take some time to think about it and write
down main conception details.

 This is a preliminary document to formalize before coding. Typically in the Wiki.

 Organize a technical review with another developer to proof read, check for
consistency and compatibility within the whole project. Try and anticipate
prerequisites, technical dependencies and potential pitfalls.

 Go to the point. Diagrams are better than text. Details will appear in comments
directly into the code.

 Iterate and update the conception document while working on the project.

 The conception document should be delivered along with the source code to
facilitate understanding and maintenance for future developers. 37

WEB DESIGN
 3 enjeux aujourd’hui :

 Etre portable : Le site doit être consultable sur tous les
supports connus (et à venir).
 Etre visuel : Communiquer grâce à des textes courts, des
images et de la vidéo, d’autant plus que ce type de
consultation est très apprécié sur mobile, tablette et
télévision.
 Rester simple : car la simplicité permet de véhiculer
efficacement les messages.

 D’où la démarche du Responsive Web Design

39

RESPONSIVE WEB DESIGN : UN PEU DE
VOCABLE

 Adaptive Web Design: generic idea of the web page adapting

to the browser context (see also progressive enhancement)
 Responsive Web Design : take into account the display (if
screen sizes vary, the web page changes)
 Responsive Layout : blocks are positionned dynamically
 Fluid Grid: columns adapt and expand based on browser width
 CSS3 & Media Queries: technical tools to implement RWD

40

CONCEVOIR EN RESPONSIVE
 Mobile first pour le fonctionnel :

définir les fonctionnalités
essentielles
 Déterminer les points de bascule
 HD first pour la créativité : enrichir
visuellement et graphiquement en
partant des hautes résolutions

41

ITÉRER
 Expérimenter

 Tester sur tous les devices

 Faire collaborer les différents métiers: graphiste,
ergonome, développeur…
 Trouver le meilleur compromis sur chaque plate-
forme
 Ayez une vraie stratégie de contenu

42

RESPONSIVE TOOLS
 Frameworks and templates

 Bootstrap http://twitter.github.com/bootstrap/
 Skeleton http://www.getskeleton.com/
 Foundation http://foundation.zurb.com/
 Less http://lessframework.com/
 Adaptive images http://adaptive-images.com/
 Design tools
 Balsamiq http://www.balsamiq.com/
 960 grid system http://960.gs/
 Test tools
 http://www.responsinator.com
 http://dfcb.github.com/Responsivator/ 43
 …and many more available…

EXERCICE 1 : AGILE
1. Dessiner un Kanban Board

2. Créer les grandes User Story, les tâches
associées
3. Créer un projet Jira / Redmine / Trello pour votre
projet
4. Simuler le sprint en cours

45

EXERCICE 2 : CODE SOURCE
1. Créer un compte utilisateur sur Github

2. Versionner votre code source dans Git
3. Créer plusieurs branches, faites des
modifications, commiter, merger

46

EXERCICE 3 : SPÉCIFICATIONS
1. Rédiger la trame de vos spécifications

2. A intégrer dans le wiki
3. Ebaucher une section de conception technique
(par exemple sur l’architecture responsive de
votre site. Voir exercice suivant)

47

EXERCICE 4 : RESPONSIVE WEB DESIGN
1. Concevez le prototype responsive de votre projet

2. Définissez les fonctionnalités clés en mode Mobile
First
3. Déterminez les points de bascule
4. Designez les différentes versions

48

AGILE, SCRUM, KANBAN, LEAN…
 http://www.crisp.se/ : voir toute la documentation de

ces auteurs
 http://agilemanifesto.org/

 Valtech Livre Blanc Agile :
http://valtech.fr/etc/medialib/library/it_consulting/fr/Li
vres_Blancs.Par.50587.File.dat/VALTECH-
LIVRE_BLANC_2012-WEB.pdf
 Agile for Dummies

50

CONCEPTION WEB, RESPONSIVE DESIGN…
 A lire:

 “Responsive Web Design” de Ethan Marcotte
 “Mobile First” de Luke Wroblewski

 http://www.nealite.fr/blog/expertise/agence-nealite-responsive-design-2-
6028.htm
 http://www.clever-age.com/veille/blog/responsive-web-design-du-point-de-
vue-du-chef-de-projet.html
 http://www.ultranoir.com/fr/#!/blog/web_3.0/responsive_design/

 Pour des transitions CSS :
 http://coding.smashingmagazine.com/2012/06/21/powerful-new-cssjavascript-
techniques/
 http://beta.theexpressiveweb.com/

 Website inspiration :
 http://www.awwwards.com/
 http://www.thebestdesigns.com/ 51
 http://onepagelove.com/

ET ENCORE…
 Blog Octo : http://blog.octo.com/

 Livre blanc Smile ALM : http://www.smile.fr/Livres-
blancs/Systeme-et-infrastructure/ALM-open-source
 Role of wiki in dev teams:
http://analysis102.blogspot.fr/2007/01/role-of-wiki-in-
dev-team.html

52

UN PETIT SITE POUR RETROUVER CE COURS
 https://sites.google.com/site/iutbobignyweb/

 Support de formation
 Liens utiles
 Coordonnées
 Formulaire d’évaluation

53

Module 1 IUT Bobigny : Organisation et Conception

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (9)

Semelhante a Module 1 IUT Bobigny : Organisation et Conception

Semelhante a Module 1 IUT Bobigny : Organisation et Conception (20)

Último

Último (20)

Module 1 IUT Bobigny : Organisation et Conception