Software project management PDF

Preview

Summary

Download Software project management PDF

Description

Software project management – Revision

User story and how to make them User story : is a chunk of functionality or feature that is of value to the customer It a simple way for developers and customers to chop up what the system needs to and it can be delivered in pieces. They are experiences you want the customer to have while using the product. It focuses on what the person using the product will be able to do A user story will have a user , what they want to do and why they need it . A good user story As a (type of user) , I want to do (goal) so that (reason). Example : : As a user, I want to be able to check my COVID symptoms, so that I know whether to receive a test or not. Two user stories cannot have the same priority. Principles of a user story

About Agile In agile the project breakdown is broken in iteratively/iterations . Every iterations has to be the same length throughout. Whether 2 weeks or 3 weeks. An iteration The iteration is time boxed and the time you spend on an iteration should be limited and never extended. An iteration will have start ,realize and evaluate

Start : plan, release : development of the project that is analysing, design building and testing., evaluate : this is where you have a retrospective meeting to evaluate an iteration. You talk about the process, what you did well and what you can improve for the next iteration.

You will also a review meeting. This where you show to the customer what you have done to receive feedback in order to add new requirements in the next iteration. Product backlog in agile This is where all the requirements including functional and non-functional requirements you will need to develop for a project will be placed. The project backlog is used to manage a scrum project and it provides an overview of the whole project. It is always developed or updated continuously based on feedback you receive from customers Every iteration selects from the product backlog to make an iteration backlog. Each item selected from the product backlog for an iteration has estimations(initial estimate), description of user story and priority of the user story or item. The product owner and the scrum team can contribute to the product backlog. However, the product owner maintains and prioritise user stories in the backlog. Scrum One of the techniques used to apply agile methodology. Scrum is an iterative and incremental process. Working product are produced at the end of every iteration in increments. In scrum, iterations are called sprints: they include the realization(development of the project) of an iteration. An increment should be produced in each iteration and should be shippable(the feature or function that is produced should be usable by a customer) At the end of a sprint: you inspect every activity that was performed on a daily bases to adapt and make changes. Scrum uses a product backlog. Sprints : You start every sprint with a version of product backlog and a Sprint planning meeting: at the end of this meeting you produce a sprint backlog. Sprint backlog focuses on the items or user stories selected for development from the project backlog. Sprints duration are usually 2-4 weeks. Scrum team works daily , developing and testing items from the sprint backlog. This is called daily scrum meetings where every team members informs what has been achieved or any obstacle so the team can find a way to solve the problem. Sprint review : at the end of a sprint, customers, business owners or users. The functions that has been developed is shown to the customers for feedback. Any new requirements are sent to product backlog and its updated. Sprint retrospective is conducted by the scrum team where they evaluate the process or project management they followed. The team learns more about themselves and improve the software process.

EPICS : these are user stories that don’t follow the invest model. The are stories that have ambiguities or large and needs to broken down into smaller user stories.

Estimation of user stories A technique used to perform initial estimates is called t-shirt. Backlog refinement meeting This is not part of the scrum process but its recommended as it happens before the sprint planning meeting. The product owner must have a set of items in the product and have them prioritised before coming to the meeting. The product owner and the scrum team work to refine the backlog. The team goes through the more important to less important user stories and estimate them using the t-shirt whether Large , small or medium. The meeting helps the scrum team to estimate the effort or size of the user stories Get clarification on the user stories from the product owner and identify user stories that have epics before beginning a sprint planning meeting/. PlanIT poker : it’s an estimation tool used to perform initial estimates of a user story. After the backlog meeting , the Product owner update the product backlog if there has been changes. Re-prioritise user stories if there has been new created.

Sprint planning meeting This is where the team selects items from the product backlog to include which user stories to include in a sprint. During the meeting, the scrum team selects what they are going to develop user stories and how they will build it. The sprint planning meeting produces a sprint goal, list of team members to participate in the sprint and a sprint backlog. Sprint planning meeting is timeboxed(place a limitation on the length of sprint planning meeting). Length of sprint planning meeting = weeks of sprint *2 Example : 2 weeks sprint means 4 hours on sprint planning meeting to be spent. Meeting time can be less but not more than 4 hours. Product owner explains the product backlog to the scrum team and specifies the highest priority items in the product backlog. He must understand the each user story before he comes to a sprint planning meeting Product owner may update the importance ratings in the excel based product backlog after the sprint planning meeting. The scrum master has to facilitate this meeting(creating an engaging environment and make sure all team members participate. They can also estimate user story if they have technical expertise. The

scrum master also coaches the team as he/she knows how scrum works. He also prepares an agenda for sprint plaining meeting. The scrum master also ensures the product backlog is in good shape. The scrum master prevents other people from interrupting the scrum team with any unrelated work. The scrum master also manually updates the excel-based sprint backlog with respect to any changes tasks, how to demo etc after a sprint planning meeting(user story id, description, estimate , tasks and how to demo)

User stories are selected for a sprint is based on either Estimated velocity of the team : here you have estimated velocity and actual velocity. Estimated velocity is calculated at the start of a sprint. They include story points that the team believe they can do Yesterday’s weather : this is a technique used to calculate the estimated velocity of the team. It can only be used if   

Team has done a few sprints before The next sprint will be done in similar way It should be the same team size and working conditions

Resource calculation(still on yesterday weather’s technique)  



Calculate available man days first (it is bigger than estimated velocity Then calculate focus factor (if there was a previous sprints) = actual velocity of prev sprint/available man days. Focus factor can be 70% for new teams who haven’t worked before. Then Estimated velocity = available man days *(focus factor )

User stories can then be selected based on points of estimated velocity and priority of user story(highest priority) Actual velocity : is produced after the completion of a sprint. You will want to make sure that the estimated velocity is close to the actual velocity. They are the number of story points a scrum team actually managed to get done Gut feeling : there is no mathematical calculations involved. Scrum team selects user stories for sprint based on user stories they think they can finish for a sprint. Gut feeling can be used to estimate the velocity of the team by first selecting user story and estimating them in points. The story points selected based on gut feeling of completing them becomes the estimated velocity of the team.

Estimating user stories :  

Every team participates in estimating the user story (2nd time should be done in points rather than t-shirt) Estimating helps in breaking down user stories



Planning poker : is technique to avoid allowing team members to affect everybody’s else’s estimate. The is why you anonymously hide estimates of every team member and then everybody reveal their estimate at the same before they start to discuss. The planning poker number uses Fibonacci numbers. The higher a number Is given to for a story point , the difficult or complex the user story is.

Breaking down stories into tasks Items or user stories in a sprint backlog needs to broken down into tasks. This is how(steps to take ) you will develop the user story. These tasks are non-deliverable and only useful for the developers. Every task for a user story must include a testing part Always use verbs when writing tasks user stories into task such as design, integrate, test, develop, implement, configure and deploy. These are specific to software engineering. How to demo a user story: You have to plan how you will demo what you want to show to the user in your sprint. It’s a high level description of how a story will be demonstrated at a sprint demo. It is used to ensure that the product owner and the team have the same understanding. It could be used by the team to see if you have finished a user story(up to standard) or you haven’t it. It is an acceptance test. Sprint info page Sprint (1) Sprint goal Sprint backlog summary of the spring backlog(user stories you have selected for sprint 1): Deposit(3)story points beside user story Migration tool(8) Back office Login(5) Backoffice admin(5) Estimated velocity:21 Schedule Sprint period: duration of sprint Daily scrum : time of scrum and location of meeting. Sprint demo day : usually last day of sprint Team members Daily scrum meetings : You have to decide and monitor the progress of your sprint. Are you finishing enough story points or you have to do more. You don’t want to wait until the end to check if you are doing well or not.

Task board : we use a task board to monitor progress of work in a sprint. Sprint backlog excel sheets : you use this this to record user stories and specify how many points a user story has . You indicate a task for each story and how specify how many story points you aim to finish in day. You should aim to reduce your estimated velocity every day. Burndown chart A graphic representation of the rate at which work is completed and how much remains that needs to be done in a sprint. It shows the progression of the team towards the sprint goal but does not include time spent working on a story point.

In the image above, the x-axis shows the sprint duration and the y-axis shows the estimated velocity(story points that needs to be completed for the sprint) You start with your estimated velocity which is 70 above. Every day, when you finish a story point , you reduce it in the diagram. The dash line : starts from the estimated velocity of the team till the end date of the sprint. This line shows whether a team is doing well or not. If the curve is next to the line or below the line, that means you are on track and finishing well. It indicates that the team is well organised and are not behind schedule If the curve is far below, that means they have estimated less than their capability and will need to add new items. They don’t have to wait and do nothing. If the curve goes above the line, means you are not progressing according to plan. This is an indication a problem and needs to be investigated. The team will need reduce their team velocity.

Extreme programming Lightweight methodology which is another agile framework. Used where there Small to medium sized teams

Scrum team works with the users to understand what is valuable to them and deliver working software often in an iterative way Scrum team address requirement changes from project management perspective or product owner. The challenge is that , the product owner may not be able to communicate accurately to the developers , what the customers actually want. Traditional development Change is difficult so adequate plan is made well before the start of the project. Agile allows changes by adding changes to software requirements however the disadvantages of this causes software erosion : where final software or product may deviate from its initial design due to many changes added. XP plans to adapt since change is inevitable . XP uses TDD and Pair programming. Planning weekly cycle , quarterly cycle and slack. Test-driven development A unit test( is written for every functionality or software requirement. The functionality will need to the pass the test first before the functionality is added to the development. A code will fail the test the first time you run the test on it. You write the code again to pass the test. The code will have to be refactored over and over again in order to improve readability , maintainability and extensibility. Acceptance test : this normally ends at the of the iteration. A high level of testing where you deliver working code to the customer for approval. Benefits of TDD. 1. Avoids scope creep : a problem where you develop something that the customer doesn’t need. TDD makes you create a test directly from a software requirement before its added to the development process. 2. Work is done in small and incremental steps that is test, code refactor, test and code again which the code maintainable and avoid having a big mess at the end of deployment. 3. It supports frequent releases and collective code ownership. At the end of every iteration, there should be shippable product to gain feedback from customer 4. There is a report of significant reduction in defect rates. Every code is tested before its added to development so there is no feature that does get tested. 5. Huge amount of bugs at the end of a project is limited as most bugs are detected during testing phase Pair Programming It involves two developers sitting together and working on the same task. It helps to reduce fatigue one can take over from another if tired from working on a requirement. There is a great amount of ideas sharing , brainstorming which encourages innovation There are two pair of eyes working on the same code so there is high tendency of detecting bugs which helps reducing bugs in general.

Disadvantages Team member may prefer working alone due to personal preference and space. Issues or conflicts can arise where there is limited space for programmers or they live in different locations with different time zones TRADITIONAL PROJECT MANAGEMENT Characteristics of a traditional project management Goals and solution are clearly known at the start Few changes for the scope are allowed The technology or infrastructure to be used is well understood. Low risk : the risk for changing requirements is low Experienced and skilled project teams are recruited to work on project due to having past experiences of developing similar projects in the past. Linear and incremental are two types of project management lifecycle approach for traditional project management. Linear follows a waterfall model. Strengths are    

Entire project is scheduled at the beginning Resources for requirements are known from the start Team members do not have to be co-located Avoidance of software erosion.

Weakness 

  

Does not accommodate changes very well and cost is high. If there is a problem with the project or the customer does not like a feature or its needed due market change, it is difficult implement these changes. Takes longer for deliverables to be produced which is great for an environment where things move very quickly. Requires complete and detailed plans The focus to satisfy the customer needs is very limited

Incremental Strengths of incremental    

Produces business value early in the project Enables you to better schedule scarce resources Can accommodate minor scope change between increments Offer a product improvement opportunity and more client customer value.

Weakness of incremental Requires handoff documentation between increments (team may change)

Partitioning of the functions may be problematic as major planning is still done at the begninig similar to the linear model Agile project management (iterative plmc) The difference between the incremental of tpm and agile is that, planning is not included in incremental whereas planning as part of each iterative process in agile.

Very efficient in environments where software requirements are not knowns as definitely as the client would like. Projects where most of the solution is known whose goals are defined and documented. Also, if the solution is complete to a point where only 1 or more features many need adjustments. Strengths      

It accommodates changes easily It focuses on business value Client reviews increments of the product for improvements It can process scope changes between iterations Adaptable to changing business conditions Does not require extensive planning to begin development

Weakness     

Resources requirements are unclear at project launch Requires more actively involved client than tpm projects Requires teams to sometimes co-locate but necessarily Implementing immediate solutions can be problematic Final solution cannot be defined at the start of the project.

Other pmlc Adaptive pmlc Most of the solution is known Extreme pmlc Starts with a goal or a solution but the right way to do it is not known so requires loads of research to be done Emertxe PMLC There is an interest in the use of a particular technology but the benefits of the technology for the organisation is not known A benchmark.   

If you have a clear goal and solutions or technologies to use then you can go with tpm. If you have a clear goal but the solutions or technology or features of a software is not clear you can go with If the goal is not that clear and the solution is not very clear or there are uncertainties or changes in the solutions then extreme pmlc is good for you



If you know the solution to use but not sure of organisation benefit or goal is not clear then emertx is for you.

FPM6011404625FC...