This methodology describes the approach and organization of work in creation of software products. Learn more about the MSF methodology you can read in the translation of Microsoft Solutions Frameworks for Agile Software Development included with Microsoft Team Foundation Server.
Scrum provides an empirical approach to software development. This the process is fast, adaptive, able to adapt and different from the cascading models. Scrum is based on iterative cycles, which makes it more flexible and predictable.
The Scrum Master is the most important role in the methodology. Scrum Master responsible for the success of Scrum on the project. As a rule, this role in the project is played by project manager or team leader. Important emphasize that the Scrum Master does not distribute tasks to team members. At the Scrum team is self-organizing and self-managing.
The main responsibilities of the Scrum Master are:
- creates an atmosphere of trust;
- participates in rallies as a facilitator – a person, ensuring successful group communication;
- removes obstacles;
- makes problems and open questions visible;
- responsible for following the practices and process in the team.
Scrum Master tracks team progress using Sprint Backlog, marking the status of all tasks in the sprint. The Scrum Master can also help the customer create a list of tasks for the team.
The Product Owner is the person responsible for the development of the product. As a rule, a representative of the customer for custom development. Owner product is a single point of final decision-making for teams in the project, which is why it is always one person, not a group or committee.
Team (Team) – in the Scrum methodology, the team is self-organizing and self-governing. The team takes over obligations to fulfill the scope of work for the sprint to the Owner product. The work of the team is evaluated as the work of a single group. At Scrum contributions of individual members of the project team are not evaluated, so how it destroys the self-organization of the team.
Team size is limited by the size of the group of people able to communicate effectively face to face. Typical the team size is 7 plus or minus 2. The team in Scrum is cross-functional. It includes people with different skills – developers, analysts, testers. There are no predefined and divided roles in team, limiting the scope of actions of team members. Command consists of engineers who contribute to the overall success of the project according to their abilities and project needs.
It is based on short daily meetings – Scrum and cyclical 30-day meetings called sprints. Result sprint is a finished product that can be transferred to the customer (at least the system should be ready to show to the customer).
Short sprints provide quick feedback project team with the customer. The customer gets the opportunity to flexibly manage the system by evaluating the sprint result and suggesting improvements to the created functionality. These improvements are listed current business requirements and technical system requirements (Product Backlog), prioritized along with other requirements and can be scheduled for the next (or one of the following) sprints. Each sprint is small waterfall. During the sprint, all work is done to collect requirements, design, coding and product testing.
The sprint goal should be fixed. This allows the team commit to the amount of work that must be done in sprint. This means that the Sprint Backlog cannot be changed by anyone except for the team.
The XP methodology developed by Kent Beck, Ward Cunningham (Ward Cunningham) and Ron Jeffries (Ron Jeffries), is one of the most popular agile methodologies today. She is described as a set of practices: planning game, short releases, metaphors, simple design, code refactoring, development Tests Ahead, Pair Programming, Shared Ownership code, 40-hour work week, constant presence of the customer and code standards.
Interest in XP grew from the bottom up – from developers and testers, tortured by a painful process, documentation, metrics and other formalism. They didn’t deny discipline, but they didn’t wish senselessly comply with formal requirements and were looking for new fast and flexible approaches to the development of high-quality programs.
When using XP, a thorough preliminary software design is replaced, on the one hand, by constant the presence in the customer’s team, ready to answer any question and evaluate any prototype, and on the other hand, regular code revisions (so-called refactoring). The basis of project documentation heavily commented code is considered. Very big the emphasis in the methodology is on testing. As a rule, for of each new method, a test is first written, and then the method code itself is developed until the test starts run successfully. These tests are stored in sets that are automatically executed after any code change.
While pair programming and the 40-hour work week and are perhaps the most famous features of XP, but still wear supportive nature and contribute to high performance developers and reduce the number of errors during development.
Lightweight agile methodology created by Alistair Cowburn, which is designed for small teams of 6-8 people to develop non-critical business applications. Like all flexible methodologies, Crystal Clear relies more on people than processes and artifacts. Crystal Clear uses seven methods/practices, three of which are mandatory:
- frequent delivery of the product;
- improvements through reflection;
- personal communications;
- a sense of security;
- easy access to experts;
- high-quality technical environment.
Crystal Clear methodology is inferior to XP in terms of performance, but very easy to use. It requires minimal efforts for implementation, because it is focused on human habits. It is believed that this methodology describes that natural order of software development, which is established in sufficient qualified teams, if they do not work purposeful introduction of another methodology. Key Features of Crystal Clear:
- iterative incremental development;
- automatic regression testing;
- users are involved in active participation in the project;
- the composition of the documentation is determined by the project participants;
- as a rule, code version control tools are used.
In this chapter, only a few of the most main methodologies, in fact there are many more, for example ICONIX, Kanban, Feature-driven development and others. Each methodology is applied depending on the type of software product, and defines the software design process.