Category: Other

How to plan a sprint

Posted on by kostyn.gricuk

Both developers and board members of companies like agile methodology thanks to the easy implementation of new features in a project and update of the product backlog. Agile helps teams to create a competitive and modern final product, adapting it to all the challenges of the modern market. When a new code is deployed every week or every two weeks, the software development process becomes more flexible and competitive.

Agile team collaborating during sprint planning

The process of estimating user stories from the product backlog or sprint backlog is one of the most contradictory issues in Agile practices. The product owner would certainly prefer backlog estimation in hours since he holds the answer to shareholders who prefer to deal with accurate and clear timeframes of a product or a particular stage.

Scrum helps us to use an iterative approach to software development, which allows adjusting the estimation time after each sprint and changing the order of tasks in the backlog to ensure product release within the deadline.

Break it down: decomposing user stories

After the Scrum team has received the user stories, they are often broken down into smaller tasks. If even after decomposition, the team finds a task too difficult to estimate or too large, another round of decomposition may be needed until the task becomes estimable. Each user story from the product backlog should be estimated prior to development.

Many Agile teams use the INVEST principle for decomposition of user stories. INVEST is an acronym that describes the characteristics of good user stories.

A user story should be:
Independent
Negotiable
Valuable
Estimable
Small
Testable

Sprint retrospective discussion

Independent means that the user story can be developed, tested and delivered even by itself.

Negotiable. A user story is not an explicit contract, but an area encompassing a variety of requirements that need to be discussed.

Valuable. Value is one of the most important elements of the INVEST principle. Each user story must deliver value to the user.

Estimable. A good user story should be estimable.

Small. User stories should be small because they need to be fitted comfortably within iterations.

Testable. In Agile, the entire code is testable, and therefore the story should be testable. If one cannot test a user story, it means that the story is too complicated.

If you’re interested in more, read Why Agile Is Not Only SCRUM

Estimating user stories: challenges

Each task needs to be estimated. The cornerstone of all the problems lies in the estimation methods. After all, the product owner and shareholders prefer estimates in hours. This helps them to better understand:

  • When the working prototype of the product will be ready.
  • When the new characteristics of the product will be made available to users.
  • When the new product will be ready for commercial release.

But developers estimating user stories may encounter problems when estimating in hours. For example, every developer works at his/her own speed, and estimates in hours may differ very much. After all, it is clear that a middle developer spends more time on a task than a senior developer. However, if a middle developer has performed such a task before, then, provided that the senior developer has not encountered such a task before, the middle developer will likely spend lesser time than his senior colleague.

Sprint backlog items on sticky notes

Whenever we talk about estimates, we refer to their accuracy. If an estimate is accurate, it very much helps in further development. But when the estimate is not accurate, the entire development process may be disrupted, which can then lead to failure to meet deadlines.

If your team practices Scrum, you must have seen from your own experience that estimates may differ significantly among different people. In estimation, people tend to rely on their own experience or colleagues’ experience. People also often try to either build a safety net by setting a deadline a little more than needed to make sure that the task is 100% delivered on time or, the other way round, name a shorter deadline in order to draw attention (e.g., the manager’s attention).

Scrum teams that are newly created or that have more than one new member may also experience difficulties during estimation. Sometimes, newcomers try so hard to make a good impression before all their team members to the extent that they underestimate a task. This may subsequently lead to disruption in sprint deadlines.

Till now, even Scrum evangelists still have no consensus on how best to estimate user stories – in story points or in hours. Some Scrum Alliance authors even claim that hours and story points reflect and measure different aspects of the development process. There is also the opinion that new members of a Scrum team may initially have difficulty with estimating user stories in story points since their very conception can be unclear. On the other hand, if the Scrum team is already well established, estimates in story points will help create a well-thought-out sprint backlog and deliver all the tasks in it within deadlines.

Most importantly, the Scrum master and product owner should have an excellent knowledge about the capabilities of their team members to convert estimates into story points to hours so as to present a report to the board of directors.

Determining the worth of a story point

The original purpose of any estimate is to determine the unit of measure, which will subsequently be used to compare all other user stories. While an hour is a more or less a clear unit, story points may seem complicated especially for those who have not handled them before.

The most common approach to determining the essence of story points is that all the Scrum team members agree on which task will be estimated in 1 story point (or 0 story points). This should be a one-piece small task that can no longer be decomposed into smaller tasks. Of course, it may take developers in the team different amounts of time to perform such task, but in general, the task should be recognized as the smallest task in the product backlog.

Also, some teams use 0 story points to determine a task that takes negligible time (for example, fixing a small bug in the layout). In this case, the Scrum team decides on how many microscopic tasks will make up 1 story point.

The next step will be to determine the scale for more complex tasks that take more time. Any number from 1 to 10, or a logarithmic scale or the Fibonacci sequence can be used. The last two are even better because values in them grow exponentially, thereby stimulating the division of large tasks or user stories into smaller ones. Also, for any scale, you need to determine which of its value would be the boundary – a task with such a number of story points must be divided into smaller tasks (it’s typically 16 story points for a logarithmic scale and 13 or 20 story points for the Fibonacci sequence).

The Fibonacci sequence is named after the scientist and mathematician who studied its laws. It is a sequence of numbers 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…, where every number after the first two is the sum of the two preceding ones. The Fibonacci sequence is used to estimate user stories because it demonstrates exponential growth and all the numbers in this sequence differ relatively from each other. Thus, Fibonacci sequence is easy to use for comparison and difficult for counting.

Team planning sprint on whiteboard

With regards to the principles of estimating tasks in story points, Scrum teams usually take into account the following factors:

– Effort – how many hours are required to complete the task;

– Uncertainty – how clear, how will the task be performed, does any member of the Scrum team have a similar experience before;

– Complexity – whether this task is connected with other tasks in a user story if the task needs some kind of comprehensive solution.

Story points are used to measure the sprint scope by finding the average statistical sum of the estimated story points. For example, a user story that has been estimated at 3 story points is not equal to a simple sum of user stories that were estimated at 2 story points and 1 story point.

Steve Bockman’s estimation method

This is one of the easiest methods of estimating user stories, requirements, or tasks. You only need to create cards with a brief description of all the user stories (or tasks, if the user stories are too extensive) from the product backlog and sprint backlog. The description should be sufficient to ensure that each Scrum team member could understand exactly what kind of a user story is involved.

Then all the cards are collected in a pile. Each team member picks the top card off the pile and places it somewhere on the playing surface:

– If a card is placed on the left of a card that has already been estimated, it means that the user story on this card is relatively less complex than the user story on the already estimated card;

– If a card is placed on the right of a card that has already been estimated, it means that the user story on this card is relatively more complex than the user story on the already estimated card;

– If a card is placed underneath a card that has already been estimated, it means that the user story on this card is of equal complexity to the user story on the already estimated card.

Each member of the Scrum team then explains why he/she placed his/her card exactly on that spot. A member can also skip a move. If all the cards from the pile have been laid out, they can be moved, explaining why this is necessary.

When all have skipped their turn, the game ends.

At the end of the game, the cards can be estimated from the smallest to the highest. Estimates are then assigned in story points.

The main aim of this game is to explain the course of one’s thoughts to other team members and hear the views of others.

Planning poker

The Planning poker (also called Scrum poker) represents a more advanced version of estimating tasks or user stories.

Before you start playing, it is recommended to first decide on a set of values that will be used. Scrum teams usually use the Fibonacci sequence because it allows to clearly see the moment when a user story or task is too large and needs to be decomposed. After agreeing on a set of values, numbers from this set are printed out in the form of a card for each member of the Scrum team. Typically, the largest number in the set of cards is 13 or 20. This number serves as a signal that the user story cannot be estimated in the form in which it is, but needs to be decomposed.

Agile sprint planning session in progress

During Planning poker session, each member receives a set of cards. The product owner describes the user story and answers questions from other members of the team. Each member estimates this user story, chooses the appropriate card, and places it face down. At the command of the product owner, all the members show their cards simultaneously. If the values in the cards differ significantly, then the team discusses the user story in more detail and then conducts another round of estimation.

Planning poker is a simple and easy way to obtain estimates of user stories from the sprint backlog or product backlog.

Fruit poker

This is a new upgraded version of planning poker. This game has exactly the same rules as in planning poker. The only difference is that fruits are used instead of numbers. Cherry is used as the smallest task, strawberries as a small task, kiwifruit as a medium task, orange as an above-average task, grapefruit as a big task and watermelon as a large and complex task that requires decomposition. Some Scrum teams also use a card called a “fruit salad” to refer to tasks that are too complex to estimate and require decomposition.

Sprint review meeting with team

Why do we need Fruit poker?

  1. This simple technique helps a Scrum team to fully concentrate on task comparison, rather than common estimation by counting.
  2. This technique is very helpful to newly-created Scrum teams.
  3. Helps those teams composed of new members who have never worked with Scrum before.

Since planning poker involves the use of numeric values, developers with no Scrum experience may encounter problems when estimating user stories. For example, they may attempt to somehow calculate the “correct” estimate based on the values of the cards of other members of the team or based on previous estimates.

Fruit poker, on the other hand, offers a quick and informal way of comparing tasks. Yes, the developer team may within themselves agree that a “Cherry” task requires from one to three hours approximately and a “Grapefruit” task requires from forty to one hundred hours of work, and thus establish some kind of value for comparisons. And that’s it.

Conclusions

Clear and accurate estimates of time and effort in most cases are not the main purpose of implementing Scrum methodology. They are often a pleasant by-product of such implementation. When estimation of user stories is simple and engaging, the Scrum team has all the chances of obtaining accurate estimates, which the product owner can then translate into hours and working days.

Scrum team members usually determine by themselves how they will estimate user stories. Since engagement is one of the core values of Scrum, the team in most cases will work out the most convenient way of estimating user tasks in practice – whether in story points or in hours, whether they will be obtained via Planning poker or Fruit poker. There is no perfect or universally recommended method of estimating user stories. Each Scrum team may find a method that suits it most.

Why Agile Is Not Only SCRUM

Posted on by kostyn.gricuk

Create Your Own Flexible Agile Hybrid

“We work under Agile principles”: this is a common phrase to hear from different IT-companies. However, do they really follow the main ideas of this popular technique and enjoy the flexibility of processes? Let us find out, why SCRUM and Agile are not the same things, and why Agile Hybrid approach is becoming even more widespread.

Why Agile Is Not Only SCRUM

Agile is the philosophy of building up a development approach that is flexible and responsive to change. So it is defined in the Agile Manifesto (https://agilemanifesto.org/). However, a closer look at the working process of a company using Agile reveals that they have just implemented one of the best-selling Agile-frameworks – without trying to enhance company’s responsiveness to the dynamic business environment.

Solid SCRUM for large iterative projects

SCRUM is one of the well-known frameworks or Agile approaches. This methodology is formalized strictly enough by one of its creators, Jeff Sutherland: the details of the formalization are described in The Scrum Guide (http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf). Specific terminology aside, SCRUM is an iterative-incremental software development model with a defined iteration length (1, 2 and more weeks).

Pros:Cons:
  • Process cyclicity
  • High level of interchangeability
  • Long delivery period
Why Agile Is Not Only SCRUM

From experience: SCRUM works great for products that are still not in the real use. When you need a highly intensive functionality delivery, introducing SCRUM does not make the process more flexible. Your team may be content with the steady workflow and process formalization, but a slow progress in implementing the necessary functionality compels you to use other methods.

Kanban for small and urgent tasks

This is another well-liked Agile framework, based on handling one high-priority task at a time.

Pros:Cons:
  • High work speed
  • Continuous delivery
  • No steady workflow
  • Too difficult to implement within large projects
Why Agile Is Not Only SCRUM

Besides, Kanban imposes higher requirements on automated testing and continuous integration tools, also making it more difficult to use.

Agile Hybrid – perfect methodology for a specific project

Under close scrutiny, the disadvantages of one of the two above-mentioned techniques (delivering functionality in releases and continuous integration) are compensated by the advantages of the other.

The pros and cons of each method gave way for Agile Hybrids, combining either different Agile methodologies or components of a methodology in one process. The main idea of this approach is to design the process according to the needs of a specific project. What’s important, Agile Hybrid is not imposing. It does not try to squeeze the team into limits, allowing for experiments and flexibility.

Why Agile Is Not Only SCRUM

SCRUM with Kanban elements is one of such hybrid frameworks that provides for delivering big user stories in releases. Meanwhile, stubbed functionality is being delivered continuously according to the pre-set product’s priorities. Such methodology is more demanding to a team, it’s internal communications and management tools. However, the result speaks for itself: the development process actually responds to change and the team remains highly productive.

An example for creating Agile Hybrid

Consider a team of qualified professionals, including programmers, project managers, operations engineers and quality engineers. They work remotely from each other. The team is about to support several taken over projects remaining under development and at the same time to launch new projects of different scope from scratch.

Due to the lack of direct contact within the team, the different work speed and technical issues classical SCRUM can give many problems in this situation. Indeed, supporting old projects demands immediate implementation, while developing new ones does not mean continuous integration.

In this case, hybrid Agile is the best choice for the team:

  • give up sprints and go for short releases: this will allow for equal work speed on different projects;
  • split the whole team into two equally functional sub-teams to organize efficient communications;
  • abandon the “Scrum of Scrums” practice: the whole cross-team coordination can be carried out by project managers;
  • implement and use the continuous integration technique actively, with operations engineers being made responsible for its management

This working method is given only as an example. In real life, you need to analyze team skills: mastery of CI-tools by operations engineers, test automation skills of quality engineers etc.

Create your own Agile Hybrids

The values promoted in Agile Manifesto are based on team’s characteristics, the skills of the participants and their specific tasks. Agile is focused on creating a participant-oriented process. Using a specific framework, be it SCRUM or Kanban, does not necessarily bring success. No matter how popular a working method is, bear in mind flexibility, convenience and efficiency.

Do not hesitate to make your own Agile hybrids, introducing the best-proven practices to your work.

Dangerous Dependence on One Supplier

Posted on by kostyn.gricuk

“One” is the worst number for doing business – we all heard that a lot of times. Nevertheless, again and again, we see companies fall into the same trap while working with only 1 customer, 1 employee, 1 product, 1 supplier… It is always just a matter of time before one leg you stand on lets you down. For stability, you should always have more than one leg.

Dangerous Dependence on One Supplier

We have been working in the field of information technology for a long time and quite often meet a situation when firms need to take urgent measures because their ITO supplier quit on them at the most inopportune moment. Clients suffer from poor quality of a product, there are even dismissals in management of customer companies. What’s going down? Experience shows that such trouble is almost inevitable to happen to those who deal only with one supplier.

It should be noted that the search of a supplier of IT services, due to a number of reasons, is a tedious and time-consuming task. So inexperienced managers stop torturous searches and focus on other work as soon as they find the first suitable candidate. This is their strategic mistake. After all, diversification is extremely important to ensure stability.

Dangerous Dependence on One Supplier

If you have only one supplier, you become inevitably dependent on him. And this gives him an opportunity to raise prices and impose such conditions that may be not only unprofitable for you, but even onerous.

The situation can change

Usually a not very conscientious supplier forces a company to take decisive steps in finding a replacement. But the search for alternatives should be conducted even in case your supplier works perfectly. Unexpected troubles beset everyone, and your ideal supplier at any moment can stop working due to completely objective reasons. And this will immediately result in very painful problems for your company.

A good example of such a situation is a case with Indian service provider Satyam, which was admitted to the falsifying company accounts in 2009. All clients of Satyam who relied exclusively on the services of the provider suffered substantial losses.

We should not forget that any supplier can encounter difficulties with its staff and with conflicts in the management team. And between the jigs and the reels someone of the key top managers may suddenly drop everything and move to Tibet to experience Buddha’s legacy and to open the chakras. In this case it is hard to predict what will happen to motivation and general team support dedicated to help you.

Dangerous Dependence on One Supplier

After all it could be better

Even if you believe that you’re okay with one supplier, it means nothing. Even if you think that Honda Civic is a great car, it does not mean that you will not change your mind after driving a Mercedes E class for about three months. In a similar fashion the reason why companies often believe that they have a good outsourcing partner, is because they haven’t tried someone who provides a service or an expertise that is head and shoulders above the one they have.

Dangerous Dependence on One Supplier

Of course, you may find that your new ITO supplier is the same, or even worse than the one that you are working with, but that doesn’t mean you have to stop looking for some service supplier that would provide better quality, speed or price.

German IT Outsourcing Intelligence Report 2012 researched outsourcing activities of 764 German companies. When asked if they multisourced, 53.8% of the respondents answered they outsourced to more than 1 vendor. You may see the statistics in the chart below.

Dangerous Dependence on One Supplier

An alternative provides a positional advantage and the power

Having multiple suppliers gives you not only stability, but also provides positional advantage and strength. This is the most important postulate, which opens great perspectives for freedom of choice. When you have an alternative, you do not need to convince your only supplier that the quality of his work is not up to standards. You do not depend on the capacity of his team scaling. You don’t need to be some tough negotiator when you set the terms of the contract, the price, etc. You simply do have the freedom of choice.

So, alternatives are one of the main components that underpin a thriving business. Dear managers, keep this in mind and do not neglect this simple and important rule.

How Not To Let Subcontractors Screw Up Your Project

Posted on by kostyn.gricuk

“Mirror, mirror on the wall. How my project’s going on?”
Anna Vasilevskaya

Would you be calm and cool-hearted if you’d need to give your baby to completely unknown people for a couple of months? I don’t think so. You definitely would like to see your baby every day, know that it is healthy and talk to the hosts to know how your baby behaves. Similar thing with forwarding your project to a subcontracting company. Are the works properly done? Are they going to meet the deadlines? Don’t they hide anything from me? Those questions would appear in the mind of a new customer during the entire project.

Subcontractor may play a role of an experienced “adult” in IT for a customer who is new in the nearshoring business to ensure his work is in safe hands. In this article I’ll try to show you an approach that will help you to be independent from your and your subcontractor’s experience level. The only way to do that is to make the development process for the customer as transparent as possible. In this case provided information represents a base for a successfully managed and transparent project. How is it better to do that? For his own benefits a customer should always try to take care about the information to be SOLID, COMPLETE and WELL-TIMED.

If FixedPrice model is chosen – no problem, all the risks are on the side of a supplier i.e. subcontractor. But working on Time&Material basis implies that subcontractor makes available for the customer to observe and control the project being carried out. If a customer has no idea about the current status, if he/she doesn’t trust enough to the subcontractor, he/she feels the need to double check everything and that makes him distracted from his/her direct tasks.

So, when you come to an agreement about the information provided by the subcontractor, you have to consider it through the three main perspectives.

SOLID. It is one of the most important goals for a subcontractor – making customer sure you give him precise and true information. Speaking simply – that you don’t tell lies. If provided information is wrong, the customer is just misled. This easily can contribute to wrong interpretations and false decisions. To prevent those situations the customer definitely needs to crosscheck the information provided to him. Definitely not everything has to be checked all the time, it is too time and efforts consuming. It has to be found an efficient scheme to check the information from time to time and in various spots. In this way customer can find aсcidental, but sometimes even intentional misstatements by subcontractor. By no means you should try to stop him doing that. Again this is completely up to the customer how often and how firmly this will happen.

COMPLETE. Basically customer has to be sure that the subcontractor doesn’t hide anything unpleasant or vice versa anything important. Information hiding can be vital when any bottle necks appear. It is more efficient to inform customer on short notice and find solutions together than hide the details and then surprise him with a bunch of problems. Customer also has to decided how deep into details he would like to drop. Usually it depends on the subcontract level. If you see that subcontractor is quite weak, it is better to require more details: what was done? when? who did it? why? could we have done it in other way? The more experienced the subcontractor is, the less information you can demand from him. Depending on that you can choose among a couple of convenient tools, which allow doing that quite easy and productive:

  • Surface level. Weekly Status Report (WSR). It is prepared every week (surprise-surprise!) by a project manager and includes all the important points of works done during previous week, planned activities, new agreements, open questions and project milestones. WSR can be customized to each customer’s needs. By the way it also helps PM to keep all the significant information in one place.
  • A deeper level. Time and task tracking in customer’s systems. God bless the person who invented them! Jira, Redmine, Trello, Breeze and so on. Reporting into customer’s systems gives him the possibility to see how much time was spent on what tasks. This also gives the opportunity to harness subcontractor’s work attaching priorities.
  • The deepest level. Daily online meetings. An interactive addition to WSRs. They can be held via Skype, TeamViewer, Hangouts, Webex etc. They help to maintain direct two-way communication with developers and managers. Developers give an idea about what they’ve done, what they are planning to do, ask questions. Customer gets the latest information about how the project is going.

WELL-TIMED. In other words all solid and complete information has to be provided to customer in proper time. The earlier the problem is detected, the easier it can be solved. To react accurately and solve possible problems the most suitable way, perhaps together with the customer, it is needed to adjust some alerting mechanism, which could use above mentioned tools (WSR, meetings) to present the information. This feature is connected closely to the TRUTH feature, they complement each other. This is perhaps the most flexible feature, as the customer is free to choose how often he’d like to get the reports.

Based on the above I can mark out two general conclusions.

  1. Typically the customer has to spend more efforts on controlling information to be solid and complete as well as frequent double checking, if subcontractor isn’t experienced enough. The more experience, the less efforts for controling him.
  2. Both customer and subcontractor should aim to bring the balance among solid, complete and well-timed to the most suitable corellation for them. So customer needs to define how much effort each feature must take. If he feels that information is solid and comes in time, but it isn’t complete enough, he needs to discuss with subcontractor how to improve it. Perhaps WSRs are not accurate or meetings should be held more often.

Basically try to follow the Pareto principle – roughly 80% of the effects come from 20% of the causes.

In our turn, we’re curious, how do you manage your work with subcontractors? What kind of experience do you have: did you raise a bump or everything was on wheels? Or perhaps you have your own ideal recipe how to “prepare & cook” subcontracting workflow?

Automated downfall check for the code. Quick SQL-injections search

Posted on by kostyn.gricuk
SQL-injections (http://en.wikipedia.org/wiki/SQL_injection) represent a wonderful way to get external access to your database. This kind of injections can be left in the code by developers both because of lack of experience and on purpose. Is it possible to find them quickly and be sure your product is safe? Our developer Alexander shares his experience of automated search for such injections.

Once I had a task to develop a plugin prototype for IntelliJ IDEA within a short time. The plugin purpose was to analyze the code to search for SQL-injections according to a certain rule described in the given XML file.

To start plugin development for IDEA you just need to download the community version and create there a project for plugin development.

As a next step I had to realize the object representation of the rule described in XML. The main point of the rule is a listing of classes and their methods, their calling is SQL-injection. Nothing to explain here, everything is simple and has nothing to deal with specifics of plugin development.

After I had realized the object representation of the rule, I started exploring OpenAPI IDEA SDK with a view to code analysis possibilities. First of all I visited their documentation site: https://confluence.jetbrains.com/display/IDEADEV/PluginDevelopment. If I tell you the given information there was enough, I’ll probably tell you a lie…

It was clear that for code analysis I have to work with psi-elements and I made some investigations in this direction. I reviewed the interface of psi-element and its other descendants and it showed that for faster orientation it’s better to output all the structure from a Java file into the console and see what happens next. I call it exploratory attack. We need a UI action that can be called in the chosen project file in IDE. While activating the action we get AnActionEvent and then we take the element following way:

PsiElement element = event.getData(LangDataKeys.PSI_ELEMENT);

in case we called the action on the chosen element in the project tree, or:

PsiElement element = event.getData(LangDataKeys.PSI_FILE);

in case we called the action from the editor of the open file.

Back to psi-elements. Psi-element has a parent psi-element and subsidiary psi-elements.  So we can get deeper recursively and output all the elements with indentations into the console. In this way I found an important.

PsiMethodCallExpression element that includes necessary information, meaning which exactly method and where do we call it from. A bit more patience and I found a way to extract this information:

PsiReferenceExpression methodExpression = expression.getMethodExpression();
PsiReference reference = methodExpression.getReference();
PsiElement result = reference.resolve();
PsiClass methodClass = (PsiClass) result.getContext();
String methodClassName = methodClass.getQualifiedName();
PsiIdentifier methodIndentifier = methodExpression.getLastChild();
String methodName = methodIndentifier.getText();

In this way we get the whole class name this method belongs to and the name of called method. That’s enough to identify whether it is a potential SQL-injection. Besides we have the psi-element of method calling, so we know what place in the code it is.

The next task – marker saving.

I created a project level component and put the marker container in it to save markers. To make the component container persistable, the component has to realize the interface ProjectComponentState<Container type>

And the fields in the container have to be marked with relevant annotations, e.g.

@com.intellij.util.xmlb.annotations.AbstractCollection
code

Displaying of markers and annotations was a sweaty piece of work. Everything was great, the way for realization of markers and annotations is easy, because you only have to realize your relevant providers and register them in the plugin. Some difficulties appeared, when I had to refresh them in the open editor. I couldn’t find the information about that on open access so quickly, so I had to use exploratory attack again. Debugging marker display mechanism I found out that it is possible to refresh SlowLineMarkersPass and it will refresh markers for the specified document. Anyway the issue with annotations highlighting the code remained. The same way I found the GeneralHighlightingPass. Class that dealt with annotations etc refreshing, but there was one hitch: to create and launch it you have to feed it with a plenty of different odd arguments and it already took the wind out of sails. Debugging didn’t help, so I had to ask for help my good old friend Google. After several cups of coffee I found an article where it was suggested to use this way

DaemonCodeAnalyzer codeAnalyzer = DaemonCodeAnalyzer.getInstance(project);
codeAnalyzer.restart();

Bingo! This approach solved my problem both with markers and with annotations. Warning! If you install developed plugin into the IDE where it is developed and then you launch debugging of the same plugin, IDE sees the code exactly from the installed plugin. As a result IDE doesn’t pick up code changes and debug falls off. Take this into account and do not install your plugin into the operational IDE, before you finish development process. Eventually I got this plugin

code_programm
  1. First of all this task doesn’t take much time. It took no more that 5 days for the whole plugin.
  2. We got more flexible while completing our tasks for code analysis. It isn’t always fully accessible in ready frameworks for static code analysis.
  3. The opportunity to use PSI elements instead of AST simplified our work.

As there is not so much information on the Internet on this topic, I hope this article might be helpful for other developers.

FP & TM Agreements: The Perks & Pitfalls

Posted on by kostyn.gricuk
fixed-price-or-time-material-in-other-words-how-to-finalize-the-perfect-application
If you are planning to do remote software development, then you must have thought about which engagement model to use. We get asked this question a lot, and as you have heard before… the answer is, it depends. In this article we’d like to present you a detailed description of FP & TM Agreements, their perks & pitfalls:

1. Fixed-price (FP) Agreement

– is identified by the price for the determined workload, despite the actual cost of work performed.scope of work.

Such type of Agreement might cover financial benefits for a certain tasks achievement of the project. Fixed-price Agreement is divided into:

  1. FP Agreement with incentive fee (FPIF) – Fixed-price agreement where the Customer pays a specified bonus for the achievement of a particular criteria.
  2. FP Agreement with fixed price – I know, it sounds a little bit grotesque, but such type of Agreement deserves a fuller explanation: when the Customer choses FP Agreement, he bears in mind that according to such contract the work load shall be determined before work start & afterwards shall not be subjected to any changes.
  3. FP Agreement with a provision for possible price adjustment – quite comfortable in cases of terms stretch, during which any changes might occur.

2. Time & Materials (TM) Agreement

– is a mixed type of Agreement, according to which the Customer reimburse the Contractor all actual costs. The Customer pays for the time spent on the development by the hour rate.

From all existing diversity of agreements, TM & FP are the most popular ones. They both have their perks & pifalls. So let’s have a closer look at them:

  1. Risk Coverage:
    Fixed price Agreement covers risks that might arise during project performance. Risks might or might not occur, but the Customer shall always pay for them. The cost of risks is calculated from their probability to appear on the cost of their realization. For example, there’s one risk in performance of the project, with a cost of 50.000$. Its probability to occur is little – around 20%, but in case of its occurrence, the cost of the project will raise on 10.000$, i.e. the risk cost equals 2000$. Irrespective of the risk occurrence, the Customer pays for the project 52.000$. In case of TM agreement the Customer pays as much as the project performance will cost, i.e. without risk -50.000$ & in case of it occurrence– 60.000$.
  2. Project Scope Assignment:
    Since the Customer pays for the actual consumed time in case of TM Agreement, he can provide the content of the work gradually, as work progresses. Provided that, he is the person who takes responsibility for the final result.

When performing the project on the FP basis, the volume of performed works is provided and evaluated prior to the signing of the contract and afterwards can not be changed. Changes in the volume of works at FP Agreement leads to termination of the current contract, payment of performed works and to signing of a new contract for the new scope of work.

tm3

The peculiarities of TM Agreement

I’d like to draw your attention to the non-obvious feature of TM contract that might resulted in customer’s confusion.
Under TM agreement, the process of development is transparent: the customer sees the development process as it is, sees all the bugs appeared, defines the objectives and content of each version of the product.

If the customer doesn’t want to spend time on the elimination of bugs and focuses on adding functionality, the number of bugs increases from version to version. After a few months of such development, there’re so many bugs that the effectiveness of QA fails, so that the developers have to create new functionality basing on existing bugs functionality. The development of new functionalities goes slower and slower thus resulting the customer’s getting nervous and looking for the causes of problems. The reason for slow development – bugs. Who creates them? The developers. The cause and the offender are found.

On the customer’s opinion, the developers should present the code without bugs. I.e. the customer expects the quality of the developers’ work on TM project to be the same as on FP project. In this case, the customer ignores the fact that in FP project, the created code undergoes the quality control & the following fixing of all found bugs before presenting it to the customer.
On FP project all bugs without any exception are fixed & only after that the customer sees the result. The customer doesn’t point the bugs that a developer should fix. He even doesn’t know whether they be. The customer is granted with the final product of the required quality.

On TM project the customer sees the bugs & decides which of them should be fixed. As far as bug fixing doesn’t add value to the product, they have a tendency to pile up. When the number of bugs becomes critical, the development process stops & the project might be closed.
To avoid project crash, one should make sure that the customer understands that under TM project he sees the project, which includes the phases of creation, testing & fixing. Disregard of one of these phases, after all, would lead to the project failure.

Conclusion

So, which agreement should we choose: TM or FP? There’s no absolute answer. The closedness of the project from the moment of order placement till its final performance presupposes the dead certainty of the customer in the rectitude of his vision on the product.

Meanwhile, TM Agreement allows making the development process clear, effective & driven. And if the Customer notes the weak spots in the project, he can deviate from the ground-plan & do not waste time & money on performance of wrong approach.
However, some non-optimality of the product is allowed in contrast to the risk of missing the budget.
That’s why, while choosing between the types of agreements, one should keep in mind all the components – budget, time, final result.

Freelancers. A blessing or a curse? How to work with freelancers?

Posted on by kostyn.gricuk

We often face different opinions on freelancers in our work. Some people fear them like plague, others hire them and сomplete the orders successfully. From time to time we hire freelancers if we require some specific expertise or need to expand the development team. And we dare to say that a freelancer will save your money as well as your nervous system. If you know how to deal with them.

freelance

Freelancers are children

A freelancer does not understand you. Just face it. It is not because they are bad, but because people in general do not understand each other. We speak the same language, but mean different things.

You can tell a freelance designer to “Draw a pretty website”, but none of you understands what it means. If you let a freelancer go after these words, he will not manage to do anything.

You may tell a freelance programmer to “Implement a payment gateway” on your website, but you do not specify whether you need e-money, order statistics, e-mail confirmation and storing the payment data. It seems obvious to you. However, it is not obvious to your freelancer.

You say that your mixing tap is leaky, but you do not specify that you do not want to replace it.

Always act on the premise that your executor did not understand the task. It will save your time in the future.

Of course, the executor is responsible for clearly understanding the task. An experienced freelancer will not let you go until you explain the task in all its details. A good executor requires a million clarifications, makes up a vision of the solution and finally makes you accept it. If you are not irritated by your freelancer delving into every detail, you are dealing with the inexperienced one.

That is why you should not wait until his lack of experience turns into your problem. Correct the situation.

  • Define the problem that a freelancer should solve. You don’t need a website, you need to sell the goods; you don’t need an article, you need to create reputation; you don’t need wedding photos, you need great memories. Allocate some time to think about the problem instead of the solution. Why do you need a website?
  • Discuss the problem with the freelancer. Ask how he would solve it. Maybe the freelancer suggests a better solution. However, this trick has a pleasant side effect: a freelancer realizes that you respect him as an expert. This will help in your further relationship.
  • Discuss the solution. Ask the freelancer to explain to you all the stages verbally. Be meticulous: “What will the user see here? How is it designed? What is the next step?” If a freelancer does not present the solution in detail, you will fail. Make him think about all the details before you discuss the price. Any hushed up question is an abyss that your project will fall into. Find these questions and clarify them.
  • Describe the solution. Ask the freelancer to make up tasks for himself, considering all discussed questions. This may seem unnecessary, the executor will be grizzling and saying “Oh, why do we need to do this? It is already obvious…” Treat him carefully, as a kid but do not stop proving your point: understanding the task should appear on paper. If there is no understanding – there is no project.
  • Reread the vision and make sure that everything looks the way you want. If something is blurred or does not even partially meet the expectations, correct this with the freelancer.

Conclusion: Some people say that a client should not think about his task since it is a job of a freelancer to clarify everything. This is nonsense. A project is a partnership. Everyone should work hard. If a client sees that the executor does not understand the task, he should step in and put things in order. Taking comfort and thinking that “it is not your responsibility” is an irresponsible approach.

Monitor the term

Freelancer will definitely fail to meet the deadline. If a freelancer meets the deadline, he might have already started his own agency and hired a couple of managers. Both young and experienced freelancers are a perfect example of irresponsibleness. But it is not personal qualities that matter, it is the way they organize their work.

Freelancer faces 3-4 parallel orders at any given moment. As soon as he finishes one project, there goes another one. This is how he provides himself with minimal earnings. A freelancer cannot but take several parallel projects – this is how he makes a living.

Then there goes another freelancer principle – the most pressing tasks are the most urgent ones.
To start making your task today, a freelancer should know that tomorrow is the time of delivery and if he fails to make a delivery – he will feel pain, shame and hunger. That is why today he puts all the orders aside and devotes his time to yours. And tomorrow (or on Monday at most ) you will have a great result.

To get a good result in time, you should keep the freelancer in the state of frantic rush. To do this you need to:

  • Set milestones with the freelancer. Preferably every 2-3 days. Suggest him to do this himself. It is important since a freelancer should make a promise. When you impose the terms on him, he will not be bound by moral obligations.
  • Follow the milestones and express your dissatisfaction openly if the freelancer is running out of time. The freelancer should be ashamed that he did not keep his promise.
  • Remind about the milestones. Accept the fact that freelancer has no time to control the terms – he has at least three clients like you. Act as a manager and calmly but insistently remind him that he is having a milestone in 2 days.
  • If the project is long, bind payments and work stages. But remember that in most cases a freelancer is not afraid of losing money: he thinks that he could have worked with 10 simple clients instead of the hard one. Do not mention money in your discussion.

Conclusion: accept the fact that a freelancer has no time to monitor the terms.

Stay connected

Treat your freelancer as a gifted child. He does his job perfectly, but he lacks discipline. Take it for granted.

This implies that:

If the freelancer does not call you during the day, he did nothing on your project today. If it’s bad for you – call him yourself.

If the freelancer says that “everything is almost done and he needs some time to stabilize the algorithm” – he probably hasn’t even started working. He’d better told it in the beginning instead of the day before the deadline.

Keep a constant contact with the freelancer, do not let him go. Project milestones should keep him fit, he should feel your constant presence.

Do not expect the freelancer to tell you that he is running out of time because of bad planning and ask to make up a new plan. If he did so – you managed to found a unique example and should always work with him. This is a grown-up, serious and smart freelancer that can hardly be even called a freelancer. This is a partner, professional and a very clever person. Such specialists are hard to find.

In most cases a freelancer will tell you about floods in his apartment, hospital visits, internet connection issues and funeral banquets. It’s a shame to put pressure on the worker when such things happen in his life, but you know that nothing has happened, don’t you?

Conclusion: If a freelancer uses “reasonable excuses”, he is definitely in deep crisis. Most likely he is busy working on other projects. Try to understand the situation and act as a grown-up – make up a new plan together and let the freelancer suggest new terms.

Try to ask him:

– Matt, what if you don’t manage to finish in time? What will we do?

Let him suggest his own punishment.

Be wiser

Freelancer is a gifted child. If he were more grown-up and concentrated, he would have already started his own business. Do not expect adult behavior from him, as well as admitting his fault or making a timely warning. He is busy surviving.

Lies, procrastination, turned off phone, elusion, excessive promises, wish to appear better than he really is can be considered as the essential elements of freelancer’s behavior and should not be taken seriously.

Just as every child, a freelancer can be influenced upon with the help of yelling and rudeness, pressure and threatening not to pay him. However, these measures won’t be effective for too long – it is easier for a freelancer to lay low than to deal with a tyrant. Be wiser – try to overwhelm him with your insistence, respect and attention. Set an example. Be respectable and the freelancer will not want to deceive you.

Drawing a final conclusion

Stick to the conviction that freelancer is a child in his profession. It is difficult for him not to let you down. Become a wise mentor and you will see how productive a freelancer can be.

Who could be saved from the Titanic of IT business?

Posted on by kostyn.gricuk

Delegating non-core functions to professionals remains the most efficient way of managing a company. Chief Executive Officer speaks to Alexej Spas, CEO of *instinctools, about finding the right partner in the outsourcing market.

Portrait of Alexey Spas, instinctools CEO

CEO and Owner at *instinctools

The media likes to talk about successful IT projects, start-ups and new technology IPOs, but are the majority of projects actually successful?

Alexej Spas: According to polls in the IT industry, only 10% of companies are getting return on investment with most of their products and actually reaching financial goals. Every day, a huge number of innovations are happening in this area, but the economic success of these is questionable. This reminds me of Titanic: it looks promising, but in the depths we discover some deadly holes

Why do you think this is?

Alexej Spas: The key here is specialization. Product launch, development and promotion are a set of complex tasks. Successful execution requires expertise in many areas – from marketing through to the product development and customer support. Not many companies have all these competencies at a sufficient level. As a result of trying to do everything on their own, companies end up drowning in the details and missing the targets. The non-core functions can, and should, be delegated to professionals who perform this function more efficiently.

Do you think it’s enough just to give non-core functions to external contractors and believe everything will be fine?

Alexej Spas: Delegating does not mean excluding yourself. My experience with companies of all sizes shows that the product or project becomes successful only with the active participation of specialists from the subject matter domain on the customer side, as well as the presence of open partnerships between the customer and supplier.

Are there any other reasons that contribute towards these failures?

Alexej Spas: Yes. One of them is slow time to market. The market for IT products is usually very competitive. We see how companies are trying hard to be the first to market with their products. But, for this, they often do not have enough of their own resources. Domestic resources are either missing or expensive. And this leads to losing market position.
So, companies are looking for resources elsewhere; the latest outsourcing reports show that 50% of companies developing their IT solutions in-house reported plans to start outsourcing their IT/development in 2013–14.

Your company has a remarkably low project failure rate. How is this possible?

Alexej Spas: When working with our customers on outsourcing projects, we follow several important rules, and can recommend those for others:

  • Focus on what we do best. We have invested more than 14 years in improving our production processes, focusing on optimization, and now we can offer this approach to our customers.
  • Look for a partner that is two to three time zones away. You’ll save a lot of valuable time.
  • Pay attention to good reputation and references of your partner.
  • Search for solutions together with your partner. Explain the context of the problem. Include them as much as possible in decision making process.
  • Find a partner from your league, as well as one that is similar in size and possibilities.
Scale balancing an ocean liner and a modern yacht

Why is choosing a partner of similar size important?

Alexej Spas: Part of our strategy is to find clients of a similar size. In this way, we can better understand each other’s problems and easily find a common language. Overall, the results of the UK Development Survey 2012 suggest that ITO is yet to be discovered by more small to mid-sized UK organizations in the near future.

But, your list of clients includes such giants as Daimler, Fujitsu and SAP. How does this fit into your recommendation of selecting a partner of similar size?

Alexej Spas: When dealing with these companies, we work with specific departments within them. They are like a smaller company inside of the larger one. So, we solve tasks within these specific departments where our rule around size applies perfectly.

How else could you advise our readers with regard to finding outsourcing partners and avoiding getting on the Titanic?

Alexej Spas: It sounds trivial, but I want to emphasize getting offers from multiple vendors – many companies neglect this. Compare them in terms of price, depth of requirement analysis, quality and level of communication. Professional ITO companies offer the possibility of a preliminary or detailed estimation of your project, as well as running pilot projects. For example, on our company website, you can order an estimation of your project directly through an online form. By comparing estimates from different vendors, you can identify the risky parts of your project and focus on these from the start of the project.

Companies need to concentrate on their strengths, and find reliable partners that can help them get to where they need to go. In this way, you can easily benchmark your existing ITO partner. And, of course, we will be happy to be your winning ship, if you chose to step on it.

The article is originally published on zmags.com.

Anna Vasilevskaya
AI modified real photo
Anna Vasilevskaya
Account Executive

Get in touch

Drop us a line about your project at
[email protected] or via the contact
form below, and we will contact you soon.