In the thursday keynote at Devoxx, Mark Reinhold (from Sun) presented the new features slated for the Java 7 release. (the expected release date of Java 7 is early 2010)
One of the most important new features will be the modularization of Java SE7. Modularization is needed because both Java and the JDK have become quite big. This for example gives issues when trying to run it on smaller (mobile) devices. Cutting the JDK into modules will avoid loading unnecessary classes, which on their turn result in shorter start-up times for applications. To print a simple string “Hello world”, Java needs over 300 classes in the current version!.
A list of the other new features can be found here!
Scrum defines three different roles: the Product Owner, the Team and the Scrum master.
The product owner, who’s responsible for the project, has the following tasks:
he defines the product vision and features
he plans releases (release dates & contents of a release)
he prioritizes the needed features in a release according to business/market value
he’s able to change features and priority of the tasks before the start of every iteration (not during the iteration)
at the end of a release he accepts or rejects the work results
he’s responsible for the return on investment of the product.
The team is responsible for the success of every iteration done in a release. Ideally the team consists out of 5 to 9 members. Different profiles are needed: developers, testers, QA guys, infrastructure guys, …
What does the team needs todo?
they need to select the iteration goal and specify work results
they have the right to do everything within the boundaries of the project guidelines to reach the iteration goal
they organize themselves and their work
they demo the work results to the product owner and stakeholders
The scrum master makes sure that the SCRUM process is followed and understood.
Besides that he also:
helps the dev team to improve its productivity by facilitating creativety and empowerment
helps the team improve engineering practices & tools so each increment of functionality is potentially shippable
helps the customer directly drive the functionality developped
enables close cooperation between all roles
The full scope of the project is put into a Product Backlog; the list of features to be implemented. This product backlog is input for the Sprint planning meeting.
The sprint backlog defines the scope of one iteration and is derived from the product backlog. It’s defined during the Sprint planning meeting. In this meeting the product owner presents to the team a prioritized product backlog. The team gives estimates of the stories selected for this sprint.
Stories are compared to each other and relative points are given based on the complexity of the stories. (higher points => more complexity). The Product owner and Team negotiate the Sprint goal and the team commits to develop a set of features. Based on these stories the team plans out smaller subtasks.
During the sprint the scope is fixed. It’s the task of the scrum master to protect the team from scope changes. (only the team itself is allowed to change the scope of the sprint!)
Generally a sprint takes 2 to 4 weeks. During the sprint, there is a daily scrum meeting; a short standup meeting where every team member will talk about what he’s busy until next meeting, what he did yesterday and any problems he encountered.
The sprint produces an increment of potentially shippable functionality containing analysis, design, coding, testing and docs.
During the Sprint a burndown chart is created: it displays the amount of work done & work remaining across time. (start with max. number of story points at day 1; then substract story points when a story is fully finished during the sprint time). This allows you to see the progress rate and estimated completion date. One can also see if the team is faster/slower then the “steady pace”. (purple line)
When the Sprint is finished; there is a sprint review meeting (a demo to the stakeholders) and a sprint retrospective meeting (a lessons learned meeting)
During the Sprint review meeting the team gives a demo to the product owner with the output of the iteration. Ideally this should be done in a pre-prod or production environment.
Present only what is “really” done (clean, refactored, unit-tsted, built, acceptance-tested); otherwise you’ll give a false impression that more is done then what’s reality.
A Sprint retrospective is a kind of Lessons learned meeting: continous improvement by collecting what went well & what went wrong during the Sprint.
You can also revise the development process to make it more effective & enjoable for the next sprint. (eg. processes, practices, communication, environment, artefacts, tools,…)
A release consists of one or more sprints. The contents of a release are based on the continuously updated product backlog. It’s the product owners responsibality to fill in the release, taking into account the actual team velocity. (eg. this team can do 25 points per sprint).
Release planning can be done Time driven (if your release should be ready on a fixed deadline) or feature driven. (select the highest priority items first).
Scrum from theory to practice
You may have difficulty going from theory to practice due to any of the following reasons:
transitioning to an agile culture
finding a product owner
lack of communication between people
cross organizational boundaries
Scrum doesn’t pretend to solve those issues in your organization, but will make them visible a lot earlier in the project.
An ideal product owner should be able to:
coordinate the various user requirements
articulate the vision of the project
make scope decisions
be a project sponsor: negotiates & manages the budget
define priorities and releases
allocate time for collaboration with the team
For cross department communication, try to get domain/technical experts assigned on the project full-time (can also be part-time if full time is not possible).
The title of this talk is a little bit mysterious if you don’t know what Comet is about, but the content is looking very interesting.
The first part of the talk will be about HTML5 WebSockets and Server Side Events. WebSockets will enable full-duplex HTTP communication, and bring an end to the “click and wait” paradigm traditionally associated with the Web.
The second half of this university session will be about deploying and scaling “real-time” Web Applications. Eg. the server and network architecture, performance requirements and scalability of a bi-directional Web application will be discussed.
Interested in the new Google Android phone? Then you certainly should not miss this univerity session by Romain Guy.
Romain Guy, who’s now working on the UI design of the Android phones as a Google engineer, always manages to impress the crowd with cool demos and knows what it takes to design a intuitive user-interface.
(which is more important than most programmers think!)
Chet Haase, who works on animation and UI components for the Flex SDK team at Adobe Systems, will likewise describe how to achieve beautiful Filthy Rich Client applications for Flex.
Java tutorials and tips