Typical JEE development process, stack

Agile development using SCRUM methodogy

In the Scrum method of agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints. But how long each sprint lasts is something for the team to decide, who must weigh the advantages or disadvantages of a longer or shorter sprint for their specific development environment. The important thing is that a sprint is a consistent duration.

During each sprint, a team creates a shippable product, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality. However, placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. Because a release requires many sprints for satisfactory completion, each iteration of work builds on the previous. This is why Scrum is described as “iterative” and “incremental.”

Every sprint begins with the sprint planning meeting, in which the Product Owner and the team discuss which stories will be moved from the product backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work the team will do, while the team retains the autonomy to decide how the work gets done. Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage.

During the sprint, teams check in at the daily Scrum meeting, also called the daily standup. This time-boxed meeting gives teams a chance to update project status, discuss solutions to challenges, and broadcast progress to the Product Owner (who may only observe or answer the team’s questions).

Just as every sprint begins with the sprint planning meeting, the sprint concludes with the sprint review meeting, in which the team presents its work to the Product Owner. During this meeting, the Product Owner determines if the team’s work has met its acceptance criteria. If a single criterion is not met, the work is rejected as incomplete. If it satisfies the established criteria, then the team is awarded the full number of points.

Because certain sprints are hugely successful and others less than ideal, a team also gathers at the end of each sprint to share what worked, what didn’t, and how processes could be improved. This meeting is called the sprint retrospective meeting.

1. Architecture and design scenario
1. architecture concepts
2. architecture definition
3. proof of concepts
2. Setting up development environment
3. data modelling
4. analysis and design
1. class diagrams - inheritance, association, aggregation, composition
2. usecase diagrams
3. deployment diagrams
5. development - reusable components, continuous integration, build automation
6. WebServices
1. SOAP web services - stacks, security, 
2. Restful - stacks, security
3. Code first Vs contract(WSDL) first approaches
7. xml binding
8. Stateless session beans
9. design patterns
10. ORM - JPA - Hibernate
11. Continuous integration (CI)
1. Developers check out code into their private workspaces.
2. When done, the commit changes to the repository.
3. The CI server monitors the repository and checks out changes when they occur.
4. The CI server builds the system and runs unit and integration tests.
5. The CI server releases deployable artefacts for testing.
6. The CI server assigns a build label to the version of the code it just built.
7. The CI server informs the team of the successful build.
8. If the build or tests fail, the CI server alerts the team.
9. The team fix the issue at the earliest opportunity.
10. Continue to continually integrate and test throughout the project.
11. Tools used for CI
1. Deployed jenkins.war in Tomcat
2. Configure ANT and Maven in Jenkins
3. Setup Jenkins jobs to build projects
4. http://www.vogella.com/tutorials/Jenkins/article.html
12. build automation