Engineering vs. Science
Traditional World’s Waterfall-based Software Development Approach
Waterfall Process Assumptions
Why a Pure Waterfall Process is Usually Not Practical
Waterfall Process Limitations
Iterativeand Incremental Development
The 12 Key Practices
2. Test-Driven Development
3. Pair Programming
5. Simple Design
6. Collective Code Ownership
7. Continuous Integration
8. On-Site Customer
9. Small Releases
10. 40-Hour Work Week
11. Coding Standards
XP Planning Game
XP Iteration Plan
Requirements in XP
XP Rules and Practices
When to Use XP
Scrum in 100 words
What is Scrum?
Scrum -a Lightweight Process
Managing the Sprint Backlog
Sprint Burndown Chart
What is CMMI?
5 Reasons for Applying Kanban
•Scientists: –Learn what is true –How to test hypotheses –How to extend knowledge •Engineers: –Learn what is true –Learn what is useful –Learn how to apply well-understood knowledge to solve practical problems
•Systems are developed in a sequential process (at times even in a single pass). •All requirements are determined up front, with the dual assumptions that they can all beknown up front, and that they are and will remain unchanging. •Analysis is done once, and precedes design. •Design is done once, and precedes coding. •All coding is done once, and precedes testing and integration. •All testing is done once followed by or in conjunction with integration activities, and precedesoperational use. •Formal review and approval is required to proceed from any one step to the next. •The customer is most involved setting the requirements, mostly disappears during analysis, design, and coding, and re-emerges during test and acceptance. •Extensive documentation is required for each and every step.
•The earlier we plan, the less accurate our plan is (even when sophisticated estimation models and historical data are used, which often they are not) –so when we define a nice project plan up front, we get the least accurate plans. •This is called the Cone of Uncertainty (and it is actually worse, more random than depicted here). •This is particularly acute in knowledge-based projects such as software development. •When things don’t work out as planned –and they never do –what happens?
•Requirements are known up front before design •Requirements rarely change •Users know what they want, and rarely need visualization •Design can be conducted in a purely abstract space, or trial rarely leads to error •The technology will all fit nicely into place when the time comes (the apocalypse) •The system is not so complex. (Drawings are for wimps)
?Don’t know up front everything wanted and needed oUsually hard to visualize every detail in advance ?We can only estimatethe costs of implementing requirements oTo gain confidence in an estimate, we need to design and actually implement parts, especially the riskiest ones oWe will probably need to modify requirements as a result ?We often need to execute intermediate builds oStakeholders need to gain confidence oDesigners and developers need confirmation they're building what’s needed and wanted ?Team members can't be idle while the requirements are being completed oTypically put people to work on several phases at once
•Big BangDelivery Theory •The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced. •Late deployment hides many lurking risks: –technological(well, I thoughtthey would work together...) –conceptual(well, I thoughtthat's what they wanted...) –personnel(took so long, half the team left) –User doesn't get to seeanything real until the very end, and they always hateit. –System Testing doesn't get involved until later in the process.
•Iterative and incremental development involves –the successive refinement of the understanding of the problem, –the solution's definition, and –the solution's implementation by the repetitive application of the core development activities. •It is incremental in that each pass through the iterative cycle grows the understanding of the problemand the capability offered by the solution. •Several or more applications of the iterative cycle are sequentially arranged to compose a project.
•Each iteration produces a more complete release than the previous iteration. •In each iteration, thefocus is on the production of a working release and not some set of project documents or un-integrated components. •It is essential that the team's progress is considered as a whole, via the testing of the integrated release.
•Each iteration will present developers with the opportunity to elicit objective feedback on the appropriateness of thesolution and the business impact that it is likely to have. •By basing the feedback on demonstrations of working versions of the system, the communication is kept focusedand to the point, allowing the development to converge upon a solution that meets the system's essential minimal characteristics. •Each iteration will present developers with the opportunity to elicit objective feedback on the appropriateness of thesolution and the business impact that it is likely to have. •By basing the feedback on demonstrations of working versions of the system, the communication is kept focusedand to the point, allowing the development to converge upon a solution that meets the system's essential minimal characteristics.
•We cannot perfectly predict a software schedule •As users see the software, they come up with newideas •Developers have a notoriously hard time estimating •If we can’t perfectly predict a schedule, we can’t perfectly say what will be delivered Why UserStories? •Emphasize verbal communication •Comprehensible by everyone •Right size for planning •Encourage deferring detail (less waste) •Participatory design
•The Planning Game •Small Releases •Metaphor •Simple Design •Test-Driven Development •Refactoring •Pair Programming •Collective Ownership •Continuous Integration •40-Hour Workweek •On-site Customer •Coding Standards
•Guide all development and conversations with a simple shared story of how the whole system works –Gives the team a whole picture of describing the system, where new parts fit, etc. •Words used to identify technical entities should be chosen from the metaphor •The default metaphor is the business domain, and it’s usually just fine •In the beginning of a software project the fundamentalvision and mission should be determined and describedin a fundamental metaphor. •Beck describesthe system metaphor as a “story that everyonecan tell about how the system works” . •Specificaspects of a system can be described in subordinated,but more concrete metaphors. •Finding an appropriate metaphor relies on involving allsuccess-critical stakeholders, discussing their different •Views and negotiating all relevant details like the keyobjects of the domain and their interaction. •The metaphoris a crucial ‘ingredient’ of the shared system vision as it helps to align all involvedstakeholders towardsthe same goals and architectural foundations,and harmonizes the common project language. •The metaphor is the underlying foundationfor the requirements to be developed and can be subject to change during development as the requirementsthemselves.
•Developers write unit tests before coding •Motivates coding –Improves design: cohesion and coupling –Provides regression tests –Provides specification by example •TDD is hard. It takes a while for a programmer to get it. In fact, in many cases it doesn’t really matter how much you teach and coach and demonstrate –in many cases the only way for a programmer to get it is to have him pair program with somebody else who is good at TDD. Once a programmer does get it, however, he will usually be severely infected and will never want to work in any other way. •TDD has a profoundly positive effect on system design. •It takes time to get TDD up and running effectively in a new product, especially black-box integration tests, but the return on investment is fast. •Make sure you invest the time necessary to make it easy to write tests. This means getting the right tools, educating people, providing the right utility classes or base classes, etc.
•Twoprogrammers work side-by-side at onecomputer •Continuously collaborate on same design, algorithm, code, test, etc. •Continuous informal review •Two software engineers work on one task at one computer –The driverhas control of the keyboard and mouse and creates the implementation –The navigator watches the driver’s implementation •Identifies defects and participates in on-demand brainstorming –The roles of driver and observer are periodically rotated •Pairs produce higher quality code •Pairs complete their tasks faster •Pairs enjoy their work more •Pairs feel more confident in their work
•Improve the design of existing code without changing its functionality –Relies on unit testing to ensure the code is not broken •Bad smells in code: –Long method / class –Duplicate code –Methods does several different things (bad cohesion) –Too much dependencies (bad coupling) –Complex / unreadable code
•No Big Design Up Front (BDUF) –Reduces the overhead –Ship working functionality faster and get feedback early •“Do The Simplest Thing That Could Possibly Work” –Later use refactoring to change it •Not too much formal documentation
•Code to belongs to the project, not to an individual engineer! •Any engineer can modify any code •Better quality of the code •Engineers are not required to work around deficiencies in code they do not own –Faster progress –No need to wait for someone else to fix something
•Pair writes up unit test cases and code for a task (part of a user story) •Pair unit tests code to 100% •Pair integrates •Pair runs ALL unit test cases to 100% •Pair moves on to next task with clean slate and clear mind •Should happen once or twice a day
•Customer available on site –Clarify user stories –Make critical business decisions •Developers don’t make assumptions •Developers don’t have to wait for decisions •Face to face communication minimizes the chances of misunderstanding
•Timeboxed •As small as possible, but still delivering business value –No releases to ‘implement the database’ •Get customer feedback early and often •Do the planning game after each iteration –Do they want something different? –Have their priorities changed?
•Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every night” •Burning the midnight oil kills performance •Tired developers make more mistakes –Slows you down more in the long run •If you mess with people’s personal lives (by taking it over), in the long run the project will pay the consequences
•Use coding conventions –Rules for naming, formatting, etc. –Write readable and maintainable code •Method commenting –Self-documenting code –Don't comment bad code, rewrite it! •Refactor to improve the design •Use code audit tools (FxCop, CheckStyle, TFS)
•The XP planning game puts a special focus on the negotiation of the requirementsand likewise on theplanning of their implementation.
•The following XP practices are related to requirementsnegotiation and elicitation of user needs: –themetaphorsupports a shared vision among stakeholders, –the planning gamehelps to understandand prioritize requirements, –the on-sitecustomerimproves stakeholder involvement, and –thespecification of acceptance testshelps to refine therequirements.
•The userstories of a particular releasewill be implementedduring severaliterations. •Each user story isdivided into several tasks, which are estimated andnegotiated regarding their effort by the programmers. •The programmers take responsibility for thetasks and start to implement them.
•28% of developers preferred towork independently, 57% didn’t think they could work with everyone, and 57% stated that pairprogrammers should spend on average 50% of their time alone. •Client On-site-the Company rarely had this luxury. •“I have conflicting interests in collective code ownership. I think it is very good when it works, but there aretimes when some code I have written seems to just get worse when others have been working on it.” •“I like the idea of collective code ownership, but in practice I feel that I own, am responsible for, some bits of code.” •One of the key ‘discoveries’ has been the relative ease to which XP has been employed on an allnewproject, and the difficulty in applying XP retrospectively on an established system.
XP works when: –Requirements are changing rapidly –High risk, new challenge projects –Small groups of programmers (between 2-10) –Able to create automated tests –Direct customer involvement is possible
•Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. •It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). •The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. •Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
•Definition from rugby football: •a scrum is a way to restart the game after an interruption, where the forwards of each side come together in a tight formation and struggle to gain possession of the ball when it is tossed in among them
•SCRUM is a lightweight process for managing and controlling software and product development in rapidly changing environments. •Iterative, incremental process •Team-based approach •developing systems/ products with rapidly changing requirements •Controls the chaos of conflicting interest and needs •Improve communication and maximize cooperation •Protecting the team form disruptions and impediments •A way to maximize productivity
•Self-organizing teams •Product progresses in a series of month-long “sprints” •Requirements are captured as items in a list of “product backlog” •No specific engineering practices prescribed •Uses generative rules to create an agile environment for delivering projects •One of the “agile processes”
•Scrum projects make progress in a series of “sprints” •Typical duration is 1–4 weeks or a calendar month at most •A constant duration leads to a better rhythm •Product is designed, coded, and tested during the sprint
•Define the features of the product •OwnstheProductBacklog •Decide on release date and content •Beresponsible for the profitability of the product (ROI) •Prioritize features according to market value •Adjustfeatures and priority every iteration, as needed •Accept or reject work results The ScrumMaster •Represents management to the project •Responsible for enacting Scrum values and practices •Removes impediments •Ensure that the team is fully functional and productive •Enable close cooperation across all roles and functions •Shield the team from external interferences
•Typically 5-9 people •Cross-functional: •Programmers, testers, user experience designers, etc. •Members should be full-time •May be exceptions (e.g., database administrator) •Teams are self-organizing •Ideally, no titles but rarely a possibility •Membership should change only between sprints
•A subset of Product Backlog Items, which define the work for a Sprint. •Productownerand Team togetherselect items from the Productbacklog they can commit to completing •Sprint Backlog’s storiesare decomposedtoTasksby Team •Is ownedbyTeam •Each Item has it’s own status •Should be updated every day •No more then 300 tasks in the list •If a task requires more than 16 hours, it should be broken down •Team can add or subtract items from the list. Product Owner is not allowed to do it •Is a FORECAST! •Is a good warning monitor
•Individuals sign up for work of their own choosing •Work is never assigned •Estimated work remaining is updated daily •Any team member can add, delete or change the sprint backlog •Work for the sprint emerges •If work is unclear, define a sprint backlog item with a larger amount of time and break it down later •Update work remaining as more becomes known
•Depicts the total Sprint Backlog hours remaining per day •Shows the estimated amount of time to release •Ideally should burn down to zero to the end of the Sprint •Actually is not a straight line •Can bump UP
?Model ?Practices ?Process Improvement
•The term "staged" comes from the way that the model describes this road map as a series of "stages" that are called "maturity levels." •Each maturity level has a set of process areas that indicate where an organization should focus to improve its organizational process. •Each process area is described in terms of the practices that contribute to satisfying its goals. •The practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the process areas. •Progress occurs by satisfying the goals of all process areas in a particular maturity level
•Continuous models provide less specific guidance on the order in which improvement should be accomplished. •They are called continuous because no discrete stages are associated with organizational maturity. •Like the staged models, continuous models have process areas that contain practices. •Unlike in staged models, however, the practices of a process area in a continuous model are organized in a manner that supports individual process area growth and improvement. •Most of the practices associated with process improvement are generic; they are external to the individual process areas and apply to all process areas •The generic practices are grouped into capability levels (CLs), each of which has a definition that is roughly equivalent to the definition of the maturity levels in a staged model. •Process areas are improved and institutionalized by implementing the generic practices in those process areas. •In a continuous model goals are not specifically stated, which puts even more emphasis on practices. •The collective capability levels of all process areas determine organizational improvement, and an organization can tailor a continuous model and target only certain process areas for improvement. •In other words, they create their own "staging" of process areas.
•In a continuous appraisal, each process area is rated at its own capability level. •An organization will most likely have different process areas rated at different capability levels. •The results can be reported as a capability profile.
•ThepurposeofRequirementsManagement (REQM)istomanagetherequirementsofthe project’sproductsandproductcomponents andtoidentifyinconsistenciesbetweenthose requirementsandtheproject’splansand workproducts.
A card attached to boxes of parts that regulates pullin the Lean System by signaling upstream production and delivery. Kanbanasks us to think differently about organizing our work – and eliminates the (first order) concept of a timeline or timebox, itrations, sprints.
•When a customer requests a given feature for a software product, they want to pull that feature out of testing so that they can start using it •Once that feature has been moved out of Testing and the customer is ready to pull the next feature out, there isn't anything to pull. •At this point, the Testing people would then try to pull the next feature out of Development. •And the same pull happens from Analysis to Development. •Don’t build features that nobody needs right now •Don’t write morespecs than you can code •Don’t write more code than you can test •Don’t test more code than you can deploy A Minimal MarketableFeature (MMF) •A minimal marketablefeature (MMF) is a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity. •The smallest set of functionality that must be realized in order for the customer to perceive value. •A “MMF” is characterized by the three attributes: minimum, marketable, and feature. •“Marketable” means that it provides significant value to the customer; value may include revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty.
•The ideal work planning processshould always provide thedevelopment team with best thing towork on next, no more and no less. •Further planning beyond this does notadd value and is therefore waste.
•Q: Scrum works flawlessly for all of my teams. Whyoverly complicate things by adding Kanban constraints? •A: Kanban isbuilt for competition. Maybe you are not in a competitive situation. Maybe your competitors are inept. If, however, youare under any pressure for systematic performanceimprovement, then the Kanban address inefficiencies that are built into Scrum.
1.Ability to release anytime–Scrum and XP, usually do not release in the middle of the sprint. This is not the case with Kanban. 2.Ability to change priorities on the fly–Scrum is reluctant to change the priorities in the middle of the sprint. In Kanban, if there is an urgent request toimplement or a really important user story, the team can just put it on top of the queue. 3.No need in iterations–Iterationsare perfect for getting into a rhythm. However, after a point, when the flow is established, iterations could rather become a waste. 4.No need in estimates–Just as iterations, estimates could also become a waste. You can take the most important user story from backlog and implement it. 5.Perfect flow visualization-Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking