Level 38

Agile is a series of software development approaches focused on the use of iterative development, the dynamic formation of requirements, and the provision of their implementation as a result of interaction within self-organizing working groups consisting of specialists of different profiles. There are several methods related to agile development methodology, in particular Extreme Programming, DSDM, Scrum, FDD.

Basic concepts of agile methods:

• people and interaction are more important than processes and tools;
• a working product is more important than comprehensive documentation;
• cooperation with the customer is more important than agreeing on the terms of the contract;
• readiness for change is more important than following the original plan.

The main principles of this approach were also formulated:

• Customer satisfaction through early and uninterrupted delivery of valuable software;
• welcome changes in requirements even at the end of development (this can increase the competitiveness of the product in the market);
• frequent delivery of working software (every month or every week, or even more often);
• close, daily communication between the customer and the developer throughout the project;
• the project is carried out by motivated individuals, provided with the necessary working conditions, support and trust;
• the recommended method of transferring information is a personal conversation (face to face);
• running software is the best measure of progress;
• sponsors, developers and users must maintain a constant pace indefinitely;
• constant attention to improvement of technical skill and user-friendly design;
• simplicity - the art of not doing unnecessary work;
• the best technical requirements, architecture and design come from a self-organized team;
• constant adaptation to changing conditions.

It was recognized that the main problem of the development was that none of the participants at any stage has complete information about what to do.

Scrum is one of the agile development techniques. It focuses on the quality control of the development process. The main feature of Scrum is the division of the development process into iterations with a clear time span (usually 2-6 weeks; they are called "sprints").

At the beginning of the sprint, a "sprint planning" is held - a meeting for 3-4 hours, where the main tasks that will be solved during the sprint are discussed. At the end of the sprint, a "demo" is held - a demonstration of the results of the team's work for this sprint.

Before the very first sprint, the customer (or his representative) forms a list of requirements for the future product. Such requirements are called "user story", and the customer is called "product owner". Also in this list, the customer (PO) indicates the priority for each task. Tasks with a higher priority will be implemented first. The whole list is called "product backlog", or "product backlog".

In addition to the product owner, scrum masters are also distinguished among the participants: he conducts all meetings, monitors compliance with all scrum principles, resolves contradictions and protects the team from distractions. Usually someone from the team acts as the Scrum Master.

At the first meeting at the beginning of the sprint, each task, in addition to being assigned a priority, is also given an approximate estimate in "abstract man-days", which is also called a "story point". The team then decides how many tasks they can complete during the sprint. For example, the customer has selected 7 tasks, and the team can only do 5. Then the remaining two tasks will go to the next sprint. If the customer does not like it, he can increase their priority, but then other tasks will fall out of the sprint. In addition, the Scrum Master can break down some tasks into smaller ones and prioritize them differently so that the customer is satisfied.

The list of selected tasks for the sprint is called the "sprint backlog", or "sprint reserve". For better clarity, a table is usually compiled, which indicates the tasks that need to be implemented, which are in the process of being implemented, and those that have already been completed. A "task burnout" diagram is also built. It graphically shows how many tasks are left to complete. Ideally, the task burnout schedule should drop to zero by the end of the sprint.

Also during the sprint, every day or every other day, small meetings are held within the team for 5-15 minutes, where each team member tells what he did during this day (or these two days), what he still has to do, and also talks about that prevents him from doing something.

When the sprint ends, the scrum-master hosts a demo that shows a list of everything that has been completed. Then a “debriefing” is held - a meeting also for a couple of hours. It usually tries to find out what was done well, and what (and how) could be done better.

Usually, in 2-3 sprints, you can identify the main problems that prevent the team from working more efficiently and eliminate them. This results in greater productivity without increasing the burden on the team. This was not possible before the era of agile methodologies.

Also in the middle of the sprint, sometimes there is also a “combing” - a meeting dedicated to planning the next sprint. It usually clarifies the priorities of tasks, and they can also break some tasks into parts and / or add new tasks to the product backlog - the product reserve.

In Scrum, participants are divided into "pigs" and "chickens". "Pigs" are fully involved in the process, "hens" - only partially. The following roles belong to the category of "pigs":

• Scrum master (holds meetings, monitors the implementation of scrum principles, etc.; this is someone from the team, the produst owner cannot be a scrum master);
• Product Owner (represents the interests of end users and other parties interested in the product);
• Development Team (a cross-functional team consisting of specialists from different profiles: developers, testers, designers, architects, etc. The team size is ideally from 3 to 9 people. The team is the only fully involved participant in the development and is responsible for the result as a whole.No one except the team can interfere with the development process during the sprint).

Chickens include the following roles:

• Users
• Customers, sellers (Stakeholders) (persons who initiate the project and for whom the project will benefit. They are involved in Scrum only during the Sprint Review meeting);
• Managers (people who manage staff);
• Consulting Experts.

A sprint is one iteration of the software development cycle in Scrum. Usually the sprint is rigidly fixed in time. The duration of the sprint is chosen based on the size of the team, the specifics of the work, the requirements, the size of the project. Most often this is selected empirically, based on trial and error. On average, a sprint can last from 2 to 4 weeks (although in some companies its duration can be even 6 weeks). To estimate the amount of work in a sprint, a preliminary estimate, measured in history points, can be used. The preliminary estimate is recorded in the project backlog.

QA stands for Quality Assuarance (that is, "Quality Assurance", if translated literally). Testers fall into this category. These are people who identify bugs and errors in the program. To do this, they use different means, both manual and automatic. After identifying bugs and errors, they report it to the developers, and they fix these errors.

The Product Owner (project owner) is the customer or the customer's representative. This is either someone on the client side (a third-party firm or individual), or some other employee of the firm who defines the requirements for the final product and monitors their implementation (for example, a business analyst). As already mentioned, it defines the requirements for the product and the tasks that the development team must solve in order to get the final product. He draws up a list of requirements (or tasks) in a certain order and with a given priority for each requirement (task). He is usually involved in the planning of the sprint (before the sprint starts) and in the demonstration of the results of the sprint (after the end of the sprint).

At the head of the exception hierarchy in Java is the Throwable. Two classes are not inherited from: Errorand Exception. First class objects are thrown away when some serious errors occur in the operation of the program and the java machine as a whole (as well as in the operation of the OS and computer hardware), so that the program can no longer continue to work and closes. This could be an out of memory error (OutOfMemoryError) or a stack overflow (StackOverflowError).

Instances of the second class can escape under a variety of exceptional situations. Actually, the class and all other classes are inherited from this class RuntimeException. The first class is singled out this way because, firstly, exceptions of this type are unchecked (unchecked), and, secondly, these exceptions include program execution errors. This usually occurs due to imperfections in the code. All other exceptions are usually the result of an unforeseen set of circumstances, such as an I/O error.

Exceptions are also divided into checked (checked) and unchecked (unchecked). The former must either be caught in the block try-catchor specified as throwables in the method signature (using the word throws ). Unverifiable ones do not require this, and the choice is left to the programmer. Checked include exceptions of type Throwable(as well as those inherited from it) and type Exception(and those inherited from it, except for exceptions of type RuntimeException). Unchecked include exceptions of type Error(and those inherited from it) and exceptions of type Runtime (and those inherited from it).

Nothing, the program will just close. Usually these are critical errors that are not always the fault of the programmer (for example, hard disk failure or operating system failure). True, among them there are two errors that can be the result of code imperfections - this StackOverflowErrorand OutOfMemoryError. The first type of error occurs when the call stack overflows - that is, when too many methods are called and the call stack becomes too large (a typical example is infinite recursion or recursion with a large number of iterations). The second error - OutOfMemoryError- occurs when the memory allocated for objects overflows, that is, when too many heavy objects are created, and they are all kept in memory (or when the garbage collector does not have time to destroy them).

In Java 7, the exception plan introduced three new "things":

• Multicatching. This is when catchseveral exceptions are handled at once in one -block:

  try {
   } catch (Exception1|Exception2|Exception3| ... | ExceptionN ex) {}

  In this case, the parameter exwill implicitly have the modifier final. Also, the bytecode generated by compiling such code (with a single catch-block) will be shorter than the bytecode generated by compiling code with multiple catch-blocks.

• Try-with-resources. tryThis construction allows you to indicate the opened resources after the word in brackets, which will close themselves after the end of the construction try () {} catch{}. Any object that implements the interface can be used as a resource in this construction AutoCloseable.

  During the closing of resources, an exception can also be thrown. Added try-with-resourcesthe ability to store "suppressed" exceptions, and an exception thrown by a try block takes precedence over exceptions thrown during closing. You can get the latter by calling a method getSuppressed()on the exception thrown by trythe -block.

• Rethrowing. Throwing exceptions with improved type matching.

  The Java SE 7 compiler parses thrown exceptions more carefully. Consider the following example:

  static class FirstException extends Exception { }
  static class SecondException extends Exception { }
  
  public void rethrowException(String exceptionName) throws Exception {
      try {
          if ("First".equals(exceptionName)) {
              throw new FirstException();
          } else {
              throw new SecondException();
          }
      } catch (Exception ex) {
          throw e;
      }
  }

  In the example try-block can throw either FirstException, or SecondException. Prior to Java SE 7, it is not possible to specify these exceptions in a method declaration because catchthe -block rethrows an exception exwhose type is Exception.

  In Java SE 7, you can specify that a method rethrowExceptiononly throws FirstExceptionand SecondException. The compiler will determine that an Exceptionex exception could only occur in trya -block in which FirstExceptionor could be thrown SecondException. Even if the parameter type catchis Exception, the compiler will determine that it is an instance of either FirstException, or SecondException:

  public void rethrowException(String exceptionName) throws FirstException, SecondException {
       try {
           // ...
       } catch (Exception e) {
           throw e;
       }
   }

  If FirstExceptionand SecondExceptionare not descendants of Exception, then you must also specify Exceptionin the method declaration.

• Annotations are used to place some additional, service information (metadata) related to a class, field, method or variable next to it. To specify an annotation, above the heading of a class or method, or it is necessary to declare a field or variable, write the name of the annotation (annotation class) after @, for example:

  ...
  @Override
  public void doSomeThing() {
  }
  ...

  In addition, the annotation can have properties, they are indicated in brackets separated by commas in the form of "key = value" pairs, where the key is the name of the property, and the value is actually the value that this property should take. It looks like this:

  @CatInfo(manager=Catmanager.class, unique=true)
  class Cat {}

  If specified indicates a value for only one property, then the property name and equal sign can be omitted: @SuppressWarnings("unchecked").

  It is also possible to leave out the parentheses at all if no values ​​are assigned to any properties.

  To create your own annotation, you need to specify the access modifier, then after the space the keyword " @interface " and then again after the space the name of the annotation (take it to start with a capital letter). Next comes the body of the annotation in curly braces. Inside the body, properties are specified in the form of method declarations (as in interfaces). You can also specify default values ​​for properties (they will accept them if, when specifying the annotation in the right place, this property will not be assigned some value). All together it looks like this:

  @interface CatManager
  {
   Class manager();
   boolean unique();
   String name() default "Unknown Cat";
  }

  Annotations perform the following functions:

  • give the necessary information to the compiler;
  • give information to various tools to generate other code, configurations, etc.;
  • can be used while the code is running;
  • increase the readability of the code and its understanding by programmers.
  There are currently three annotations used by the compiler: @Deprecated, @Overrideand @SuppressWarnings. The first annotation marks obsolete methods and classes that are not recommended for use (the compiler displays a warning about them). The second annotation is placed over the overridden methods of the descendant class (this allows you to control the relationship between the original method and the overridden one). The third annotation allows you to suppress (not display) some of the exceptional warnings that the compiler usually displays in connection with this method or class (for example, that it is already deprecated and deprecated).