Explore
For Enterprise
Join for Free
Log In

Parcourir
Rechercher
For Enterprise
Connexion
Inscrivez-vous gratuitement

Building Software with Agile

Loading...

Managing an Agile Team

Université de Virginie

4.7 (573 évaluations) | 25K étudiants inscrits

Cours 3 de 5 dans Développement agile Spécialisation

While agile has become the de facto standard for managing digital innovation teams, many wonder if they’re doing it ‘right’. Twitter is full of jokes about how teams say they do agile but don’t ‘really’ do it. The reality is that getting the most out of agile is less about observing specific procedures and more about how a team focuses and measures their progress. Rather than just boring you with an accounting of agile methodologies, this course focuses on helping you better charter your team’s focus, definition of success, and practice of agile. While learning about agile mainstays like Scrum, XP, and kanban, you’ll also learn to help your team ask the right questions about how they’re working and facilitate good answers on how agile can help. As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 20 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122) This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

Visualiser le programme de cours

Compétences que vous apprendrez

agile product management, Agile Software Development, backlog management, Kanban, XP

Avis

4.7 (573 évaluations)

5 stars
423 ratings
4 stars
119 ratings
3 stars
27 ratings
2 stars
2 ratings
1 star
2 ratings

SA

Jun 05, 2019

I've really enjoyed this course on Managing an Agile Team. Comprehensive with a mix of insights from industry experts, case studies and great instructions on best practices from Alex.

DB

Aug 01, 2017

This is an interesting course that provides critical information regarding collaboration with key stakeholders outside the scrum team. I use lessons learned in the course daily.

À partir de la leçon

Building and Managing

This week we’ll dive into the jobs of building software and the core management jobs in running an agile team. Agile--and XP in particular--offers a rich body of work on specific coding practices. We’ll step through a few of the most prominent and discuss key linkages with the other concepts and practices you’ve learned. On the job of managing, we’ll dive deeper into what that means and what works in an agile context.

Building Software with Agile4:21

XP on Writing Software: Part 19:29

XP on Writing Software: Part 23:32

Bill Wake on YAGNI6:31

Bill Wake on Integrated QA3:32

Enseigné par

Alex Cowan
Faculty & Batten Fellow

Transcription

Welcome to the module on building software with Agile. Now, even if your job is not to create code and build software, these ideas are still important for you because as an Agile participant or manager it's still going to be part of your job to help create space for your team to focus on the items that they think are important in this area. And so the way we're going to look at the job of building is that you have code creation and maintenance, the actual building of code. Version control and integration. So how do we manage all of the different revisions of the software and then bring them together? And then how do we maintain best practice architectures and conventions. So how do we approach the job of building code with best practices and how do we develop an ongoing idea about how we do this in the best possible way that continually improves. And then how do we execute functional testing? So, when we put the whole system together and we want to make sure that it delivers the narrative that we all thought was a good idea, how do we do that? And if we look at the definition of success here, how do we know if this is working? I would say that it's you're not accumulating technical debt. And we talked about what that means, it's the idea that your software is not kind of getting harder and harder to deal with, more bug-prone, harder to extend, enhance, change. It's actually staying the same or ideally even getting better, easier to enhance and update. Your code that you're releasing, your software product has a relatively low defect rate. In particular, low level bugs are caught with some of the techniques that we'll explore here, like unit testing. And you're using automation in a prudent way. Now a lot of the material that you'll see, that we have talked about talks about automation as this, sort of, super important piece of infrastructure and almost universally a good thing. Which, you know, it sort of is. But, it's not like categorically everything is better off being automated. It's best to automate things that are repetitive, predictable, and work intensive. And so, that'll vary some, but I think you'll hear from most teams that their ability to build software with Agile has been greatly enhanced by their ability to automate a lot of the tasks of putting the software together, running the standardized tests that they've accrued to make sure it's okay. And otherwise avoiding hand carrying a lot of the more routine tasks of checking the software. It is easy to actually release the software to the public frequently and that process is painless. It's okay, that doesn't mean that when the software goes out it's perfect, but it means that the problems aren't horrible and that they're easy to resolve and contain. And that your work in progress flows well. Meaning that you don't have terrible stack ups where everything's in design, or everything's in QA and everybody's kind of idling and waiting. That you have balanced productivity and relatively continuous flow of discrete narrative through whatever your process is to go from idea to working software. If you remember the blue button moment, this is really, really integral to sort of the working task associated with building. If you remember in the not agile scenario, we have a developer, designer who wants to refactor, or, in this example, he knows that the blue buttons are going to be a bad bet. And we're kind of asking have we created a highly non-agile environment where she thinks I don't have the empowerment, the will, the space, and support for my team to fix this the way it should be fixed. And so we end up with crappy software that doesn't draw on the accumulated wisdom of all the different creative people on the team. Or do we have a situation where she does feel like she can do that. She collaborates with her team members to talk about what they ought to do. And these people will generally end up with much more valuable software much more often and In overall infrastructure for doing Agile that is much stronger. So, that's what we're focused on learning about in this module about building.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2019 Coursera Inc. Tous droits réservés.

Disponible sur Google Play

Coursera
À propos
Direction
Carrières
Catalogue
Certificats
Certificats MasterTrack™
Diplômes
For Enterprise
For Government
Pour le campus

Communauté
Learners
Partners
Developers
Beta Testers
Translators

Se connecter
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Blog Tech

Plus
Conditions
Confidentialité
Aide
Accessibilité
Presse
Contact
Répertoire
Filiales