• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile android app

Agile android app






Total Views
Views on SlideShare
Embed Views



1 Embed 10

http://starpmo.com 10



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Agile android app Agile android app Document Transcript

    • Agile ManifestoIn 2001, a group of 17 programmers who work in IT Programming and interested in Iterative and agilemethods met in Snowbird, UT to develop common framework for what is meant by Agile methods. This grouphas created the Agile Manifesto.Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.Items on left are considered value drivers while the items on right are generally management controls forsoftware development. Many members consider that Agile is a project management approach rooted inprogramming parlance while traditional waterfall approaches (PMP) are rooted in management parlance.Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.www.StarPMO.comAgile Team Roles 1. Programmers, designers, architects: How to design and program the software
    • 2. Product managers: Why the software is important 3. Domain experts (SME): The rules to be followed by software. Must follow industry standards like regulatory etc. 4. Interaction designers: How the software should behave (Understand users, needs, how they interact with software etc) 5. Graphic designers: How should user interface look like 6. Tester: Where are defects likely to be found 7. Project manager: How to interact with rest of the company (read Politics)In many ways, the traditional project roles still exist in an Agile project, but in a modified manner for amodified purpose. www.StarPMO.comAgile ArtifactsAn artifact is a document or a chart to manage an Agile project 1. Sprint burn down chart: The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog as the spring progresses. 2. Product backlog: The product backlog is a high-level list that is maintained throughout the entire project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an absolute ordering by business value based on various metrics to be determined by the project team (For example provided by www.unleashpm.com). It is therefore the “What” that will be built, sorted by importance. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timelines and, to a limited extent prioritize. The Product Backlog, and business value of each listed item is the property of the product owner. The associated development effort is however set by the Team. 3. Sprint backlog: The sprint backlog is the list of work the team must address during the next sprint. Features are broken down into tasks, which, as a best practice, must be 4-8 in any given sprint. With this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in. The sprint backlog is the property of the team, and all included estimates are provided by the Team. Often an accompanying task board (For example provided by www.unleashpm.com) is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”. www.StarPMO.comDaily Agile Meeting or Stand up Meeting On each day of a sprint, the team holds daily meetings in a stand up position for about 10 minutes (“the daily Agile meeting or a stand up meeting”). Meetings are typically held in the same location and at the same time each day. Ideally the daily Agile meetings are held in the morning as they help set the context for the days work. All team members are required to attend the daily scrum but will not be postponed if someone is not in a position to attend. Since both the Project Manager and Product
    • Owner are committed team members, they are expected to attend and participate. Anyone else (for example, Head of the department, a salesperson, or a developer from another project) is allowed to attend but are there only to listen. This makes the daily Agile an excellent way for an Agile team to disseminate status information--if youre interested in hearing where things are at, attend that days meeting. The daily stand up meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the meeting. During the stand up each team member provides answers to the following three questions: 1. What did you do yesterday? 2. What will you do today? 3. Are there any impediments in your way? By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains. The stand up meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other. If a programmer stands up and says "Today I will finish the user information generation template" everyone knows that in tomorrows meeting he will say whether or not he did finish. This has the wonderful effect of helping a team realize the significance of these commitments and that their commitments are to each other, not to some distant customer. Any impediments that are raised become the Project Manager’s responsibility to resolve as quickly as possible. Typical impediments are: • I still havent got the upgrade I ordered a month ago. • I need help debugging a problem with ______. • Im struggling to learn ______ and would like to pair with someone on it. • The department Head has asked me to work on something else "for two days”. In cases where the project manager cannot remove these impediments directly himself (e.g., usually the more technical issues) he still takes responsibility for making sure someone on the team does quickly resolve the issue.www.StarPMO.comTechnical DebtIt is the total amount of “less than perfect” design and implementation decisions in the project. Quick anddirty hacks made to make something work right now. This usually increases the maintenance cost and cost ofadding new features. Refactoring is done to reduce technical debt so that code can be reused. Technical debtis something which prevents team from being Agile and has to be constantly addressed as the projectprogresses. www.StarPMO.comTime boxingWork invariably stretches to use the existing time (Student syndrome). Time boxing prevents this by ensuringa work stops when it is time up. It will prevent “ Analysis paralysis”.www.StarPMO.com
    • Last responsible momentMaking decisions during the moment at which failing to make a decision eliminates an important alternative. Ifyou delay beyond this time decisions are made by default which is NOT good. By delaying the decision till thispoint you improve accuracy of decisions, decrease your workload and decrease impact of changes. All thisbecause you will have higher information at the time of decision making. www.StarPMO.comUse StoriesThey Represent a self contained, individual elements of work. They correspond to individual features andrepresent one or two days of work.E.g. A Job application portal: “Ability to search for a job” is a story. www.StarPMO.comIterations or SprintsIteration or a Sprint is the full cycle of design-code-verify-release of an Agile team. Each iteration will involvecustomer deciding what stories to implement in the iteration and results in an software which the customercan use. Beginning of an iteration i where the customer can make changes to the direction of softwaredevelopment. Although planning is frequent, it is small and proportion to the size of iterations. www.StarPMO.comVelocityA measure to be able to determine the amount of work which can be done in an iteration. Most commonways to express velocity are user story points or man days.www.StarPMO.comTheory of constraintsEvery system has a single constraint that determines the overall throughput of the system. One must find theconstraints in the system (developers, programmers, testers) and eliminate the constraint. www.StarPMO.comMindfulnessThe ability to respond effectively to changes requires that everyone pay attention to the process and practicesof development and this is called “mindfulness”. Sometimes there are subtle pending changes, you mayrealize technical debt to be growing or the tone of customer feedback to be changing, or team behaviorchanging etc. www.StarPMO.comPair programmingTwo members share the same keyboard. One member does the coding (and the tactical issues concerned) andthe other members think about the big picture (Driver and a navigator). The partners can switch whenfrustrated or stuck. This usually gets people tired more than solo programming as the energy involved ishigher. A good rule of thumb is to pair up anything which needs maintenance. Large monitors and good leg
    • room is essential. Create chances for both the members to be learning to enhance the utility of pairprogramming. www.StarPMO.comEnergized workWhen you are energized you work better. One of the best ways to feel energized is to take care of yourself. Gohome on time every day, spend time with family & friends and do engage in activities that take your mind offof work. At work, give full attention to work. Turn off interruptions like e-mail, instant messages, phones andshield from unnecessary meetings. If you make more mistakes than progress, then it is time to take a break. www.StarPMO.comInformative work spaceAn informative work space brings information into the team. It allows the team to sense the state of projectwhen they take breaks. An informative work space also provides for people to communicate easily.Big visible charts and hand drawn charts are preferred. www.StarPMO.comRoot cause analysisEverybody makes mistakes- Aggressively laying blame does not solve this problem and only causes people tohide the mistakes.Instead of thinking of this as a people issue, think of it as a process issue- This is called as root cause analysis.5 Why technique is a good tool for root cause analysis.Fixing root causes needs the cooperation of other people and this can be done by during retrospectives. 1. Example: Why is our largest customer unhappy? Because our deliveries of bicycles have been late for the last month. 2. Why have our bicycle deliveries been late for the last month? Because production has been behind schedule. 3. Why has production been behind schedule? Because there is a shortage of wheels. 4. Why are we having a shortage of wheels? Because incoming inspection has rejected a large number of wheels for not being round. 5. Why are we rejecting so many parts? Because purchasing switched to a cheaper wheel supplier that has inconsistent quality.www.StarPMO.comRetrospectivesRetrospectives (Introspective lessons learned meetings) are a great way to continually improve a process.Iteration retrospective happens at the end of each retrospective. Following are a few tools to keep in mind in aretrospective. • Prime directive: No blame game. • Brainstorming (Enjoyable, frustrating, puzzling, same, more ,less): Use of index cards • Mute mapping (Variant of Affinity mapping)
    • • Pick the one with highest number of cards and focus on it (discard others for this retrospective). Can use root cause analysis.www.StarPMO.comTrustTrust is essential for a team to improve productivity. Some strategies to create trust: • Customer programmer empathy: Sitting together and understanding different point of view. • Programmer-tester empathy • Eat together • Team continuity • Impressions (Organizational antibodies)www.StarPMO.comUbiquitous LanguageWill help reduce mistakes and greatly increase communication. It is suggested that programmers should speakthe language of domain experts and not other way around. The code can use functions, classes etc based onthe domain experts language. www.StarPMO.comCoding standardsCreating of coding standards will help increase communication and collaborative work.Not just formatting, but naming the variables, handling exceptions, when and where to log events etc are allpart of standardization.www.StarPMO.comIteration DemoIt’s a concrete way to show your progress and keep stakeholders happy. It helps the team to be honest abouttheir progress and helps solicit feedback from the customers and change direction if needed. Any one can dothis, but is best done by the product manager.Two key questions to ask at end of iteration demo are: 1. Is the work satisfactory till date 2. Can the work be continued www.StarPMO.comAgile ReportingOnly product reports that are strictly necessary (as reports take up time). There are progress reports andmanagement reports.Some practices for progress reports are: • Weekly demo • Release and iteration plans • Burn up chart • Status e-mailsSome practices for management reports are:
    • • Productivity (The actual metrics are difficult and needs stakeholder involvement) • Throughput (Number of features developed) • Defects (Decide who will arbiter defect vs intentional behavior) • Time usage (Developing, planning, improving skills, out of office, un accounted)www.StarPMO.comVersion controlWill help team to co-ordinate source code, testing and other artifacts. It provides a central repository for thecode.Repository: Storage place for all the files.Sandbox: It is a working copy of files on local systemCheck out: To create a sandbox check out a copy of repository (also called as update and lock)Update: Update sandbox to get latest changes from the repositoryLock: Prevents anyone from making changes except youCheck in or commit: Check in the files from sandbox to save them into repositoryRevert: Throw away changes and return to point of last updateTip or head: Contains the latest changes made to the code that has been checked inTag or label: A mark allowing easy accessRoll back: A check in to remove from tip of the repositoryBranch: Create distinct “Alternate histories”Merge: Merge multiple files and resolve conflictsConcurrent Editing: Where multiple users can edit at same time and if two users edit same line of code thenthe lines are prompted to be merged manually.Collective code ownership is encouraged for Agile software development approach. www.StarPMO.comContinuous IntegrationGet members to agree to build frequently and never break the build. Agreement is the key as forcing is notlikely to work. The general rule to keep the build to under less than 10 minutes. If the build is reasonably fast,the it is a good idea to do synchronous integration (Confirm that the build and test succeeded before you goto next step). If the build takes longer, then it is tantalizing to do asynchronous integration. The biggestproblem is that it tends to result in broken builds and you have to interrupt your work later when the buildbreaks. If anyone has checked out the code in the mean time their build will not work either (If they have goneout for lunch then someone else has to fix the mess). www.StarPMO.comOsmotic CommunicationCommunication that is picked up or absorbed by another person. Osmotic communication means thatinformation flows into the background hearing of members of the team, so that they pick up relevantinformation as though by osmosis. This is normally accomplished by seating them in the same room. Then,when one person asks a question, others in the room can either tune in or tune out, contributing to thediscussion or continuing with their work. When osmotic communication is in place, questions and answersflow naturally and with surprisingly little disturbance among the team. Osmotic communication is the more
    • powerful version that small projects can attain of close communication, a property core to the entire Crystalfamily. Osmotic communication makes the cost of communications low and the feedback rate high, so thaterrors are corrected extremely quickly and knowledge is disseminated quickly.People learn the project priorities and who holds what information. They pick up new programming, design,testing, and tool handling tricks. They catch and correct small errors before they grow into larger ones.Although osmotic communication is valuable for larger projects, it is, of course, increasingly difficult to attainas the team size grows. Hence it is suggested in Agile methods that if the need for growing the size of team isfelt, better thing to do is to recruit the team with higher experience. It is hard to simulate osmoticcommunication without having the people in the same room; however, adjacent rooms with two or threepeople in each confers many of the benefits.www.StarPMO.comCommunication FactorsThere are several factors that effect communication, including: 1. Physical proximity. The closer people are to one another the greater the opportunities for communication. 2. Temporal proximity. Whether or not two people are working at the same time affects communication. 3. Amicability. Amicability, the willingness of someone to hear the thoughts of another person with good will and to speak without malice, is an important success factor. The greater the amicability a greater amount and quality of information will be communicated and less will be concealed. Amicability is closely followed by the trust that people have for one another and the sense of community that they share. Sometimes amicability can run too high, people can be so worried about offending their colleagues that they are afraid to disagree with them or be afraid to take the initiative for fear of being perceived as glory seekers.www.StarPMO.comKanban BoardA Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal MarketableFeature, Plain Old Requirement or something else. This is different from a task-board, which generally focuseson visualizing the current tasks.A Kanban System manages the flow of these units of value, through the use of “Work In Process limits”. This isdifferent from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the endof a time-box. A Kanban System deals with these units of value through the whole system, from when theyenter a teams control, until when they leave it. This is different from a task-board, which generally only dealswith the work in the build/test stage, but shows no information about what work is being prepared, or whatwork is ready for release.
    • By putting these 3 properties of a Kanban System together, we can describe a Kanban System for SoftwareDevelopment as one which allows value to flow through the whole system using WIP limits to create asustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System todemonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIPLimits can be adjusted and their effect measured as the Kanban System is continuously improved.A task-board simply shows what development tasks have been predicted to be done in the current time-box,with their status.www.StarPMO.comAgile Iteration PlanningAfter the iteration demo and retrospective are complete, iteration planning begins. Start by measuring thevelocity of the previous iteration. Take all of the stories that are "done done" and add up their originalestimates. This number is the amount of story points you can reasonably expect to complete in the upcomingiteration.Be sure to use estimated time, not actual time, when calculating velocity. This allows the velocity to accountfor interruptions and other overhead. With your velocity in hand, you can select the stories to work on thisiteration. Ask your customers to select the most important stories from the release plan. Select stories thatexactly add up to the teams velocity. You may need to split stories or include one or two less importantstories to make the estimates add up perfectly.Because the iteration planning meeting takes stories from the front of the release plan, you should havealready estimated and prioritized those stories. As a result, selecting stories for the iteration plan should onlytake a few minutes, with perhaps ten or 15 minutes more to explain.www.StarPMO.comSize Estimation: Story PointsPoints is a relative measure that can be used for agile estimation of size. The team decides how big a point is,and based on that size, determines how many points each work item is. To make estimation go fast, use onlyfull points, 1, 2, 3, 5, 8, and so on. To get started, look at 10 or so representative work items, give the smallestthe size of one point, and then go through all other work items and give them a relative point estimate basedon that point. Note that points are used for high-level estimates, so do not spend too much time on any oneitem. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikelyto be addressed within the current iteration.Use non linear number sequence (Like Fibonacci numbers) to determine size as humans can differentiate non-linear numbers better than linear number sequences.A key benefit of points is that they are neutral and relative. There may be disagreement about the actualeffort required to do it, but we do not care at this point in time, we only want the team to agree on the
    • relative size. We will later use Velocity to determine how much size, or how many points, the team can takeon within an iteration.www.StarPMO.comSpike SolutionIt is a technical investigation or experiment to research the answer to a problem (For example, you want toknow if C# throws an exception on floating point overflow, you can do a quick spike to find the answer)The biggest problem with Spike solution is that it takes time to experiment which is going to be wasted afterthe solution is found. A Spike Solution:1) Is an experimental solution that cuts through all the "layers.“2) Is necessarily time-boxed.3) Is always intended to be thrown away.Spike – a spike is a quick and dirty implementation to show that the suggested solution would work. It doesnot follow the laid down architecture and might be done in a different language all together. For example aspike could be done in RoR and then later implemented in Java. These are more like prototypes and arethrown away. www.StarPMO.comSize Estimation: Ideal daysIdeal days are the imaginable amount of time that would be spent on the project if there were nointerruptions (including email checking), everybody was working full time at full speed without any vacationsand everything needed was present from the day one.Pros: • The concept of ideal time is relatively simple to explain both to developers and their bosses.Cons: • Since both elapsed and ideal times are measured in the same units, they tend to mix • Not everybody is eager to accept that in a real world week there can be only two-three full ideal work days • Since team skills and the understanding of the subject area raise over time, ideal day estimations tend to decay and have to be readjusted often • Ideal days can be difficult to sum. My ideal days are not equal to yours www.StarPMO.comAgile Exploratory TestingExploratory testing is a style of testing in which one learns about the software while simultaneously designingand executing tests, using feedback from the previous tests to inform the next. This helps discover emergentbehavior, unexpected side effects etc. Four tools are helpful for exploratory testing. They are: 1. Charter: A small document providing information about what to explore and what of things to look for in the system. 2. Observation: Based on observations of code. 3. Note taking: To prevent where you have been and where you are going, can take the aid of a notepad. Take notes of what might need further exploration.
    • 4. Heuristics: A guide which helps in explorations (Like boundary testing)www.StarPMO.comIteration VelocityVelocity is the number of story points completed in an iteration. Ways to increase velocity: 1. Pay down technical debt 2. Improve customer involvement 3. Support energized work 4. Offload programmer other admin duties 5. Provide necessary resources www.StarPMO.comAgile PersonasA persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind ofperson who would interact with it. The idea is that if you want to design effective software, then it needs tobe designed for a specific person. For the bank, potential personas could be named Frances Miller and RossWilliams. In other words, personas represent fictitious people which are based on your knowledge of realusers.You’re likely familiar with actors. Unlike actors, personas are not roles which people play. In use case modelingactors represent the roles that users, and even other systems, can take with respect to your system. Forexample, in a banking application we would have actors such as Customer and Credit Card Processor. Actorsare often documented by a sentence or two describing the role. For example the description for Customermight read “A person or organization which does business with the bank.”Personas are different because they describe an archetypical instance of an actor. In a use case model wewould have a Customer actor, yet with personas we would instead describe several different types ofcustomers to help bring the idea to life. www.StarPMO.comTest Drive Development (TDD)Test-driven development (TDD) is a software development process that relies on the repetition of a very shortdevelopment cycle: first the developer writes a failing automated test case that defines a desiredimprovement or new function, then produces code to pass that test and finally refactors the new code toacceptable standards. A 2005 study found that using TDD meant writing more tests and, in turn, programmersthat wrote more tests tended to be more productive.Programmers using pure TDD on new ("greenfield") projects report they only rarely feel the need to invoke adebugger. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the codeto the last version that passed all tests may often be more productive than debugging.Test-driven development offers more than just simple validation of correctness, but can also drive the designof a program. By focusing on the test cases first, one must imagine how the functionality will be used byclients (in the first case, the test cases). So, the programmer is concerned with the interface before theimplementation. This benefit is complementary to Design by Contract as it approaches code through test casesrather than through mathematical assertions or preconceptions.
    • Test-driven development offers the ability to take small steps when required. It allows a programmer to focuson the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are notconsidered initially, and tests to create these extraneous circumstances are implemented separately. Test-driven development ensures in this way that all written code is covered by at least one test. This gives theprogramming team, and subsequent users, a greater level of confidence in the code.Test-driven development is difficult to use in situations where full functional tests are required to determinesuccess or failure. Examples of these are user interfaces, programs that work with databases, and some thatdepend on specific network configurations. TDD encourages developers to put the minimum amount of codeinto such modules and to maximize the logic that is in testable library code, using fakes and mocks torepresent the outside world.Management support is essential. Without the entire organization believing that test-driven development isgoing to improve the product, management may feel that time spent writing tests is wasted. www.StarPMO.comTracer BulletPragmatic Programmers usually prefer a "Tracer Bullet" which: 1) Is an experimental solution that cuts through all the "layers" of the architecture. 2) Is not necessarily time-boxed. 3) Is not intended to be thrown away.It is of production quality and rest of the iterations can build on this code. www.StarPMO.com