Building Software with Agile

Loading...

En provenance du cours de University of Virginia

Managing an Agile Team

411 notes

University of Virginia

Managing an Agile Team

411 notes

Cours 3 sur 5 dans Specialization Agile Development

Traditional development processes often lead to team frustration and poor results. Agile offers a different approach to managing the complexity of software development. This course focuses on the day-to-day jobs of running a software development program and how leading agile methodologies (Scrum, XP, kanban) can help you do them better. From transitioning a team to agile to running sprints to managing stakeholders, this course gives you the skills you need to manage an agile team in your specific operating environment. We'll show you how to: - Think through and focus on the most important aspects of your projects and sprints - Facilitate your team’s initial and ongoing adoption of the specific agile practices that work for you - Anchor your outcomes and success criteria in durable ideas about what makes for valuable products - Support your team's transition from traditional approaches to agile - Create an agile-friendly environment across functional disciplines - Identify and manage outside stakeholder needs 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.

À partir de la leçon

Building, Managing, and Introducing

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. We’ll close with ideas and case studies for introducing (or reintroducing) agile to your organization.

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

Rencontrer les enseignants

Alex Cowan
Faculty & Batten Fellow
Darden School of Business

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 propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

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

Télécharger dans l'App Store

Disponible sur Google Play