1 Agile is Dumb. 2 Look at Moodle List of Essays Get in groups of 4-5 Divide and read the readings in the category “agile is dumb” – About 20 minutes.

Slides:



Advertisements
Similar presentations
Senior Capstone Design Project Learning. What is Project Learning? What is…? How to Make…?
Advertisements

Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Agile Planning Dealing with Reality. Reality Basic agile principle – don’t expect static plans to hold, be flexible and expect changes.
Software Development Life-Cycle Models
Software Development Life Cycle
CSE 470 : Software Engineering The Software Process.
Modeling the Process and Life Cycle CSCI 411 Advanced Database and Project Management Monday, February 2, 2015.
Processes. Outline Definition of process Type of processes Improvement models Example Next steps… 1.
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Alternate Software Development Methodologies
ITEC 370 Lecture 25 Lifecycles. Review Questions? F give prototype demonstration –Testing plan for your software Life cycles –Scrum (Roles, Meetings,
Software Life Cycles ECE 417/617: Elements of Software Engineering
W5HH Principle As applied to Software Projects
Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.
Extreme Programming--a “New” Process Model Extreme Programming-- a “New” Process Model.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
CS3500 Software Engineering Agile Software Development (1) Agile software development, proposed in 2001 by the non-profit Agile Alliance, has four basic.
Approaches to ---Testing Software Some of us “hope” that our software works as opposed to “ensuring” that our software works? Why? Just foolish Lazy Believe.
Data Structures and Programming.  John Edgar2.
1 KAN’S INTRO AND OVERVIEW MODELS Ch1 & 2 in his book Steve Chenoweth, CSSE.
The Software Development Cycle Defining and understanding the problem.
CPTE 209 Software Engineering Summary and Review.
Chapter 4 – Requirements Engineering
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture 11 : Frameworks SWE 316: Software Design and Architecture  To understand.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
Embracing change with Extreme Programming Method Engineering Erik ten Brinke
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 Integration and Design – Part 5 Bonus at the end of the hour – how to invent a foam football… using the “spiral” process.
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem Darwish.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
CSE 308 Software Engineering Software Engineering Strategies.
Software Requirements (Advanced Topics) “Walking on water and developing software from a specification are easy if both are frozen.” --Edward V Berard.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Problem Definition Chapter 7. Chapter Objectives Learn: –The 8 steps of experienced problem solvers –How to collect and analyze information and data.
Approaching a Problem Where do we start? How do we proceed?
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
OHTO -99 SOFTWARE ENGINEERING “SOFTWARE PRODUCT QUALITY” Today: - Software quality - Quality Components - ”Good” software properties.
CS 5150 Software Engineering Lecture 3 Software Processes 2.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
1 Design and Integration: Part 2. 2 Plus Delta Feedback Reading and lecture repeat Ambiguous questions on quizzes Attendance quizzes Boring white lecture.
CS3100 Software Project Management Agile Approaches.
CS5103 Software Engineering Lecture 02 More on Software Process Models.
Agile Software Development Jeff Sutherland, one of the developers started it In February 2001, 17 Tools: continuous integration, automated or xUnit test,
Stand Up Comedy Project/Product Management
Evaluating Requirements
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Prepared by Amira Selim 31 st October 2009 Revised by Dahlia Biazid Requirements Analysis.
Topic:- At the end we will be able to explain:- Why it is called Meta Model ?? Spiral Model Its Advantages & Disadvantages… Phases of Spiral Model...
1 Chapter 2 SW Process Models. 2 Objectives  Understand various process models  Understand the pros and cons of each model  Evaluate the applicability.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
Baby Steps to Agility How to Grow Into Agile. A little about me A little about Agile Growing into Agile Questions Goals.
Software Engineering Management
Game Design, Development, and Technology
Integrate Agile Testing into the Process
Waterfall and Agile Quality Techniques
HCI in the software process
Software Development Process
Introducing ISTQB Agile Foundation Extending the ISTQB Program’s Support Further Presented by Rex Black, CTAL Copyright © 2014 ASTQB 1.
HCI in the software process
Killer Project Management Best Practices
HCI in the software process
Agile Development – a new way of software development?
Human Computer Interaction Lecture 14 HCI in Software Process
Extreme Programming (and Pair Programming)
Software Development Process
Presentation transcript:

1 Agile is Dumb

2 Look at Moodle List of Essays Get in groups of 4-5 Divide and read the readings in the category “agile is dumb” – About 20 minutes – Divide up the readings – Scan your article for main points Try to summarize the top 3-5 arguments against agile, from these perspectives. – Your statements should be brief – about a sentence. – Write it on a piece of paper with your names you’ll hand in to me.

3 On your team Pick the top 3 arguments, altogether. – Circle them. Pick the top one of those 3, – And be ready to talk about it.

4 Questions about these critiques Do they offer alternative solutions? Is it possible they are partly right? Are there projects where Agile works better and worse? Is “salesmanship” important in getting people to use new stuff? – Technologies – Processes – Your products?

5 Slightly more scholarly views - 1 From "Do we Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study," by Z. Racheva, et al, ~2011. The researchers studied 8 organizations and found: The agile assumptions about client knowledge of requirements are not always true. Even having an onsite client was not always feasible. Or, the client may not be able to answer questions in a timely way. The developers made inter-iteration decision making. The involvement of clients consisted mostly of approving plans / giving comments. Clients often want things that are known not to work. Most clients relied on developers to prioritize requirements.

6 Slightly more scholarly views - 2 From "Agile Requirements Engineering Practices: An Empirical Study," by Cao and Ramesh, IEEE Software, The researchers studied the requirements practices of 10 organizations involved in agile development, and found: Most of the organizations did try to abbreviate requirements into user stories, etc. Face-to-face meetings with customers were used to validate requirements. A lack of high-quality interactions posed a real risk. Mostly, product managers acted as surrogate customers, but even this was not full-time. When customers have divergent interests, achieving a consensus is challenging. Some customers don’t trust agile processes. Intense, iterative requirements engineering tends to build satisfactory customer relationships. New technology situations are similar to speculative applications, in being good for agile. Personnel turnover causes problems when you rely on a low level of documentation. Non-functional requirements tend to be ignored. Continual re-prioritization of requirements is important. Customers add value by providing the business reasons for each requirement.

7 Slightly more scholarly views – 2 - cntd From the same source: Developing by customer priority can cause architectural problems - e.g., a non-scalable solution. – Early architectures tend to be inadequate. – The need for refactoring isn't always obvious. – Developer experience and schedule pressure weigh on the success of a refactoring strategy. – Refactoring may not solve an architecture problem. – Throwing away code and starting over is an occasional problem. The main two types of requirements changes are: – Adding or dropping features, and – Changing already-implemented features. It's rare that the development in an iteration is completely unsatisfactory. Prototyping does reduce errors. Customers will give feedback on these. Prototypes can become products you have to live with. Test Driven Development can capture requirements operationally, and enable defect tracing. Developers have to become accustomed to doing TDD. It's a big challenge for most organizations. Most organizations used frequent requirements review meetings to their advantage. – Not as helpful if they don't cover major issues. – Customer-written acceptance tests can be part of requirements. – Most agile requirements aren't suitable for formal verification.

8 Summary of the articles Agile does not solve hard problems: – Mostly about team organization and task distribution. – It’s not a fix for: A poisonous work environment.

9 Buffalo’s summary Really great programmers don’t think a lot about software process: – Although most of the really great programmers I know tend to be sort-of lone wolf sorts that are not super-great at organizing teams, say. – But, I think it’s fair to say if you want to be a really good programmer, you need to network, etc.

10 More from Buffalo Agile consultants are snake oil salesmen: – They are by definition not professional programmers, and only some of them could potentially be employed as such. – Pragmatism – tricky.

11 More more Buffalo Agile is copping out on requirements analysis: – Seriously, this is not a strength. – The best things you can say are: Sometimes the requirements are not that complicated. Maybe the developers shouldn’t be your expert user- elicitors? Or, GUI designers?

12 And… Developers ought to be more disciplined: – Maybe there is a secret technique for awesome developer productivity in here. – But, Buffalo doubts it.