Software the Agile Way....

The first is the number of defects found after development.  An  XP  team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some  XP  teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve. The second metric is the time lag between the beginning of investment in an idea and when the idea first generates revenue.   Even small organizations typically find they take more than a year from investment to return. Gradually reducing the time from investment to return increases the amount and timeliness of feedback available to the whole team. Both post-development defects and investment-to-return are indicators of team effectiveness much as a speedometer is an indicator of speed. You don't make a car go faster by grabbing the speedometer needle and moving it over. If you wan...

In an ideal system the below mentioned non functional characteristics could be imagined: Highly Secure Very High performance  Massive flexible  Extremely Scalable  Easy to use Easy to support Simple to develop and maintain However this comes with a cost hence a careful up front analysis should be done to make an informed  decision on what architecture to choose for the system. Suggestion is to involve all the people involved in the delivery in the beginning of the project to think through the application. This would help identify the impact on below mentioned activities: System architecture Project schedule Test strategy Overall Cost Stories with clear acceptance criteria must be created so that these could be tracked and thinking is evaluated. Remember to avoid such acceptance criteria :  Response time must be "as fast as possible"  If no further analysis is done on such criteria then there are possibility of adding comple...

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.

S mall releases -  By the end of each iteration( 2 to 3 weeks long)  the team is responsible for delivering working, tested code that can immediately be put to use. The p lanning game -  Prior to the start of each iteration, the team and customer plan the iteration. This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story . R efactoring -  Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting  of code so as to improve the code without changing its external behavior.Refactoring is one of technique used by XP to replace upfront design. T esting -  XP puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003). On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or ...

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon...

Problem Many teams start out with good intentions and then have quality erode as people go through the motions due to burn out or just no longer having fun.  Solution 1. For sustainability, the team really should own and evolve their standards instead of them being handed a bible. 2. Also, it is more critical to get early momentum through delivery of working software and feedback on that software than to get bogged down in the minutiae of a specific standard.  3. I suggest starting with the minimum that the team reaches a quick consensus on as necessary from the beginning and then add/subtract from it as feedback and experience indicates to the whole team. The standards can and should change over time. The key is clarity , testability , extensibility and maintainability of the code itself.  4. It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one tea...

Having 100% coverage doesn't guarantee the lack of defects—it only guarantees that all of your code was executed, regardless of whether your application behaves like it should.  So rather than obsessing about code coverage, focus your attention on making sure that the tests you do write are meaningful.

Team Formation Requirement workshop and identifying the Epics and stories Initial technical architecture Initial Release goal Secure Funding Development Environment setup  Risks identification

Agile is a cultural change that impacts people, processes and tools in different ways across the organization; based on iterative, time boxed and incremental approach , where requirements and solutions evolve through collaboration between self-organizing and cross-functional teams , Agile promotes adaptive planning , evolutionary development and delivery and encourages a rapid and flexible response to change . 

S stands for SRP (Single responsibility principle):- A class should take care of only one responsibility. O stands for OCP (Open closed principle):- Extension should be preferred over modification. L stands for LSP (Liskov substitution principle):- A parent class object should be able to refer child objects seamlessly during runtime polymorphism. I stands for ISP (Interface segregation principle):- Client should not be forced to use a interface if it does not need it. D stands for DIP (Dependency inversion principle) :- High level modules should not depend on low level modules but should depend on abstraction.

Spike are type of Story that are used for activities such as research,design,exploration and even prototyping. Functional Spike- It is used to list out the scenarios which can influence the implementation. Technical Spike- It is used to determine the Feasibility and impact of design strategy.