from idea to production efficient agile software ...€¦ · from idea to production-efficient...
TRANSCRIPT
From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
Benjamin Nothdurft
Benjamin Nothdurft
IT Trainer, Speaker & Lecturer
Software Engineer
IT Conference & Meetup Organizer
Software Engineer
www.epages.com
http://developer.epages.com/blog
Softwerkskammer Jenawww.jenadevs.org
Founder & SpeakerPartner with
Java User Group Thüringenwww.jugth.de
Founder & JUG Leader
Benjamin Nothdurft
facebook.com/dataduke
xing.to/dataduke
linkedin.com/in/dataduke
From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
Benjamin Nothdurft
Part 1:
Efficient Agile Software Development
Roadmap PlanningScrum
Scrum ValuesRoles
MeetingsRetrospectives
Team Health MonitorAgile Fluency Model
Scaling Agile
Roadmap Planning
Roadmap
Scrum
The scrum process was founded in 1993 by Jeff Sutherland. Heborrowed the term „scrum“ from an analogy from a Harvard study
that compared high-performing, cross-functional teamsto the scrum formation used by Rugby
one of the most popular frameworks for implementing agilea simple framework for effective team collaborationproduct is built in a series of fixed-length iterationsfocusses on building software that meets business needs
Official Scrum Guide: http://www.scrumguides.org/index.html
Common communication problem
in software development
Agile Manifesto
Individuals and interactions over Processes and toolsWorking software over Comprehensive documentation
Customer collaboration over Contract negotiationResponding to change over Following a plan
http://agilemanifesto.org
Scrum Values
https://www.scrum.org/resources/blog/updates-scrum-guide-5-scrum-values-take-center-stage
Sprint
Scrum projects make progress in a series of “sprints"Typical duration is 2 – 4 weeksConstant duration leads to a better rhythmProduct is designed, coded, and tested during the sprint
Roles
Product Owner
Defines the features of the productResponsible for the profitability of the product (ROI)Maintains and prioritises the Product BacklogAdjusts features and priority every iteration, as neededAccepts or rejects work results
Roles
Scrum Master
Responsible for enacting Scrum values and practicesRemoves impedimentsEnsures that the team is fully functional and productiveEnables close co-operation across all roles and functionsShields the team from external interferencesFacilitates meetings
Roles
Developer Team
Typically 5 – 9 membersCross-functional (programmers, UI designers, testers etc.)Self-organisedDecides how features will be implemented
Artifacts
Product Backlog
A list of all desired work on the projectPrioritised by the product ownerRe-prioritised at the start of each sprint
Artifacts
Sprint Backlog
Set of product backlog items selected for the sprintHighly visible, real-time picture of the work that the teamplans to accomplish during the sprintTeam members choose tasks themselves, work is neverassignedOnly team members can add, delete or change the sprintbacklogWork remaining is updated daily
Meetings
Backlog Refinement
• Is held a couple of days before the end of a sprint• Presentation & estimation of new stories in the sprint backlog
Meetings
Sprint Planning I + Sprint Planning II
Sprint planning II is held directly after sprint planning ISprint planning I is used to build the sprint backlog and tocommit to the sprint goalSprint planning II is used to break each user story downinto manageable tasksParticipants: Developer Team, ScrumMaster and Productowner, sometimes stakeholdersDuration: 1,5 - 16 hours
Meetings
Daily Scrum Meeting
The daily scrum is not a status update for the ScrumMasteror product owner! They are commitments in front of peers.Goal: Team synchronises itself, Avoids other unnecessarymeetingsParticipants: Everyone is invited, only team members,Scrum Master and product owner talkDuration: 15 min. maxTypical Questions: What did I do yesterday? What will I dotoday? Is anything blocking me?
Meetings
Sprint Review
Typically takes the form of a demo of new features orunderlying architectureWorking product is shown, avoid presentation slidesOnly finished things are shownGoal: Team presents what is accomplished during the sprintParticipants: Everyone is invited. Developer Team, ScrumMaster, Product Owner are mandatoryDuration: between 15 min - max 1 hour
Meetings
Sprint Retrospective
Periodically take a look at what is and what is not workingDefine action items (and complete them within the agreedtimeframe)There are various ways to do sprint retrospectivesGoal: Improving team performanceParticipants: Developer Team, Scrum Master, ProductOwner (not mandatory), Others (if invited)Duration: At end of each sprint, 30 min - 90 minAlso possible: cross-team retrospectives
Meetings
Sprint Retrospective
Periodically take a look at what is and what is not workingDefine action items (and complete them within the agreedtimeframe)There are various ways to do sprint retrospectivesGoal: Improving team performanceParticipants: Developer Team, Scrum Master, ProductOwner (not mandatory), Others (if invited)Duration: At end of each sprint, 30 min - 90 minAlso possible: cross-team retrospectives
Retrospectives in Detail
Retrospectives in Detail: Set the stage
Retrospectives in Detail: Set the stage
Retrospectives in Detail: Set the stage
Retrospectives in Detail: Gather data
Retrospectives in Detail: Gather data
Retrospectives in Detail: Generate Insights
Retrospectives in Detail: Decide what to do
List of specific Active Learning Cycle
Action ItemsKaizen ItemsGrowth Method / Mindset
Retrospectives in Detail: Close
Retrospectives in Detail: Close
Sprint Burndown Chart
Team Health Monitor
https://www.atlassian.com/team-playbook/health-monitor/project-teams
https://www.meetup.com/Agile-Jena/photos/26939029/#449592451
Scaling Agile
Frameworks:
LeSSSaFeDADNexus
Recommended Literature
Scrum Guide by Ken Schwaber and Jeff Sutherland( )Scrum - verstehen und erfolgreich einsetzen by Stefan Roock andHenning WolfThe Nature of Software Development by Ron JeffriesEssential Scrum: A Practical Guide to the Most Popular Agile Processby Kenneth RubinUser Stories Applied: For Agile Software Development by Mike CohnInnovation Games by Luke HohmannGame Storming by Dave Gray, Suuni Brown and James MacanufoLean Enterprise: How High Performance Organizations Innovate atScale by Jez Humble, Joanne Molesky & Barry O'ReillyThe Lean Startup by Eric RiesMore books:
http://www.scrumguides.org/scrum-guide.html
http://www.agilenutshell.com/agile_books
From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
Benjamin Nothdurft
Part 2:
Challenges in Modern Software Engineering
Communities of PracticeExtreme Programming (XP)
Conway's LawMicroservices
DockerContinuous Integration/Continuous Delivery
Software CraftsmanshipHackathons
Domain-Driven Design (DDD)
Community of Practice
Extreme Programming Techniques
Conway's Law
"Organizations which design systems […]are constrained to produce designs which
are copies of the communicationstructures of these organizations.”
– Melvin E. Conway
https://www.thoughtworks.com/insights/blog/demystifying-conways-law
Microservices
https://martinfowler.com/articles/microservices.html
Docker
https://de.slideshare.net/Docker/docker-birthday-3-intro-to-docker-slides
https://docs.docker.com/engine/reference/commandline/docker
KatasWhat makes a good practice session? You need time without interruptions, and a simple thing youwant to try. You need to try it as many times as it takes, and be comfortable making mistakes. Youneed to look for feedback each time so you can work to improve. There needs to be no pressure:this is why it is hard to practice in a project environment. it helps to keep it fun: make small stepsforward when you can. Finally, you’ll recognize a good practice session because you’ll came out of itknowing more than when you went in.Code Kata is an attempt to bring this element of practice to software development. A kata is anexercise in karate where you repeat a form many, many times, making little improvements in each.The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hourlong). Some involve programming, and can be coded in many different ways. Some are open ended,and involve thinking about the issues behind programming. These are unlikely to have a singlecorrect answer. Remember that the point of the kata is not arriving at a correct answer. The point is the stuff youlearn along the way. The goal is the practice, not the solution.
http://codekata.com
Hackathons
Domain-Driven Design
Recommended Literature
Extreme Programming Explained: Embrace Change by Kent BeckBuilding Microservices by Sam NewmanRelease It!: Design and Deploy Production-Ready Software byMichael NygardContinuous Delivery: Reliable Software Releases Through Build, Test,and Deployment Automation by Jez HumbleUsing Docker: Developing and Deploying Software with Containersby Adrian MouatThe Software Craftsman: Professionalism, Pragmatism, Pride bySandro MancusoDomain-Driven Design: Tackling Complexity in the Heart of Softwareby Eric EvansThe Coding Dojo Handbook by Emily BacheDomain-Driven Design kompakt by Vaughn Vernon, Carola Lilienthal
From Idea to Production
-
Efficient Agile Software Development
and
Challenges in Modern Software Engineering
Benjamin Nothdurft
Part 3:
Übung zu Event Storming
Entwickle ein Schemadarstellung zum Prozess derDurchführung eines Hochschulkurses. Welche Akteure
sind involviert? Welche Events müssen erfolgen?