Skip to content

Home

Jump to bottom Edit New page
dmitrymov edited this page Nov 25, 2012 · 53 revisions

Welcome to the Backlog wiki!

About:

In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business; it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).

Vision of the project:

Our software will help to solve the problems associated with managing software development. Here is some benefits of this project and which problems it is help to solve:

  1. Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.

  2. Project Managers want a process that is easy to plan, execute, and track.

  3. Product Managers want features implemented quickly, with no bugs.

  4. Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.

  5. Customers want all of their feature requests and bug-fixes done quickly.

  6. Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.

  7. Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.

  8. Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.

  9. Responsiveness is best achieved by fulfilling customer requests quickly.

  10. Project status and plans should be visible to everyone who has an interest in them.

Project Documentation:

Project Iterations:

Team:

  • Natan Braslavskiy
  • Dima Movchan
  • Anton Litovka
  • Danil Iskusnov

Clients and sponsors:

  • Intel Jerusalem

Team values:

  • Collaborating, supporting and respecting one another.
  • Communicating openly, honestly and frequently.
  • Developing a highly motivated, valued and diverse workforce.

How we going to work?

We divided the project into the stories, and each story into the tasks. For each story we have one teammate, that responsible for this story. Also the stories and tasks have priority, in which we have to perform them. So we making little steps to our goal with communication and helping to each other.

Communication ways:

  1. We have a meetings at least two times per week.
  2. We have a briefing each day for 15 mins, where each team member reports how is going his tasks.
  3. Using cellphones, skype, chats, and email.

Development methods:

Scrum:

List of properties:

  1. Sprint managemant (logic part).
  2. Liniar graph and columnar graph.
  3. Database - contain information about the sprint, programmers and etc.
  4. GUI - Display the data from the DB in a convenient form.

Technical structure:

Our project is divided into 3 parts:

  1. Database will be managed via ADO.NET, in which we going to save data about the sprint.
  2. Logic part is responsible for the connection between DB and external view of the program (GUI), for math calculations and for sprint managing. Will be implemented in C#.
  3. GUI will display information about sprint, for example: a stories, tasks, working dates and etc. Also will display graphic of the progres. Also will be implemented in C#.

Initial planning and evaluation:

* Building external view of the program(GUI)(1~2 weeks). * Creating DB (1 weeks). * Logic part: Calculations and Managment of sprint and logic data.(2~3 weeks) * Making connection between program and DB. (2 weeks) * Draw the graph of the progress (1 week) * Testing the program and resolve bugs. (1~2 week)

Risk managment:

1. New environment. - Learn everything you need to work in this environment. 2. Lack of information about the project area. - Gather as much information as possible and make conclusions. 3. Lack of time can lead to a reduction of futures. - Try to do tasks as soon as possible, help to teammates that has problems with some tasks. 4. A large number of stored information in the database may lead to loss of productivity. - Use smarts algorithms and planning how to bring less data to the main memory from DB. 5. Poor planning parts of the program and relationships between this parts. - Each part try if it answer to all requirements, to ask for advice from experienced engineers in the field.

Technological experience:

(Trying to solve environment problem).

  • Installed all need software (like Visual Studio).
  • Prepared ERD, figure entities to match to external view of the program.
  • Created an example of DB, GUI, writed some code in Visual studio (C#).

Conclusions:

Our team faced the problem of synchronization code, we created a database and writed some code that connect to DB and transfer data to Gui, as result we discovered that code is not appropriate, and we have to do a lot of changes.

Our progress

Add a custom footer
Add a custom sidebar
Clone this wiki locally