I am leading integration projects recently, so decided to look for best practices of what must be done/clarified to make integration successfull.
Accidentally i was given a book to read - Software Requirement Patterns (Best Practices) by Stephen Withall
In Chapter 5 there is an overview of what is important for integration projects.
All integrations have following main issues:
- systems cooperation might be time-consuming and unpredictable undertaking
- interfaces for other systems might be very complex
- if external inteface is used, it might not do exactly what we want or might work as we expected
- if we are developing own interface, we become dependent on other system to implement it properly
- and of course testing becomes more complicated, since not all problems are identified so easily (communication, technical and other issues)
- all upper issues become even more difficult to manage if both sides are working on integration at the same time
To manage integration more successfully we should define requirements for inter-system interface this way.
Interface requirement
1. Interface name - meaningfull name
2. Interface ID - unique number within the scope of the system
3. The system at each end - it might be that the same interfacw might appear more than once, so it needs to be explained
4. Interface purpose - self describing :)
5. Interface owner - describes which organisation is responsible for a certain interface
6. Technology to be used for interface
Extra interface requirements
Individual types of interaction; Throughput; Scalability; Extendability; Availability; Traffic verification and recording; Upgrading; Security; Documentation
Considerations for Testing
1. Explicit interaction requirements
2. Implicit interactions, which help to satisfy goals stated indirectly (f.ex. security requirements might involve additional kinds of interactions)
http://www.online-stopwatch.com/large-stopwatch/
Very nice stop watch for measuring how effectivelly you spend your time.
I also tried this time in meetings - helps to be always aware how much time is left and prevents wasting time :)
p.s. i am also using it as my pomodoro :)
http://www.pomodorotechnique.com/
Very interesting book ...
The basic unit of work in the Pomodoro Technique™ can be split in five simple steps:
1.Choose a task to be accomplished
2.Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3.Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4.Take a short break (5 minutes is OK)
5.Every 4 Pomodoros take a longer break
And look! It is a bit related to SCRUM ;)
The primary inspiration for Pomodoro Technique was drawn from the following ideas:
time-boxing, the cognitive techniques described by Buzan, among others, relating
to how the mind works, and the dynamics of play outlined by Gadamer. Notions relating to
structuring objectives and activities incrementally are detailed in Gilb.
Very good summary of what problems we face while making a schedule - http://www.cprime.com/knowledge/articles/uncertainty.html
Why Uncertainty Exists
Suppose we are estimating the effort required to remodel a house. We will start by breaking down the project “Remodel House” into a few smaller steps, namely
Remodel Kitchen
Remodel Bedroom
Remodel Living Room
We want to estimate the effort required for each of these steps, such as “Remodel Bedroom.” Unfortunately, our estimate will not be exact. Estimates differ from reality because of uncertainties, which arise in many ways
Incomplete Understanding of Scope
We may not have accounted for all the requirements. Do we need to replace the baseboards? If we didn’t think about the baseboards, our concept of scope is missing an important element, and our estimate will not include the work to replace them.
Incomplete Understanding of Work per Scope
Perhaps we did include baseboard replacement in scope, but we assumed the effort involved was limited to nailing the new ones in position. Unfortunately, we didn’t account for the work required to measure and cut the baseboards to the right size, so even though the scope was right, the effort estimate will be too low.
Imperfect Understanding of Known Work
Even if we did remember all of the work that needs to be done for the baseboards, and estimate accordingly, our estimates may be off because some of the boards split when nailed. We will either have to replace those baseboards, or drill them to avoid splitting when we nail them. Either way, the work will increase beyond our estimate.
Inability to Forecast the Unexpected
What happens if the paint we need is out of stock, or someone delivers the wrong baseboards? These external events are unpredictable, and disrupt our schedule.
How to Cope with Uncertainty
Once we have reduced uncertainty to a practical minimum, the only other thing we can do is to take the remaining uncertainty into account in our process. We’ll look at strategies suited for projects that are subject to different kinds of constraints below. (For simplicity, we’ll assume that resources are fixed, since the ability to add resources does not vary in a meaningful way between the different scenarios. Similarly, we also assume that scope is well-enough controlled to prevent scope creep.)
Fixed Schedule, Fixed Scope
The first thing to understand about this set of constraints is that success is not always possible. If scope is truly fixed, and schedule is subject to uncertainty, then we have already seen that extreme cases will break any schedule.
These projects are planned with uncertainty in mind, by adding enough buffer time into the schedule to handle a reasonable level of uncertainty (for example, allocate 30% of the schedule for this purpose). This approach works well in situations where uncertainty is small, such as for repeating processes (e.g., laying carpet, or painting houses).
Fixed Schedule, Adjustable Scope
Many agile project-management frameworks handle uncertainty by committing to the only thing that can truly be controlled, which is the schedule, and adjusting the scope as required to meet the schedule. This strategy is particularly useful in high-uncertainty environments, where estimation is known to be inaccurate, and where scope is not well-understood and may change frequently.
The Scrum framework handles this situation effectively. It requires careful planning, but in a way that handles high uncertainty gracefully. Scrum projects work in short cycles to deliver modest increments of scope quickly, and to allow for frequent changes in scope and priority. Within each cycle, scope is adjusted as necessary in order to guarantee that the schedule is met.
No Schedule, Unknown Scope
Uncertainty is greatest when the scope is not known prior to the start of execution. This is the case for reactive organizations, such as Customer Support groups, which receive urgent requests that must be handled quickly, but which cannot be scheduled or planned in any meaningful way.
Another agile process, Kanban, is useful for this scenario. Kanban processes re-prioritize requests daily, and throttle (control) the flow of work by limiting simultaneous work-in-progress to a specified number (e.g., up to three concurrent requests can be handled by the staff).
There is always a desire to compare productivity of different team's. But naturally questions arise how can we do it, because Team's might be working on different domains and they are estimating work in story points, ideal days, Fibonacci numbers and etc).
It is obvious that Story points used in one Team are not necessarily equal to other's Team numbers, so these just can not be compared.
But when it comes to estimating in ideal days than we naturally want to compare it and it looks valuable for us :)
But i accidentally got into very interesting article discussing this issue.
Most of the guys there agreed on the following:
Any attempt to measure (or worse, incent according to) the productivity of different Teams is fraught with peril. It will destroy morale and lead people to game the system.
I tend to agree, but i think that Scrum Master must be responsible of preventing people trying to game the system. Because overall productivity is very important in our company when teams are working on the same product.
Very interesting article - http://www.imediaconnection.com/content/25973.asp
Main aspects I highlighted for myself and i think we are moving to the right direction.
- Financial data
Integrate ad serving tools with financial systems that are used by customers.
- Buy-side data
CPC is not so useful, you can get more value comparing data from display and search campaigns.
- Audience data
Target audience, not page.
It becomes obvious that even though internet advertisement is relatively cheap, but industry needs to focus on making it more effective. Probably social medias and mobile advertisement could help to do this.
