Each project will eventually get to the point where there is a list of features populated. In a Scrum project for instance, the team will eventually start off with a backlog of User Stories. Each User Story can be seen as a feature.
A feature is not necessarily a piece of software, but rather a collection of software developed to perform a requested task. For instance, if the client asks for a "Login", this can consist of a login page, a table of users, a function to encrypt passwords, and so on.
In this example, the "Login" will become a feature to be assigned to a number of developers. The creation of the login page, the table of users, and the other smaller tasks will be To-do's, as we will see in a later recipe in this chapter.
In this recipe, we will see how we can create a list of features and assign them to certain project members.
For this recipe, we don't need any physical pages or code. All we need is an application.
Create a new application named Enterprise Application and add a blank page named Home inside it.
For this recipe, we have to assume a lot of things. Because we will not actually be creating the "Enterprise Application" we just need to theorize what kind of features such an application should contain.
Let's assume that at least these features need to be built:
- Users need to be authenticated in a secure way
- Users need to be able to see a list of employees
- Users need to be able to see a list of departments
- Administrators need to be able to edit the list of departments
Now we can start to build our List of Features in Team Development.
- Navigate to Team Development from the Workspace Home Page.
- Click on Features.
We can now see a large Dashboard screen that is completely empty. This Dashboard will be filled with data once we add items in Team Development.
There are also some tabs near the top of the screen. We will leave them alone for now. Once we have added something, it is more prudent to explain this screen.
- Press the button labelled Create Feature.
- In the first text field, enter Users need to be authenticated in a secure way.
- Enter text for New Owner: Security Manager.
- Enter text for New Contributor: HR Manager.
- In New Release enter 0.1.
- Feature Status will be Not Started - 0%.
- Desirability is 1. Marquee feature.
- Priority is 1. As soon as possible.
- Start Date will be January, 3rd 2011.
- Due Date will be February, 4th 2011.
- The Public Feature Summary is a piece of text to describe the Feature. Since we don't need to be very elaborate, just enter the text Users need to be authenticated in a secure way.
- Set Publish this feature to Yes.
- The Description can be more elaborate, and the text can even be formatted. Again, we don't need to be elaborate. Use the text Users need to be authenticated in a secure way.
- Use the List of Values to select the "Enterprise Application" in the corresponding field.
- The Estimated Effort will be 120 hours.
- Press the Create Feature button to save.
- The first feature is now done. In the same manner, we will now create the other three features. The required data to be entered can be found in the following table:
|
Item name |
Feature 2 |
Feature 3 |
Feature 4 |
|
Feature |
Users need to be able to see a list of employees |
Users need to be able to see a list of departments |
Administrators need to be able to edit the list of departments |
|
Owner |
HR Manager |
HR Manager |
HR Manager |
|
Contributor |
N/A |
N/A |
Security Manager |
|
Release |
0.1 |
0.2 |
0.2 |
|
Feature Status |
Under consideration 10% |
Not started 0% |
Not started 0% |
|
Desirability |
Marquee feature |
Highly desirable |
Highly desirable |
|
Priority |
As soon as possible |
Prioritized |
Normal priority |
|
Parent Feature |
N/A |
N/A |
Users need to be able to see a list of departments 0.2 |
|
Start Date |
February 7th 2011 |
February 21st 2011 |
March 7th 2011 |
|
Due Date |
February 25th 2011 |
March 11th 2011 |
March 25th 2011 |
|
Public Feature Summary |
Users need to be able to see a list of employees |
Users need to be able to see a list of departments |
Administrators need to be able to edit the list of departments |
|
Publish this feature |
Yes |
Yes |
Yes |
|
Description |
Users need to be able to see a list of employees |
Users need to be able to see a list of departments |
Administrators need to be able to edit the list of departments |
|
Application |
Enterprise Application |
Enterprise Application |
Enterprise Application |
|
Estimated Effort |
80 |
40 |
80 |
After entering all this data, we have a nice start for a small project.
When we now take a look at the different tabs of the Features page, we can see that they start to make more sense.
- Open the tab Calendar.
- Navigate to the month of February 2011.
In this overview, all due dates for Features can be found. This overview is very helpful for all participants in the project to keep a grip on the planning.
Browse the other tabs to see what kind of information is offered.
A Development Team consists of people with many different skills and levels of authority. Not all of these team members should have access to the development environment. To assure that these people can use Team Development, but not look into the actual development environment, we can create an End User with just a few privileges.
- Go to the Administration section and press Manage Users and Groups.
- Press the Create User button.
- Enter the username End User.
- Enter an e-mail address like
[email protected]. - In the Account Privileges section set all privileges to No, except for Team Development Access. That should be Yes.
Now enter a password and press the Create User button.
When we log into the Workspace with this user, we can see that only the Team Development button and the Administration button are available, with the latter being restricted to just the possibility to change our own password.
This user can now be used to do tasks in Team Development that do not require access to the Application Builder or SQL Workshop, like reporting bugs or performing administrative tasks.