Do Think OUT of BOX

These are few questions asked in an interview! The answers are really stunning and inspiring.

Thinking out of the box! A must read…

Question 1:

You are driving along in your car on a wild, stormy night, it’s raining heavily, when suddenly you pass by a bus stop, and you see three people waiting for a bus:

1. An old lady who looks as if she is about to die.
2. An old friend who once saved your life.
3. The perfect partner you have been dreaming about.

Which one would you choose to offer a ride to, knowing very well that there could only be one passenger in your car?

This is a moral/ethical dilemma that was once actually used as part of a job application.

He simply answered:
I would give the car keys to my Old friend and let him take the lady to the hospital. I would stay behind and wait for the bus with the partner of my dreams.

Sometimes, we gain more if we are able to give up our stubborn thought limitations. Never forget to Think Outside of the Box.?

Question 2:

What will you do if I run away with your sister?

The candidate who was selected answered, “I will not get a better match for my sister than you sir”

Question 3:

Interviewer (to a student girl candidate) : What if one morning you woke up & found that you were pregnant.

Girl – I will be very excited and take an off, to celebrate with my husband.

Normally an unmarried girl will be shocked to hear this, but she managed it well. Why I should think it in the wrong way, she said later when asked.

Question 4:

Interviewer: He ordered a cup of coffee for the candidate. Coffee arrived kept before the candidate, then he asked what is before you?

Candidate: Instantly replied: “Tea”

He got selected.

You know how and why did he say TEA, when he knows very well that coffee was kept before.
(Answer: The question was What is before you (U, alphabet) Reply was TEA ( T, alphabet). Alphabet T is before Alphabet U.

Question5:

Interviewer said: “I shall either ask you ten easy questions or one really difficult question.”

Think well before you make up your mind! The boy thought for a while and said, my choice is one really difficult question.?

Well, good luck to you, you have made your own choice!

Now tell me this. What comes first, Day or Night?

The boy was jolted into reality as his admission depends on the correctness of his answer, but he thought for a while and said, “It’s the DAY sir!?”

How? the interviewer asked.

Sorry sir, you promised me that you will not ask me a SECOND difficult question!?

Sometimes just thinking out of the box is all it takes!
Share with your friend and give them a special moment of thinking…!!

.

Source: http://funnychutkule.com/1990/very-difficult-questions-with-amazing-answers-out-of-the-box-thinking/

Who the hell is Agile?

Agile Methodology

The goal of Agile Methods is to allow an organization to be agile, but what does it mean to be Agile? Agile means being able to “Deliver quickly. Change quickly. Change often” While Agile techniques vary in practices and emphasis, they share common characteristics, including iterative development and a focus on interaction, communication, and the reduction of resource-intensive intermediate artifacts. 

Developing in iterations allows the development team to adapt quickly to changing requirements. Working in close location and focusing on communication means teams can make decisions and act on them immediately, rather than wait on correspondence. Reducing intermediate artifacts that do not add value to the final deliverable means more resources can be devoted to the development of the product itself and it can be completed sooner. These characteristics add maneuverability to the process, whereby an Agile project can identify and respond to changes more quickly than a project using a traditional approach. 

Agile Methods

Agile Methods have much in common, such as what they value, but they also differ in the practices they suggest. In order to characterize different methods, we will examine the following Agile Methods:

• Extreme Programming
• Scrum
• Crystal Methods
• Feature Driven Development
• Lean Development
• Dynamic Systems Development Methodology.

Extreme Programming

Extreme Programming is undoubtedly the hottest Agile Method to emerge in recent years. Introduced by Beck, Jeffries, and further popularized by Beck’s Extreme Programming. XP owes much of its popularity to developers disenchanted with traditional methods looking for something new, something extreme. The 12 rules of Extreme Programming, true to the nature of the method itself, are concise and to the point. In fact, you could almost implement XP without reading a page of Beck’s book.

• The planning game: At the start of each iteration, customers, managers, and developers meet to flesh out, estimate, and prioritize requirements for the next release. The requirements are called “user stories” and are captured on “story cards” in a language understandable by all parties.

• Small releases: An initial version of the system is put into production after the first few iterations. Subsequently, working versions are put into production anywhere from every few days to every few weeks.

• Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after which to model the system.

• Simple design: Developers are urged to keep design as simple as possible, “say everything once and only once”.

• Tests: Developers work test-first; that is, they write acceptance tests for their code before they write the code itself. Customers write functional tests for each iteration and at the end of each iteration, all tests should run.

• Refactoring: As developers work, the design should be evolved to keep it as simple as possible.

• Pair programming: Two developers sitting at the same machine write all code.

• Continuous integration: Developers integrate new code into the system as often as possible. All functional tests must still pass after integration or the new code is discarded.

• Collective ownership: The code is owned by all developers, and they may make changes anywhere in the code at anytime they feel necessary.

•On-site customer: A customer works with the development team at all times to answer questions, perform acceptance tests, and ensure that development is progressing as expected.

• 40-hour weeks: Requirements should be selected for each iteration such that developers do not need to put in overtime.

• Open workspace: Developers work in a common workspace set up with individual workstations around the periphery and common development machines in the center. Because the development team needs to be co-located, team size is limited to the number of people that can fit in a single room, generally agreed to be from 2 to 10.

Iteration length: XP has the shortest recommended iteration length of the Agile Methods under consideration, 2 weeks.

Support for distributed teams: Because of XP’s focus on community and collocation, distributed teams are not supported.

System criticality: XP is not necessarily geared for one system or another. However, most agree that there is nothing in XP itself that should limit its applicability. 

Scrum 

Scrum, along with XP, is one of the more widely used Agile Methods.

Pre-sprint planning: All work to be done on the system is kept in what is called the “release backlog.” During the pre-sprint planning, features and functionality are selected from the release backlog and placed into the “sprint backlog,” or a prioritized collection of tasks to be completed during the next sprint. Since the tasks in the backlog are generally at a higher level of abstraction, pre-sprint planning also identifies a Sprint Goal reminding developers why the tasks are being performed and at which level of detail to implement them

Sprint: Upon completion of the pre-sprint planning, teams are handed their sprint backlog and “told to sprint to achieve their objectives”. At this point, tasks in the sprint backlog are frozen and remain unchangeable for the duration of the sprint. Team members choose the tasks they want to work on and begin development. Short daily meetings are critical to the success of Scrum. Scrum meetings are held every morning to enhance communication and inform customers, developers, and managers on the status of the project, identify any problems encountered, and keep the entire team focused on a common goal.

Post-sprint meeting: After every sprint, a post-sprint meeting is held to analyze project progress and demonstrate the current system.

Key principles of Scrum:

• Small working teams that maximize communication, minimize overhead, and maximize sharing of tacit, informal knowledge.

• Adaptability to technical or marketplace (user/customer) changes to ensure the best possible product is produced. Frequent ‘builds,’ or construction of executables, that can be inspected, adjusted, tested, documented, and built on.

• Partitioning of work and team assignments into clean, low coupling partitions, or packets.

• Constant testing and documentation of a product as it is built.

• Ability to declare a product ‘done’ whenever required (because the competition just shipped, because the company needs the cash, because the user/customer needs the functions, because that was when it was promised.

Team size: Development personnel are split into teams of up to seven people. A complete team should at least include a developer, quality assurance engineer, and a documenter.Iteration length: While Schwaber originally suggested sprint lengths from 1 to 6 weeks, durations are commonly held at 4 weeks.

Support for distributed teams: While Scrum’s prescription does not explicitly mention distributed teams or provide built-in support; a project may consist of multiple teams that could easily be distributed.

System criticality: Scrum does not explicitly address the issue of criticality. 

The Crystal Methods

To the extent that you can replace written documentation with face-to-face interactions, you can reduce the reliance on written work products and improve the likelihood of delivering the system. The more frequently you can deliver running, tested slices of the system, the more you can reduce the reliance on written ‘promissory’ notes and improve the likelihood of delivering the system” As you add people to the project, you translate right on the graph in to more opaque versions of crystal. As project criticality increases, the methods “harden” and you move upwards on the graph. The methods can also be altered to fit other priorities, such as productivity or legal liability. All Crystal methods begin with a core set of roles, work products, techniques, and notations, and this initial set is expanded as the team grows or the method hardens.

Team size: The Crystal Family accommodates any team size; however, Cockburn puts a premium on premium people.

Iteration length: Up to 4 months for large, highly critical projects.

Support for distributed teams: Crystal Methodologies have built in support for distributed teams.

System criticality: Crystal supports 4 basic criticalities: failure resulting in loss of comfort, discretionary money, essential money, and life.  

Feature Driven Development 

FDD’s core values:

• A system for building systems is necessary in order to scale to larger projects.

• A simple, well-defined process works best.

• Process steps should be logical and their worth immediately obvious to each team member.

• ‘Process pride’ can keep the real work from happening.

• Good processes move to the background so the team members can focus on results.

• Short, iterative, feature-driven life cycles are best.

Develop an overall model: The FDD process begins with developing a model. Team members and experts work together to create a “walkthrough” version of the system.

Build a features list: Next, the team identifies a collection of features representing the system. Features are small items useful in the eyes of the client. They are similar to XP story cards written in a language understandable by all parties. Features should take up to 10 days to develop. Features requiring more time than 10 days are broken down into sub features.

Plan by feature: The collected feature list is then prioritized into subsections called “design packages.” The design packages are assigned to a chief programmer, who in turn assigns class ownership and responsibility to the other developers. Design by feature & build by feature: After design packages are assigned, the iterative portion of the process begins. The chief programmer chooses a subset of features that will take 1 to 2 weeks to implement. These features are then planned in more detail, built, tested, and integrated.

Team size: Team size varies depending on the complexity of the feature at hand

Iteration length: Up to two weeks.

Support for distributed teams: FDD is designed for multiple teams and, while it does not have built-in support for distributed environments, it should be adaptable.Criticality: The FDD prescription does not specifically address project criticality. 

Lean Development

Lean Development’s12 principles focus on management strategies:

(1) Satisfying the customer is the highest priority.

(2) Always provide the best value for the money.

(3) Success depends on active customer participation.

(4) Every LD project is a team effort.

(5) Everything is changeable.

(6) Domain, not point, solutions.

(7) Complete, do not construct.

(8) An 80 percent solution today instead of 100 percent solution tomorrow.

(9) Minimalism is essential.

(10) Needs determine technology.

(11) Product growth is feature growth, not size growth.

(12) Never push LD beyond its limits.Because LD is more of a management philosophy than a development process, team size, iteration length, team distribution, and system criticality are not directly addressed.   

Dynamic Systems Development Method 

DSDM lifecycle has six stages: Pre-project, Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration, Implementation, and Post-project.  

Pre-project: The pre-project phase establishes that the project is ready to begin, funding is available, and that everything is in place to commence a successful project.  

Feasibility study: DSDM stresses that the feasibility study should be short, no more than a few weeks. Along with the usual feasibility activities, this phase should determine whether DSDM is the right approach for the project.

Business study: The business study phase is “strongly collaborative, using a series of facilitated workshops attended by knowledgeable and empowered staff who can quickly pool their knowledge and gain consensus as to the priorities of the development”. The result of this phase is the Business Area Definition, which identifies users, markets, and business processes affected by the system.

Functional model iteration: The functional model iteration aims to build on the high-level requirements identified in the business study. The DSDM framework works by building a number of prototypes based on risk and evolves these prototypes into the complete system. This phase and the design and build phase have a common process:(1) Identify what is to be produced.(2) Agree how and when to do it.(3) Create the product.(4) Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the system)

Design and build iteration: The prototypes from the functional model iteration are completed, combined, and tested and a working system is delivered to the users.

Implementation: During this phase, the system is transitioned into use. An Increment Review Document is created during implementation that discusses the state of the system. Either the system is found to meet all requirements and can be considered complete, or there is missing functionality (due to omission or time concerns). If there is still work to be done on the system, the functional model, design and build, and implementation phases are repeated until the system is complete.

Post-project: This phase includes normal post-project clean-up, as well as ongoing maintenance.Because of DSDM’s framework nature, it does not specifically address team size, exact iteration lengths, distribution, or system criticality. 

Agile Modeling 

Agile Modeling (AM) is proposed by Scott Ambler. It is a method based on values, principles and practices that focus on modeling and documentation of software. AM recognizes that modeling is a critical activity for a project success and addresses how to model in an effective and Agile manner.

The three main goals of AM are:

(1) To define and show how to put into practice a collection of values, principles and practices that lead to effective and lightweight modeling.

(2) To address the issue on how to apply modeling techniques on Agile software development processes.

(3) To address how you can apply effective modeling techniques independently of the software process in use.

AM is not a complete software development method. Instead, it focuses only on documentation and modeling and can be used with any software development process. You start with a base process and tailor it to use AM. Ambler illustrates, for example, how to use AM with both XP and Unified Process (UP) The values of AM include those of XP—communication, simplicity, feedback and courage—and also include humility. It is critical for project success that you have effective communication in your team and also with the stakeholder of the project. You should strive to develop the simplest solution that meets your needs and to get feedback often and early. You should also have the courage to make and stick to your decisions and also have the humility to admit that you may not know everything and that others may add value to your project effortsSince AM is not a complete software process development method and should be used with other development methods, the team size, exact iteration lengths, distribution and system criticality will depend on the development process being used. 

Conclusions
Agile Methods are here to stay, no doubt about it. Agile Methods will probably not “win” over traditional methods but live in symbiosis with them. While many Agile proponents see a gap between Agile and traditional methods, many practitioners believe this narrow gap can be bridged. Glass even thinks that “[t]raditionalists have a lot to learn from the Agile folks” and that “traditional software engineering can be enriched by paying attention to new ideas springing up from the field”. 

Why will Agile Methods not rule out traditional methods?
Agile Methods will not out rule traditional methods because diverse processes for software engineering are still needed. Developing software for a space shuttle is not the same as developing software for a toaster. Not to mention that the need to maintain software, typically a much bigger concern than development, also differs according to the circumstances. Software maintenance is, however, not an issue discussed in Agile circles yet, probably because it is too early to draw any conclusions on how Agile Methods might impact software maintenance. 

Where is Agile going?
Agile is currently an umbrella concept encompassing many different methods. XP is the most well known Agile Method. While there may always be many small methods due to the fact that their proponents are consultants who need a method to guide their work, we expect to see some consolidation in the near future. We compare the situation to events in the object-oriented world in the 1990s, where many different gurus promoted their own methodology. 

In a few years, Rational, with Grady Booch, became the main player on the method market by recruiting two of the main gurus: James Rumbaugh (OMT) and Ivar Jacobsson (Objectory). Quickly the “three amigos” abandoned the endless debates regarding whose method was superior, which mainly came down to whether objects are best depicted as clouds (Booch), rectangles (OMT), or circles (Objectory), and instead formed a unified alliance to quickly become the undisputed market leader for object-oriented methods. 

We speculate that the same can happen to the Agile Methods, based, for example, on the market-leader XP. Even if the Agile consolidation is slow or non-existent, what most likely will happen, independent of debates defining what is and is not Agile, practitioners will select and apply the most beneficial Agile practices. They will do so simply because Agile has proven that there is much to gain from using their approaches and because of the need of the software industry to deliver better software, faster and cheaper.                                                         

Looks like the Explorer is jumping to No man’s Land..

Here comes the amplification of Microsoft's product Internet Explorer getting obsolete.

With the development of Windows 10, microsoft has its plan to bring in alternate for Internet explorer. Hence bringing a light weight browser (yet to be named officially, but unofficially called as spartan), which is similar to Google chrome (or) Mozilla firefox. With windows 10, both the browsers will be available for use along with the operating system pack.

After windows 10, microsoft is thinking whether to continue with internet explorer or not. But the existing OS services, where the IE is available, the services and support would still continue.

So the long continued browser started in 1994 with version 1.0 has made its all its way to version 1.12 here in 2015. Lets hear for further updates from Microsoft.

Source: http://www.techradar.com/news/internet/microsoft-is-going-to-kill-internet-explorer-1288578