Previously on
: Are we enough? Wydział Matematyki i Nauk Informacyjnych Politechnika Warszawska
DSDM: Project overview
Software Development Framework How to communicate? How to divide project into tasks? How to deal with risks and requirements? How to assign tasks? How to verify tasks completion?
Software Development Methods Lean Kanban Feature Driven Development Crystal Model Storming Extreme Programming Bonus: Affective Software Development Guilt Driven Development Shame Driven Development
Software Development Methods Lean Kanban Feature Driven Development Crystal Model Storming Extreme Programming Bonus: Affective Software Development Guilt Driven Development Shame Driven Development
Initial ideas by Hirotaka Takeuchi and Ikujiro Nonaka in The New Product Development Game. (1986) Cleaned up by Jeff Sutherland, John Scumniotales, and Jeff McKenna (1993) Presented on OOPSLA conference by Jeff Sutherland and Ken Schweber (1995) Described by Ken Schweber and Mike Beedle in Software Development with (2001) Source: https://www.techwell.com/techwell-insights/2012/10/brief-history-scrum
: It s like playing chess: you learn the rules and then you play.
roles Product Owner - Defines client s priorities, maintains medium-level product requirements (i.e. Project Backlog), empowered to make decisions on behalf of the client Master - Expert on processes, helps to facilitate (not conduct!) Daily Meetings Team - Interdisciplinary (analysis, development, deployment, testing skills), self-organizing, motivated group consisting of 5-9 people, committed to the project at least for a duration of a Sprint
processes Sprint - a single 1-4 weeks long work period concentrated on delivering a valuable and working product Daily stand-up - A short meeting for a whole Team for answering 3 questions: What have I done yesterday? What am I planning to do today? Do I have any problems? Stand-up meeting should provide sufficient background for further face-to-face interactions and overall knowledge of sprint progress. Sprint kick-off meeting - a meeting for planning the next sprint, breaking-down product backlog items into smaller tasks for sprint backlog, and making time estimations of them Sprint review and retrospective - a meeting(s) concluding the
processes Product Backlog - a set of mid-level prioritized tasks Sprint Backlog - a set of low-level tasks, which the Team chose to complete during particular Sprint. Tasks are based on the Product Backlog Burndown chart - a tool for measuring Team s performance (aka velocity) during the Sprint
rules Client should be constantly involved Team should partake in tasks estimation Team commits, as a whole, to delivering a new product within a single sprint Individuals are responsible for the quality of their work (code ownership)
Product backlog Id Priority Description Est. Compl. Resp. 1 M Create database structure 6h 8h NS 2 M Present the data 2h 1h IN 5 M Fill in the database 4h 3h AB 3 S Analyze processes involving DB 5h - - 4 C Online data update mechanism 8h - CD
Chrysler Comprehensive Compensation System developement initiated (a payroll system supposed to support 87 000 employers, written in SmallTalk) (1994) System does not printout a single paycheck (1996) Kent Beck hired, Extreme Programming invented (1996) System deployed (1997) System closed after processing payrolls of around 10 000 people due to technological and business change (1999) Sources: https://en.wikipedia.org/wiki/chrysler_comprehensive_compensation_system Kent Beck s book on Extreme Programming
XP: Take well-known best practices of code development and testing to the extreme.
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
XP rules 1 Planning 2 Small releases 3 System metaphor 4 Simple design 5 Continuous testing 6 Refactoring 7 Pair Programming 8 Collective ownership 9 Continuous integration 10 40-hour work week 11 Continuous client interaction 12 Coding standards
/ PM
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people. This is achieved when all stakeholders: Understand and buy into the business vision and objectives Are empowered to make decisions within their area of expertise Collaborate to deliver a fit for purpose business solution Collaborate to deliver to agreed timescales in accordance with business priorities Accept that change is inevitable as the understanding of the solution grows over time
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
DSDM principles 1 Focus on the business need 2 Deliver on time 3 Collaborate 4 Never compromise quality 5 Build incrementally from firm foundations 6 Develop iteratively 7 Communicate continuously and clearly 8 Demonstrate control (over the SCOPE of the project)
Project Approach Questionnaire I Strongly Agree Agree Neutral Disagree Strongly Disagree All members of the project understand and accept the DSDM approach (Philosophy, Principles and Practices) The Business Sponsor and the Business Visionary demonstrate clear and proactive ownership of the project. The business vision driving the project is clearly stated and understood by all members of the project team All project participants understand and accept that on-time delivery of an acceptable solution is the primary measure of success for the project
Project Approach Questionnaire II Strongly Agree Agree Neutral Disagree Strongly Disagree The requirements can be prioritized and there is confidence that cost and time commitments can be met by flexing the scope of what s delivered. All members of the project team accept that requirements should only be defined at a high level in the early phases of the project and that detail will emerge as development progresses. All members of the project team accept that change in requirements is inevitable and that it is only by embracing change that the right solution will be delivered.
Project Approach Questionnaire III Strongly Agree Agree Neutral Disagree Strongly Disagree The Business Sponsor and Business Visionary understand that active business involvement is essential and have the willingness and authority to commit appropriate business resources to the project. It is possible for the business and solution development members of the Solution Development Team to work collaboratively throughout the project. Empowerment of all members of the Solution Development Teaam is appropriate and sufficient to support the day-to-day decision-making needed to rapidly evolve the solution in short, focussed Timeboxes
Project Approach Questionnaire IV Strongly Agree Agree Neutral Disagree Strongly Disagree The DSDM roles and responsibilities are appropriately allocated and all role holders understand and accept the responsibilities associated with their role. The Solution Development team has the appropriate collective knowledge and skills (soft skills and technical skills) to collaboratively evolve an optimal business solution. Solution Development Team members are allocated to the project at an appropriate and consistent level sufficient to fully support the DSDM timeboxing practice
Project Approach Questionnaire V Strongly Agree Agree Neutral Disagree Strongly Disagree Tools and collaborative working practices within the Solution Development Team are sufficient to allow effective Iterative Development of the solution. All necessary review and testing activity is fully integrated within the Iterative Development practice. Project progress is measured primarily through the incremental, demonstrable delivery of business value. There are no mandatory standards or other constraints in place that will prevent the application of the DSDM Philosophy and Practices on this project.
Rational Unified Process Further reading Rational Unified Process
Rational Unified Process Further reading Why RUP is not an framework? Does not involve whole team in the analysis phase Plans products in all the phases up-front, instead of choosing particular work at the beginning of each iteration Explicitly orders the use-case flows (i.e. functions of the product) to be delivered by their risk (starting with those with higher risk assessment) Measures project progress by completed use-case flows Answers common management and development problems by creating various artifacts: use cases, use-case flows, Software Development Plan, Risk Management Plan
Rational Unified Process Further reading RUP phases Inception Elaboration Construction Transition
Rational Unified Process Further reading Inception Express clearly project scope: to capture context, as well requirements, constraints and key features for acceptance criterias. Plan and prepare business case: to assess alternatives for risk management, team organization and project plan. Architecture draft: draft architecture through some PoC development. Prepare environment: assess project and organizations, select tools and which parts should be improved.
Rational Unified Process Further reading Elaboration Create baseline architecture: create an executable architecture Refine vision Create detailed iteration plans and baselines for construction Refine use case and prepare construction phase: at the end of the phase 80% of use case descriptions should be complete.
Rational Unified Process Further reading Construction Manage resources, control and process optimization. Component development and acceptance criteria test development. Product release assessment based on acceptance criteria.
Rational Unified Process Further reading Transition Execute implanting plans. Finish support material. Test released product in development environment. Create product release. Get user feedback. Adjust product based on user feedback. Make software available to end user.
Rational Unified Process Further reading Take away message practices may be applied without project management, but not the other way round
Rational Unified Process Further reading Take away message practices may be applied without project management, but not the other way round
Rational Unified Process Further reading Further reading https://www.agilebusiness.org/content/introduction-0 http://www.agile-process.org/ https://www.versionone.com/agile-101/agile-methodologies/ https: //www.ibm.com/developerworks/rational/library/1826.html https://en.wikibooks.org/wiki/rup_-_ibm_rational_unified_ Process/Phases https://www.martinfowler.com/articles/newmethodology.html https://en.wikipedia.org/wiki/chrysler_comprehensive_ Compensation_System http://alpha.mini.pw.edu.pl/~kaczmars/artykuly/xp-zespol.pdf