Sunday, April 6, 2014

Taking backup of Filezilla FTP client settings

Hi Friends,

I use FileZilla FTP client to transfer files using FTP.  I found it amazing and got it for free from https://wiki.filezilla-project.org/Main_Page

I have stored many sites in site manager with various kinds of settings so that I can quickly connect to these FTP sites and reach the desired location as soon as I connect to those FTP sites. Many times I wanted to transfer these site's and other settings onto some other machines due to change of machines, machine reformatting, etc.

Here are the easy techniques to take backup and restore the FileZilla client settings.

Option-1:  Export one particular site only
If you want to export only one site from the list of sites then follow simple steps below:

1. Open site Manager either by clicking ctrl+s or from File->Site Manager menu






2. Right click and select export.




3. Save it by giving some meaningful name.  It will create xml file

4. Copy this xml file to new machine and import it from File->Import menu



Option-2:  Export all the site only
If you want to export only one site from the list of sites then follow simple steps below:

1. From File->Export menu



2. Select the categories you want to export. It gives 3 categories to export as shown in screenshot below.





3. Save it by giving some meaningful name.  It will create xml file

4. Copy this xml file to new machine and import it from File->Import menu

Friday, April 4, 2014

Agile Methodology Myths busted

Myth-1: Each team member in Agile Scrum method should do everything

Agile says Scrum teams should be self-organizing and cross-functional.  It means scrum team as a whole should be having necessary skills to create product increment.  This doesn't mean that each individual in team should be cross-functional.  In Agile, each team member is called developer having different skills like Designer, Programmer, Tester, etc.  Agile doesn't mean and doesn't want to kill the expertise of the people.  


Myth-2: Agile means no documentation

Agile never says that there should be any documentation.  Documentation is important but focus should be on working software instead of comprehensive documentation.  Agile says, we should get rid of documentation which doesn't add value.  For example: Low level design docs are important for future reference as well but creating estimation of how many defects testers are going to open in release doesn't make any sense. How can anyone forecast, how many defects would be raised :-)


Myth-3: Agile means no planning


On the contrary, Agile requires more planning.  Only difference between planning in Waterfall and Agile methods is when planning is done.  In Waterfall model, whole planning is done at the start of the release cycle, whereas in Agile small amount of planning is done to fix the Time and Cost of the project at the start of the release and team continue to do sprint planning to pick up the tasks which is most important for the customer


Myth-4: Agile means lack of discipline


This is utmost false. Agile brings sense of responsibility and discipline in each team member.  It brings people together and commitment at each step and it demands that each individual be responsible to deliver whatever he has agreed too. The daily interactions enhance this sense of responsibility, which is not the case when people hide behind documents and bureaucratic obstacles.  So, it actually demands more responsibility and a discipline enforced by the collective.

The rule of keeping a sustainable pace – which means avoiding overtime – requires a serious commitment against procrastination. The ideal velocity of the team should be determined, and maintained. The iterations are short, so any lagging will be promptly noticed.


What is "Agile" Methodology

Lets first try to define what is Agile Methodology?

Agile Methodology is an alternative development methodology to traditional project management like waterfall model. Agile Methodology encourages rapid and flexible response to changes.  Heart of Agile Methodology is defined in Agile Manifesto.


Components which comes into consideration when we do project management.
  1. Time
  2. Budget
  3. Scope
  4. Quality
In Traditional Waterfall model, Time-Cost-Scope remains fixed and if project is behind schedule it makes quality go down.  Whereas in Agile Model, Time-Quality-Cost remains fixed and scope varies as per time-boxed iterations.



Agile Manifesto
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan 


The meanings of the manifesto items on the left within the agile software development context are described below:
  • Individuals and interactions: In agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
  • Working software: Working software will be more useful and welcome than just presenting documents to clients in meetings.
  • Customer collaboration: Requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
  • Responding to change: Agile development is focused on quick responses to change and continuous development.


Agile Manifesto is based on 12 principles:
  • Customer satisfaction by rapid delivery of useful software
  • Welcome changing requirements, even late in development
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Sustainable development, able to maintain a constant pace
  • Close, daily co-operation between business people and developers
  • Face-to-face conversation is the best form of communication (co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity- The art of maximizing the amount of work not done - is essential
  • Self-organizing teams
  • Regular adaptation to changing circumstances


Well-known Agile software development methods:
  • Agile Modeling
  • Agile Unified Process (AUP)
  • Crystal Clear
  • Crystal Methods
  • Dynamic Systems Development Method (DSDM)
  • Extreme Programming (XP)
  • Feature Driven Development (FDD)
  • GSD
  • Kanban (development)
  • Lean software development
  • Scrum
  • Velocity tracking

Everything you want to know about Agile Scrum Team

Scrum team builds the product (software, website, etc) that the consumer consumes.  Scrum ideally consists of core roles and additional roles.  But, whenever we talk about scrum team that means we are talking about core roles only. 

Core Roles
  • Product Owner
  • Development team
  • Scrum Master
Additional Roles
  • Stakeholders
  • Managers
  • Users

 Scrum teams consists of following features:
  • Team size for scrum team should be 7 plus or minus 2
  • Team should be cross-functional.  Cross-functional teams have all the competencies required to accomplish the work without depending on others who are not part of the team. As we can see there are no testers, coders, programmers, in scrum team.  All the members except Product Owner and Scrum master are called developers.  Developers could be having different skills like programmer, tester, designer, documentation, etc. 
  • Team should be able to do everything required to achieve sprint goals.  There is an misconception that every team member should be able to do everything.  Every scrum team should have developers with variety of skills like programmer, test, etc but every scrum team member is not supposed to do everything
  • Team should be Self-organizing.  Self-organizing teams chooses how best to accomplish their work, rather than being directed by others outside the team.
  • Scrum team should decide on scrum goals and results
  • Scrum team demos work to the Product owner and other stakeholders