Software the Agile Way....

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. DevOps is also characterized by operations staff making use many of the same techniques as developers for their systems work. “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. “Dev” is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product,” which can include Product, QA, and other kinds of disciplines. DevOps Practices  –Specific techniques used as part of implementing the above concepts and processes. Continuous integration and continuous deployment, “Give your developers a pager and put them on call,” using configuration manage...

Ward Cunningham  coined the term , and Martin Fowler has some  good takes  on the subject, and  Ron Jeffries  as well. Technical Debt includes those  internal  things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical Debt doesn't include deferred functionality, except possibly in edge cases where delivered functionality is "good enough" for the customer, but doesn't satisfy some standard (e.g., a UI element that isn't fully compliant with some UI standard). During the planning or execution of a software project, decisions are made to defer necessary work. For example: It's too late in the LifeCycle ?  to upgrade to the new release of the compiler. We'll do it next time around. We're not completely conforming to the  UserInterface  guidelines. We'll get to it next time. We don't have time to uncruft (refactor, see  RefactorMercilessly ) t...

Scrum framework is deliberately light in defining this as there are many existing practices is requirement gathering that work well. Scrum does not want to impose any one style and allow the organisation to choose what is best for them.  Product Owner should  - Establish a vision for the project to constrain the scope  - Talk to his/her users and get high level business requirements.  - Order them so they give value to the organisation and meet the scope of the project (or change the scope if not originally correct)  - Work with the team to define what is a "Ready" requirement.  - With team refine them into functional requirements that can actually be built  - Constantly adapt as more knowledge is learnt or gained  This is a continual process

A project has a short lifespan, it has a start and and end. The product live is longer than a project.  A project may not necessarily deliver all Product Backlog Items, especially low value items. These may be postponed until a future date.  Defects and change requests happen post the project, these are added to the products backlog which can then be managed. A product backlog typically contains the following 3 types of stories  1. New features  2. Defects  3. Engineering - Stories for optimizing/refactor the current code, a effort undertaken to reduce the tech debt 

Neutral view points Inspection of Scrum implementation Coaching to improve Identify opportunities shield team from external disruptions remove blocks Facilitate communication Mediate conflict Incrementally help make changes to process Keep team focused

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.

WHAT ARE FACILITATION SKILLS? One of the most important sets of skills for leaders are facilitation skills. These are the "process" skills we use to guide and direct key parts of our organizing work with groups of people such as meetings, planning sessions, and training of our members and leaders. Facilitation has three basic principles: A facilitator is a guide to help people move through a process together, not the seat of wisdom and knowledge. That means a facilitator isn't there to give opinions, but to draw out opinions and ideas of the group members. Facilitation focuses on  how  people participate in the process of learning or planning, not just on  what gets achieved A facilitator is neutral and never takes sides facilitating actually means: Understanding the goals of the meeting and the organization Keeping the group on the agenda and moving forward Involving everyone in the meeting, including drawing out the quiet participants and controll...

1.  HP LoadRunner Performance testing for websites is something which, in the past, was mostly done with software tools installed on local machines. Take for example HP's  LoadRunner , probably the most well known tool in the world of performance testing (it’s been around for a while). 2. JMeter - Advanced Open Source Option JMeter is an open source project that is very similar to LoadRunner as far as technical capabilities go. It essentially runs simulated, virtual users that make all of the requests that a real browser would make. The JMeter Challenge Like many open source, developer-oriented platforms, the real challenge with JMeter is that it was written with a focus on technical functionality and not on user experience. For example, in JMeter, a virtual user is called a ‘thread’, whereas other tools use the terms 'virtual user', 'simulated user', or even simply, 'user'. JMeter also makes use of the term 'sampler', whi...

The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.The primary goal of the technique is to determine the root cause of a defect or problem. (The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.) A key phrase to keep in mind in any 5 Why exercise is "people do not fail, processes do". Source-  5 Whys Example-  The vehicle will not start. (the problem) Why?  - The battery is dead. (first why) Why?  - The alternator is not functioning. (second why) Why?  - The alternator belt has broken. (third why) Why?  - The alternator belt was well beyond its useful service life and not replaced. (fourth why) Why?  - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)

All projects have risks and the risks have the potential for negatively impacting the project. (I am not referring to opportunity (positive) risk.)   Try to Include Budget and Schedule for Unknown Risks A project manager can request additional budget and schedule to account for known risks at the beginning of a project. Of course, the risk contingency does not include the full impact of risk. Instead you multiply impact by the percentage likelihood for all high risks. Then add the numbers to come up with a risk contingency budget and schedule. However, risk identification is not something that only happens at the beginning of a project. The project manager assesses risks throughout the project.  Therefore, it makes sense to include time and budget for unknown risks as a part of your estimating process. If you do an effective job of periodically reassessing risks, you may find new risks to manage that were not included in the original risk contingency budget. You can...