Hi all, this is a good matrix to keep track of your skill set as you advance in your field.
Hi all, this is a good matrix to keep track of your skill set as you advance in your field.
Computer Scientist’s Checklist
Tip #1: Java is very accessible and all the following are available for free.
The steps you take may slightly vary depending on your familiarity with Java and its tools.
Google search, good blogs and online tutorials are your friends in setting up the above 6 items. Even with 13+ year experience in Java, researching on Google.com is integral part of getting my job done as a Java developer. As an experienced Java developer, I can research things much faster. You will improve your researching skills with time. You will know what key words to search on. If you are stuck, ask your mentor or go to popular forums like Javaranch.com to ask your fellow Java developers.
Tip #2: Start with the basics first.
Enterprise Java has hundreds of frameworks and libraries and it is easy for the beginners to get confused. Once you get to a certain point, you will get a better handle on them, but to get started, stick to the following basic steps. Feel free to make changes as you see fit.
Tip #3: Once you have some familiarity and experience with developing enterprise applications with Java, try contributing to open source projects or if your self-taught project is non trivial, try to open source your self-taught project. You can learn a lot by looking at others’ code.
Tip #4: Look for volunteer work to enhance your hands-on experience. Don’t over commit yourself. Allocate say 2 to 3 days to build a website for a charity or community organization.
Tip #5: Share your hands-on experience gained via tips 1-4 in your resume and through blogging (can be kept private initially). It is vital to capture your experience via blogging. Improve your resume writing and interviewing skills via many handy posts found in this blog or elsewhere on the internet. It is essential that while you are working on the tips 1-5, keep applying for the paid jobs as well.
Tip #6: Voluntary work and other networking opportunities via Java User Groups (JUGs) and graduate trade fairs can put you in touch with the professionals in the industry and open more doors for you. The tips 1-5 will also differentiate you from the other entry level developers. My books and blog has covered lots of Java interview questions and answers. Practice those questions and answers as many employers have initial phone screening and technical tests to ascertain your Java knowledge, mainly in core Java and web development (e.g. stateless HTTP protocol, sessions, cookies, etc). All it takes is to learn 10 Q&A each day while gaining hands-on experience and applying for entry level jobs.
Here’s an excerpt I found very interesting from John Sonmez’s newly released book, ‘the Complete Software Developer’s Career Guide’. It is a good read and I recommend it.
I think I might try this option, and I think you guys might want to give this some thought too.
CREATE YOUR OWN COMPANY
Many people laugh when I tell them this idea of gaining experience when you don’t have any, but it’s perfectly legitimate.
Way more companies than you probably realize are actually run by a single person or a skeleton staff of part-time workers or contractors.
There is absolutely no reason why you cannot create your own software development company, develop an application, sell or distribute that app, and call yourself a software developer working for that company.
You can do this at the same time you are building your portfolio and learning to code.
If I were starting out today, I’d form a small company by filing for an LLC, or even just a DBA (Doing Business As) form (you don’t even need a legal entity), and I’d build an app or two that would be part of my portfolio. Then, I’d publish that app or apps in an app store or sell it online in some way.
I’d set up a small website for my software development company to make it look even more legit.
Then, on my resume, I’d list the company and I’d put my role as software developer.
I want to stress to you that this is in no way lying and it is perfectly legitimate. Too many people think too narrowly and don’t realize how viable and perfectly reasonable of an option this is.
I would not advocate lying in any way.
If you build an application and create your own software development company, there is no reason why you can’t call yourself a software developerfor that company and put that experience on your resume—I don’t care what anyone says.
Now, if you are asked about the company in an interview, you do need to be honest and say it is your own company and that you formed it yourself.
However, you do not need to volunteer this information.
I don’t think being the sole developer of your own software company is a detriment either.
I’d much rather hire a self-starter who formed their own software company, built an app, and put it up for sale than someone who just worked for someone else in their career.
I realize not all employers will think this way, but many will. You’d probably be surprised how many.
Apache Maven, is a software project management, and comprehension tool, based on the concept of a project object model, or POM. Maven can manage a project’s build, reporting,and documentation from a central piece of information. A more comprehensive definition of Apache Maven, is that Maven is a project management tool, which encompasses a project object model.
It also ensures that programmers always get the most recent version of compilers, et cetera. Most Java projects rely on other projects, and open source frameworks, to function properly. It can be cumbersome to download these dependents manually, and keep track of their versions, as you use them in your project. Maven provides a convenient way to declare these project dependencies, in a separate,external, POM.XML file. It then automatically downloads these dependencies and allows you to use them in your project. This simplifies project dependency management greatly.
It is important to note, that in the POM.XML file, you specify the what, and not the how. The POM.XML file, can also serve as documentation tool, conveying your project dependencies and their versions. Software developers refer to Maven, as a build tool. Since it is used to build deployable artifacts from source code. On the other hand, if you asked a project manager they might call it a project management tool, since it follows a development life cycle. In reality, it is both.
Go to maven.apache.org
From this page we can either use the link on the left that says Download, or we can just use the link in the middle where it says Use Download.
Let’s look quickly at the system requirements. Probably one of the most important ones is that it requires Java Development Kit or JDK 1.7 or higher.
We’ll take a look at that in a minute, but for right now, under the link we have Binary tar file, a Binary zip file, and two source files.
I’m gonna go ahead and download the apache-maven-3.3.9-bin.zip file. It doesn’t take long to download and you can see it’s only 8.2 MB.
The first thing we need to do is extract the archive file that I just download, so I’m gonna go down to my archive, and I’m gonna click on it and I’m going to click on Extract, and I’m gonna say Extract all. The Maven website recommends that you extract the file to the Program Files directory on your C: drive so I’m gonna do that. I’m gonna click on Browse, I’m gonna go into my C: drive, to my Program Files, and I’m going to go ahead and say Select Folder, and I’m gonna say Extract. Now I have a folder called apache-maven-3.3.9, and if I open it up, I’ll see there’s a bin folder, a boot folder, a conf folder, and a lib folder. At this point, I’ve completed my download. The instructions for using Maven depends on whether you’re running a Windows machine or a Mac OS or Linux machine.
Before the installation we must verify our Java version from the command line using java -version. Remember it must be 1.7 or higher.
So do this:
cmd -> java -version
To make life easier, we need to update our environment variables. We can do that using either the command window, but, if you use the command window you’re going to have to update them every time, or, we can go to the control panel.
For now, let’s use the control panel. I’m going to go back to start again and type “control panel”. From here, I’m going to go to System and Security. I want to go to System. Now, I need to go to my Advanced system settings. Then you’ll see at the bottom it says Environment variables. Let’s click on Environment variables. The top half of the screen are specific user variables for the producer profile. The second half, the bottom half, is my system variables.
What we want to do here is we want to add a variable to indicate where the Java home is. This is where we stored our JDK.
Let’s add a new system variable. We’re going to click on new and we’re going to call it java_home. The value for the variable will be the path that takes me to my JDK file. In our case it’s going to be c:\program files\java\jdk, mine was 1.8.0_91 and I’m going to click OK.
Now you’ll see it’s added to your list of system variables. The next thing we need to do is we need to add our new Apache Maven directory, which is also in my program files. Let’s go back and take a look. If I go to my C drive, to Program Files,the very first folder is Apache Maven 3.3.9. Inside there is the bin folder. That’s what I need, I need to know that path. Let me close that. What I want you to do is to click on the path variable that already exists and say “edit”.
We’re going to add a new variable. It’s going to say, c:\program files\apache-maven-3.3.9 this time I also want to include, \bin. Now, my environment knows where to find the Maven commands. I’m going to click OK. I’m going to click OK, again, and OK again, and I’ll close my control panel.
Now, we do need to open a new command prompt. If you have any command prompt windows open, go ahead and close them and start a new window so it will pick up those environment changes that we just made. Now, from the command prompt, I’m going to type mvn -v and hit enter. We can see that this is Apache Maven 3.3.9. It tells me my Maven home folder. It gives me the Java version that we’re using, the Java home, as well as the default local and operating system name.
At this point I’m ready to get started using Maven on my Windows machine.
Maven use of the concept of a Project Object Model, or POM.
This model has a a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at certain phases in the lifecycle process. One of the things that makes Maven so powerful is that it relies on the concept that projects are set up with default behaviors. For example, the pom.xml file is always located in the base directory.The source code must be in a certain directory. Resources necessary for the project are in a another folder or directory. Test cases are in a specifically named folder. And a target folder is always created that’s used for the final JAR file.
As you can see the base directory is called calculator.Inside calculator we have our src folder, as well as our target folder, and our pom.xml file.
Inside the source folder is where we’ll find our main Java programs and our source code, as well as any needed resources. And, the test folder, which contains again, the Java test programs. And any resources needed for that. Finally, the JAR file will be stored in the target folder. This folder structure is an important example of how Maven has adopted convention over configuration. By always using a standard folder structure, it allows developers to concentrate on coding. Once the code and resources are placed in the correct directories,and the POM file is updated.
Maven handles the rest. A project model includes: A project description, a unique set of coordinates, project attributes, the project’s license information. The project version, any authors or contributors to the project, and a list of project dependencies.
Before we go further,let’s take a look at a sample POM file. This is the file for the calculator project. The POM file is stored as an XML file. XML files use tags similar to HTML.When you create a sample program using Maven,it automatically adds a j unit dependency to allow us to do unit testing for our Java program. In the case of Maven, we have tags such as group ID, artifact ID, packaging, version, etc. The artifact ID is used for the name of the program. In our case, calculator. Since it’s a Java program, the packaging is going to be to create a JAR file. And the version in this case is 1.0. The description, name, and URL are all optional. Below that are the dependencies. When you create a sample program using Maven,it automatically adds a j unit dependency to allow us to do unit testing for our Java program.
You might have noticed the three red asterisks next to the three fields: group ID, artifact ID,and version. That’s because these three fields together, make up what we call the coordinates of the project, and they must be a unique combination. So, if I wanted to create a second version of my calculator project. I’d have to change the version number from 1.0 to 2.0, or 1.1, or something, to make it unique.
When using Maven it’s important to understand the Maven life cycle. Let’s take a look at a high level overview of the flow when using Maven. Maven starts by generating a project. A project consists of a POM or Project Object Model and source code that’s assembled in the Maven standard directory layout. Next, we execute Maven with a life cycle phase as an argument that prompted Maven to execute a series of plugin goals. After that, we can install a Maven artifact into our local Maven repository.And finally, we can run the app.
Let’s take a closer look at the default life cycle phases.
One of the phases is Validate. Validate is used to validate the project to make sure it is correct and all necessary information is available.
Another phase is Compile. We compile the source code of the project.
Test: Test compiles the source code using a suitable unit testing framework.These tests should not require the code be packaged or deployed just yet.
Package, take the compiled code and package it in its distributable format. For example, a Java program will be packaged as a Java file or a Java archive file.
Integration-test. Process and deploy the package if necessary into an environment where integration tests can be run.
Verify runs any checks to verify the package is valid and meets quality criteria.
Install. Install the package into the local repository for use as a dependency in other projects locally.
And finally, Deploy. This is done in an integration or release environment. It copies the final package to the remote repository for sharing with other developers and projects.
Plugin goals can be attached to each lifecycle phase. As Maven moves through the phases in a lifecycle it will execute the goals attached to each particular phase. Each phase may have zero or more goals bound to it. For example, when we run mvn install we will see that more than one goal is executed.
It’s usually located on your home drive in a folder called .m2. This directory contains your Maven repository. When you download a dependency from a remote Maven repository,Maven stores a copy of the dependency in your local repository. In addition, it also places a copy of your jar file and the pom.xml file for each installed project. Let’s take a look at both of these.
As you can see, there’s a tag called dependencies, and inside these, there is one dependency called junit. The three tags groupID, artifactId, and version are the coordinates that make this particular dependency unique. The scope identifies what part of the life cycle this dependency is going to be used in. In this case, it’s the test phase. It is easy to add additional project dependencies by updating this pom.xml file. By adding a list of dependencies here in one place, it is also easy for someone to identify what dependencies are required for this particular project. Finally, by including the dependencies in this external file, it is easy to update the version numbers in one place as dependencies might change.
The POM file contains all the information about a project. The file is stored with an .XML extension. Here’s an example of POM.XML file that has the minimum amount of information required. As you can see, it has a groupId, an artifactId, and a version.Remember those three things make up the Maven coordinates and are required for all projects.
A plugin is a collection of one or more goals. And a goal consists of a unit of work in Maven.
A plugin may have one or more goals. Maven consists of several core plugins.
These core plugins include a JAR plugin, which creates the JAR, or Java Archive files. A compiler plugin, which contains goals for compiling source code and unit tests. And a Surefire plugin, which is used for executing unit tests and generating reports.
NetBeans always puts projects inside of the NetBeans folder that’s created on My Documents folder, within my producer, within my users, on my C drive. The group ID is com dot my company. I’m gonna change mine to com dot lynda.
On the left hand side you can see the mavenhelloworld project, let’s go ahead and take a look at the source packages. Inside there we have our com.lynda.mavenhelloworld. Let’s open that, and there’s our app.java. And as you can see I didn’t do any coding. Maven automatically created this little simple app that just says “Hello World”, on the left hand side of the project folder, you can see there’s the source packages, the test packages, any dependencies, test dependencies, java dependencies, and project files.
Let’s go ahead and run this new application by clicking on the green run arrow. In my output window I gotta scroll up a little bit. And there’s my Hello World output. Even if you don’t want hello world application, by using the quickstart to create the shell, you can now go in and make changes to the java application and create your own.
But it’s a great way to get the file and folder structure set up for a Maven project. If you have NetBeans installed, go ahead and give it a try.
In this challenge you’re gonna use Maven to create a new project. You’ll do this using the Maven Archetype Tool from the command prompt. The new project will be a very small, simple web application.
Here is the command that you’ll need to use at the command line. You’ll type mvn space archetype colon the word generate space dash DgroupId equals, I’m using com.lynda, but you can use your organization ID if you want, space dash DartifactId. The artifactId that we’re gonna use is the name of the program. I’m calling mine sampleWeb. Space dash DarchetypeArtifactId equals maven-archetype-webapp.
This tells Maven that we want to create a web app. Finally, dash interactiveMode equals false.Once you enter the command and hit Enter, Maven will create the project for you. From there you can navigate to your directory, look for sampleWeb/src/main/webapp folder and launch the index.jsp file.
Let’s talk a little bit about unit testing. As I’m sure you’ll agree, unit testing is a critical step in any programming project. What’s really nice about Maven is that it providesbuilt-in support for unit testing. JUnit plug-in is used to easily test our application. When we first created our project using the archetype quick start to get our project created, it automatically created a test directory with a test application.
There are times when you need to add dependencies. This is one of the benefits of using Maven. It makes adding dependencies easy. Remember, Maven supports both internal and external dependencies. Whenever a project references a dependency that isn’t available in a local repository, Maven will download the dependency from a remote repository into the local repository. So far, all of our projects have included the JUnit dependency. It is sometimes going to be necessary to add other dependencies required by your project.
Let’s say we’ve added some logging to our code for debugging purposes, and we need to add the Log4j as a dependency. Let’s add this dependency to our calculator project. In order to add the dependency, we need to edit the pom.xml file. So I’m going to go to my file explorer, I’m already in my calculator project. I’m going to go into my pom file. To open the file, I’m going to right click and say edit with Notepad++. And right below the dependency for JUnit, I’m going to add a new dependency.
The group ID is going to be Log4j. The artifact ID is also Log4j. The version number is 1.2.17.It’s always a good idea to check the version number by going to Google and just look up Log4j version. And, finally, the scope parameter. The logging is used in the compile phase of the life cycle.
And we don’t want to end our dependency tag. Okay, let’s save our pom file, and now we can go ahead and run our calculator program again. In the command prompt I’m in the calculator folder so I’m going to just go ahead and run mvn install.
Maven makes adding resources really easy. It is often helpful to allow your program to retest input from a file. To use a file for testing, you must add the file to your Resources folder in your test directory. Then we must update our code to read from the fileand I’m gonna add print line statements to help with debugging to make sure that everything is working as expected.
We have our main folder, but then we also have our test folder which was created by Maven.Inside Test, you should have a Java folder, but you’re probably gonna need to add a resources folder. To do that, you can right click and say New, Folder, and just name it Resources.
The last part of the process is packaging your application. The packaging information is stored in your pom.xml file. Some sample packaging types include jar, for Java Archive Files, war, for Web Archive File, EAR. Remember, the default is a jar file. If the type is omitted, Maven will automatically create a jar file. Let’s take a look at the pom.xml for our calculator app. Remember, the last time we updated it, we added the log for dependency,which starts on line 18.
But if we go back up to where the Maven coordinates are, embedded within the coordinates is, on line 6, a packaging tag. That packaging tag says jar, because our application was a Java application. So it will automatically create a Java archive. When we’re ready, we can go to the Command Prompt, and from within the base project folder, we can type MVN Package, and it will create the jar file. This is also done when you run the MVN Install as well as even the MVN Test.
But now we have our jar file, we have a copy of it in our local repository, and we’re ready to go. So remember, when you’re ready to package your application, check your pom.xml file to see what packaging type you have declared.
Version Control is the process of keeping track of your creative output as it evolves over the course of a project or product. It tracks what is changed, it tracks who changes it, and it tracks why it was changed.
As you work, each new version is kept in a simple database-like system. A Version Control system is an application or a set of applications that manage creating a repository, which is the name of the specialized database where your files and history are stored. In some systems, this is in an actual database, and in some systems this is done by creating a set of small change files which are identified by some identifier and managed by the software. The next is working set. Your files and folders can be organized into projects within the repository in a manner similar to how you manage files by keeping them in folders on your hard drive.
The files on your hard drive, from the point of view of the Version Control software, are considered your working set. You change the files in the working set and then update the repository to reflect those updates, automatically creating a backup and denoting the purpose of the changes in a process– that’s called add when you are adding new files or committing or checking in for existing files. Once you have added or updated files in the repository, you can easily revert your working set with any version of the data in the repository.
If you’re working by yourself, you can grab an older version. If you are working in a team, you can grab files that have been updated by your team members. That process is either called updating or checking out, and finally as we talked about before, you can mark the state of an entire project tree or an entire repository with an identifier called either a tag, or a label depending on the vendor, when significant events occur such as shipping a release or delivering it to a client.
Repository – the database where your changes are tracked;
Working set – your local files with potential changes not yet in the repository;
Add and check-in – ways of getting data into the repository;
Checkout and update – ways of getting data from the repository into your working set;
Revert or rollback – ways of updating your working set to match specific versions of the repository.
When sending changes from one repository to another, you can do it via two methods, one is to use a method which uses HTTP or SSH to communicate the information to a remote server, the other is a way of extracting data from a repository to be able to send by email. Push sends the changes from your repository to the server’s repository, and pull gets the changes from the server and adds them to your local repository. As I said, this is almost often done via a server listing on HTTP or via SSH.
Typically, you initialize the repository because the repository is on your local box.Similar to the Centralized Version Control, you still have a working set, and you add things and you update them. In addition, you can also have this optional remote repository, which is a way of backing things up. Now typically, people that use Git or Mercurial use a system like this, and they will use a hosted system like GitHub in order to be able to back up their local repository into the cloud, and that’s done as we mentioned just before in terminology by using push and pull.
The first thing you need to know to use Version Control is how to create either the entire repository or how to create a portion of the repository for the project your’re working on. With Distributed Version Control, you’ll create the repository yourself at least on your local machine. And then you may synchronize it with another repository created on the server by an administrator. So you’ll create the repository by using a command that’s sometimes called initialize and sometimes called create.
And what this does is create an empty space for you to put your files and directories in, as we did in our sample before where we simply created myprog.c and checked it in. If your files already exist, meaning you’re adding an existing project to Version Control, you can use the Add feature of your Version Control Software to bulk add all the files and directories into your working set and then check them in. In Distributed Version Control, there’s usually a concept between your file system and the repository that’s called the staging area. I did git commit -a -m and the -a meant add any files that are in the working set that aren’t already in the repository automatically.
Once you’ve got your files in, and you can get your files out, the typical work flow when using any Version Control System looks like this in your repository. At Time 1, you can see that there’s a file in your repository that contains A, B, and C. Let’s say you check it out and then you delete B and you add D. Now when you save your files back into the repository, use a command that’s called commit, check in, or update. When you command the Version Control System to save your updated file, it will ask you for a short description of the changes you’ve made. This is oftentimes called a commit message, and this is a crucial part of the history of tracking information.
This is one of the places where Version Control systems can really help you out.So you’ve got your file in the repository at time T1, you would check it out or update it as necessary, and you begin to make some changes.
You delete feature B and add feature D and then you realize that’s not the way you want it. So with Version Control software, you can go back and say please overwrite the file in my working set with the most recently saved one, or even overwrite the file or the entire working set with the version from last Thursday. This is sometimes called reverting, and in some systems it’s called rollback. Now, the key thing is that you have to identify the specific version you want to roll back to. Each time you commit or check in, the Version Control Software creates a change set identifier.
Sometimes you want to be able to identify the entire state of the repository at a particular point in time, such as a customer release or a major milestone of the project. Rather than writing down a cryptic change set identifier, Version Control systems allow you to supply a human readable name describing the current state of the whole repository or project, in our case here, V1.0. This is called tagging in some systems and labeling in others.
You start out with your main branch and your existing files, and you create a new branch, and now you have another set of identical files that you can make changes to. Because all branching means is that you’re taking the current state of the repository and creating a new copy.
In the new branch, as opposed to the main branch–which is also sometimes called the trunk–you can make any changes you want and they don’t affect the product that is already working.This is a perfect sandbox in which you can experiment and you can refactor code. You can delete old unnecessary features and add brand-new ones. You really have full freedom to do anything you want to.
In our example, a repository contains a file containing features A, B, and C. Once you branch you can see the main trunk still contains A, B, and C, and so does the branch.
Now, at T2 we may delete C and add feature D. And this doesn’t have anything to do with what we can do in the main branch, where we might, for example, add feature F. And back in the branch we might delete feature B now and add feature E. And this is all without changing our main production code.
Hand in hand with branching is the reverse process, called merging. This allows you to take changes that you’ve made in a branch and add them back into the main trunk or into another branch. So let’s take a look. We have our main branch, there is our main file, we’ll create a new branch, as we did before, feature 1, and we’ll take the copy and we’ll add feature D. And now back in the main branch, we’ll add feature F. And here in parallel, we’re going to add feature E in the feature 1 branch.
So as you do these changes, you might decide you like both sets of changes and want to combine them. In this case, we don’t have any conflicting changes because we didn’t delete anything, we just added. So now we ask our Version Control system to merge the two branches together, and now we end up with a new file 1, checked into the main branch with all the features from both the main branch and the feature branch.
When there are conflicts, such as two changes in each branch that effectively did the same thing, for example, if we deleted feature B in both the main branch and the feature 1 branch, the Version Control Software sometimes can’t tell exactly what you meant to do and so therefore it declares a merge conflict and requests that you resolve this manually.
A scrum team typically consists of around seven people who work together in short, sustainable bursts of activity called sprints, with plenty of time for review and reflection built in. One of the mantras of scrum is “inspect and adapt,” and scrum teams are characterized by an intense focus on continuous improvement—of their process, but also of the product.
Scrum recognizes only three distinct roles: product owner, scrum master, and team member:
The product owner is responsible for maximizing the return the business gets on this investment (ROI).
One way that the product owner maximizes ROI is by directing the team toward the most valuable work, and away from less valuable work. That is, the product owner controls the order, sometimes called priority, of items in the team’s backlog. In scrum, no-one but the product owner is authorized to ask the team to do work or to change the order of backlog items.
Another way that the product owner maximizes the value realized from the team’s efforts is to make sure the team fully understands the requirements. If the team fully understands the requirements, then they will build the right thing, and not waste time building the wrong thing. The product owner is responsible for recording the requirements, often in the form of user stories (eg, “As a <role>, I want <a feature>, so that I can <accomplish something>”) and adding them to the product backlog. Each of these users stories, when completed, will incrementally increase in the value of the product. For this reason, we often say that each time a user story is done we have a new product increment.
The scrum master acts as a coach, guiding the team to ever-higher levels of cohesiveness, self-organization, and performance. While a team’s deliverable is the product, a scrum master’s deliverable is a high-performing, self-organizing team.
The scrum master is the team’s good shepherd, its champion, and guardian, facilitator, and scrum expert. The scrum master helps the team learn and apply scrum and related agile practices to the team’s best advantage. The scrum master is constantly available to the team to help them remove any impediments or road-blocks that are keeping them from doing their work. The scrum master is not—we repeat, not—the team’s boss. This is a peer position on the team, set apart by knowledge and responsibilities not rank.
High-performing scrum teams are highly collaborative; they are also self-organizing. The team members doing the work have total authority over how the work gets done. The team alone decides which tools and techniques to use, and which team members will work on which tasks. The theory is that the people who do the work are the highest authorities on how best to do it. Similarly, if the business needs schedule estimates, it is the team members who should create these estimates.
A scrum team should possess all of the skills required to create a potentially shippable product. Most often, this means we will have a team of specialists, each with their own skills to contribute to the team’s success. However, on a scrum team, each team member’s role is not to simply contribute in their special area. The role of each and every team member is to help the team deliver potentially shippable product in each sprint. Often, the best way for a team member to do this is by contributing work in their area of specialty. Other times, however, the team will need them to work outside their area of specialty in order to best move backlog items (aka user stories) from “in progress” to “done.” What we are describing is a mindset change from “doing my job” to “doing the job.” It is also a change in focus from “what we are doing” (work) to what is getting done (results).
So, how many team members should a scrum team have? The common rule of thumb is seven, plus or minus two. That is, from five to nine. Fewer team members and the team may not have enough variety of skills to do all of the work needed to complete user stories. More team members and the communication overhead starts to get excessive.
These are the tools we scrum practitioners use to make our process visible.
The product backlog is the cumulative list of desired deliverables for the product. This includes features, bug fixes, documentation changes, and anything else that might be meaningful and valuable to produce. Generically, they are all referred to as “backlog items.” While backlog item is technically correct, many scrum teams prefer the term “user story,” as it reminds us that we build products to satisfy our users’ needs.
The list of user stories is ordered such that the most important story, the one that the team should do next, is at the top of the list. Right below it is the story that the team should do second, and so on. Since stories near the top of the product backlog will be worked on soon, they should be small and well understood by the whole team. Stories further down in the list can be larger and less well understood, as it will be some time before the team works on them.
Each item, or story, in the product backlog should include the following information:
The sprint backlog is the team’s to do list for the sprint. Unlike the product backlog, it has a finite life-span: the length of the current sprint. It includes: all the stories that the team has committed to delivering this sprint and their associated tasks. Stories are deliverables, and can be thought of as units of value. Tasks are things that must be done, in order to deliver the stories, and so tasks can be thought of as units of work. A story is something a team delivers; a task is a bit of work that a person does. Each story will normally require many tasks.
A burn chart shows us the relationship between time and scope. Time is on the horizontal X-axis and scope is on the vertical Y-axis. A burn up chart shows us how much scope the team has got done over a period of time.
A burn down chart shows us what is left to do. In general, we expect the work remaining to go down over time as the team gets things done.
These events appear as vertical lines on the burn down chart: a vertical line up when we add new work, or down when we remove some work from the plan.
When the team’s tasks are visible to everyone from across the room, you never have to worry that some important piece of work will be forgotten.
The simplest task board consists of three columns: to do, doing and done.
The team’s definition may include things like: code written, code reviewed, unit tests passing, regression tests passing, documentation written, product owner sign-off, and so on. This list of things that the team agrees to always do before declaring a story done becomes the teams “definition of done.”
The sprint cycle is the foundational rhythm of the scrum process. Whether you call your development period a sprint, a cycle or an iteration, you are talking about exactly the same thing: a fixed period of time within which you bite off small bits of your project and finish them before returning to bite off a few more.
The shorter the sprint cycle, the more frequently the team is delivering value to the business.
The goal of part one of the sprint planning meeting is to emerge with a set of “committed” stories that the whole team believes they can deliver by the end of the sprint. The product owner leads this part of the meeting.
Note the separation in authority: the product owner decides which stories will be considered, but the team members doing the actual work are the ones who decide how much work they can take on.
In phase two of the sprint planning meeting, the team rolls up its sleeves and begins to decompose the selected stories into tasks. Remember that stories are deliverables: things that stakeholders, users, and customers want. In order to deliver a story, team members will have to complete tasks. Task are things like: get additional input from users; design a new screen; add new columns to the database; do black-box testing of the new feature; write help text; get the menu items translated for our target locales; run the release scripts.
The output of the sprint planning meeting is the sprint backlog, the list of all the committed stories, with their associated tasks
The daily scrum, sometimes called the stand-up meeting, is:
Daily. Most teams choose to hold this meeting at the start of their work day. You can adapt this to suit your team’s preferences.
Brief. The point of standing up is to discourage the kinds of tangents and discursions that make for meeting hell. The daily scrum should always be held to no more than 15 minutes.
Pointed. Each participant quickly shares:
The goal of this meeting is to inspect and adapt the work the team members are doing, in order to successfully complete the stories that the team has committed to deliver.
Note that these are not the stories in the current sprint–those stories are now in the sprint backlog. We recommend one hour per week, every week, regardless of the length of your sprint. In this meeting, the team works with the product owner on:
Stories at the top of the product backlog need to be small. Small stories are easier for everyone to understand, and easier for the team to complete in a short period of time. Stories further down in the product backlog can be larger and less well defined. This implies that we need to break the big stories into smaller stories as they make their way up the list.
Experience is the best teacher, and the scrum cycle is designed to provide you with multiple opportunities to receive feedback—from customers, from the team, from the market—and to learn from it. What you learn while doing the work in one cycle informs your planning for the next cycle. In scrum, we call this “inspect and adapt”; you might call it “continuous improvement”; either way, it’s a beautiful thing.
All Excerpts From
Sims, Chris & Hillary Louise Johnson. “SCRUM: A Breathtakingly Brief and Agile Introduction.” DYMAXICON.
This material may be protected by copyright.