Software Engineering and Architecture

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• The highest priority is to satisfy the customer through early and continuous delivery of valuable software
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliveer working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the ob done.
• The moste efficient and effective method of conveying infromation to and within a development team is face-toface conversation.
• Woring software is the primary measure of progress
• Agile processes promote sustainable develpment. The sponsors, develepers, and users should be able to maintain a constant pace indefinitely.
• Continzous attention to technical excellence and good design enhances agility.
• Simplicity- the art of macimizing the amount of work not done - is essential
• The best architectures, requirements, and designg emerge from self-organizing tems.
• At regular intervals, the team revlects on how to become more effective, then tunes and adjusts its behavior accordingliy.

In the agile methodology used for software prjects. It is based on 11 Priciples structured in 3 Areas:

• Problem (risks in development projects)
  • 4 variables
  • cost of change
• Core Values
  • Feedback
  • Communication
  • Simplicity
  • Courage
  • Respect
• Activities
  • Listening
  • Coding
  • Testing
  • Designing

• Schedule slips
• Project cancled
• System does not evolve gracefully (defect rate increases)
• Defect reate
• Business misunderstood
• Business changes
• False feature rich
• Staff turnover

The role of XP is to give us priciples and practices in order to deal with these risks!

• 4 variables (and their relations):
  • Time (results out of the next 3 variables)
  • Resources
  • Quality
  • Scope
• External forces (customers, managers) can set the values for 3 of the variables.
• The develpment team sets the value for the 4th one.

• Communication
• Simplicity
• Feedback
• Courage
• Respect

• We wqill do what is needed and asked for, but no more
• This will maximize the value created for the investment made to date
• We will take small simple steps to our goal and mitigate failures as they happen
• We will create something we are proud of and maintain it long term for reasonable costs

• Everyone is part of the team and we communicate face to face daily
• We will work together on everything from reqirements to code
• We will create the best solution to our problem that we can together

• We will take every iteration commitment seriously by delivering working software
• We demonstrate ou rosftware early and often then listen carefully and make any changes needed
• We will talk about the project and adapt our process to it, not the other way around

• We will tell the truth about progress and estimates
• We don't document excuses for failure because we plan to succeed
• We don't fear anything because no one ever works alone
• We will adapt to changes when ever they happen

• Everyone gives and feels the respect they deserve as a valued team member
• Everyone contributes value even if it's simply enthusiasm
• Developers respect the expertise of the customers and vice versa
• Management respects our right to accept responsitility and receive authority over our own work

• Fundamental principles
  • Rapid feedback
  • Assume simplicity
  • Incremental change
  • Embracing change
  • Quality work
• Other principles
  • teach learning
  • Small initial investment
  • Play to win
  • Concrete experiments
  • Open, hoest communication
  • Work with people's instincts, not against them
  • Accepted responsibility
  • Local adaptation
  • Travel light
  • Honest measurement

• The plannig game
• small releases
• Metaphor
• Simple design
• Testing
• Refactoring
• Pari programming
• Collective ownership
• Continuous integration
• 40 hours week
• On-Site customer
• Coding standards

• Balance between business and technical considerations
• Business people decide about:
  • Scope+Priority+Compositoin of releases+Dates of feleases
• Technical people decide about:
  • Estimates+Consequences+Process+Detailed Scheduling

• Every release should be as small as possible, containing the  most valuable business requirements
• The release has to make sense as a whole (no half-working features)
• Better to release once a motnh than twice a year.

• Everybody on the team needs to have a "common understaning" for the system
• Everybody on the team needs to have a "shared vocabulary"
• This applies to technical and non-technical people
• What are the basic elements of the system and what are their relationships?

• The right design for a software system is one that:
  • Runs all tests
  • Has no duplicated logic
  • Has the fewest possible classes and methods
• "Pu in what needed when you need it"
• Emergent, growing design; no big design upfront (through refactoring)

• Any program feature without an automated test simply doesn't exist
• The tests become part of the system
• The tests allow the system to accept change
• Develpment cycle:
  • Listen (requirements)
  • Test (write first)
  • Code (simplest)
  • Design (refactor)

• When implementing a feature, ask yourself if there is a way to improve the existing source code, so that implementing the feature is easier
• Automated tests provide a safety-net for refactoring without fear

• All production code is written by two people looking at one screen, with one keyboard and one mouse
• Two roles. The programmer on the keyboard focuses on the current method. The other programmer thinks aobut the broader context (refactoring, etc.)
• Pairs change requently

• Anybody who sees an opportunity to add value to any portion of the code is required to do so at any time
• Everybody takes responsibility for the whole of the system. Not everyone knows every part equally well, but everyone knows something about every part

• Code is integrated and tested at least once a day (sometimes more)
• Build process must be automated, on a dedicated machine
• Automated tests are run and make it possible to identify problems early

• Sustainable development. Effort should be spread out evenly
• Extended periods of overtime have a negatice impact on productivity
• Goal: Be fresh every morning, be tired and satisfied every envening
• Not being in front of a computer does not mean forgetting about the system... Taking a step back often leads to "Aha!" moments

• A real customer must be physically with the team, available to answer their questions
• Real customer = user who will use the system
• The real customer does not work on the project 100% of his time, but need to be "there" to answer questions rapidly
• The real customer also helps with prioritization

Collective ownership+constant refactoring means that coding practices must be unified in the team.

• There is still no "magic" process that would work exactly the same way for every project, in every environment
• Agile methodologies and XP describe core values and key principles that you need to integrate and customize in your particular context
• Agile teams need to continuously reflect on their work
• XP looks like it is less "formal" than tradidtional methodologies. But while there are cerainly less roles, less workflows and less artifacts, CP reqires a lot of discipline to work well.

The scrum is a popular way of restarting play from the middle of the field during a game of rugby union football. In a scrum, the two teams of forwards lock shoulders and push against each other, attempting to gain ground and kick the ball to heir scrum-half with their feet. The ball is then passed to the backs who try to advance with it or kick for goal. 

• Scrum is an agile process that allows us to focus on delivering the highest business value in the sortest time
• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month)
• Every two weeks t a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint

• Self-organizing teams
• Product progresses in a series of month-long "sprints"
• Requirements are caputred as items in a list of "product backlog"
• No specific engineering practives prescribed
• Uses generative rules to create an agile environment for delivering projects
• One of the "agile processes"

• Process Control Theory: Two approaches to control and manage processes
  • Defined process control model: Simple processes with unobtrusive noise repeatable
  • Empirical process control model: Complex, noisy processes, not repeatable
• Noise category indicates what process should be used
• Attention: Almost no system development process is so simple, has so little noise, for the defined process control model to be appropriate!
• Empirical processes are managed through frequent inspection and adaptive control

• The requirements
• A list of all desired work on the project
• Ideally expressed such that each item has value to the users or customers of the product
• Prioritized by the product owner
• Reprioritized at the start of each sprint

• Scrum projects make progress in a series of sprints
  • Analogous to Extreme Programming iterations
• Typical duriation is 2-4 weeks or a calender motnh at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint
• No changes allowed during a sprint
• Plan sprint durations around how long you can commit to keeping change out of the sprint (Typically 2-4 weeks)