After a very intensive and practical Agile Lab, in which I had to prepare two talks – one on Agile techniques and other on Geolocation, today I had the pleasure of participating in a very nice SCRUM Talk presented by Mr. Jens Trompeter, Board Member in Itemis company.

Itemis company is specialized in Model Driven Software development. Its products ranges from mobile and embedded applications to Eclipse Modeling Project. They also offer Consulting and coaching and Agile project management.

We acknowledged today that there's more in SCRUM than just that we learned  from the Agile Lab and OOSC class: we had the opportunity to get real life, production-grade advices on how actually this technique (who is used to manage the projects) can help companies to finish projects in a timely and budget manner. Also, we understood that Agile techniques complement really well the SCRUM managing by filling the gap in software development. So both these methodologies can drive creation of a software product to a success if properly managed and understood.

We had in the first part a general theoretical presentation of the concepts and the involved roles who helped me remember the key concepts learned also in the Agile lab. In the second part, we had a more practical presentation on how these techniques are applied. Mr. Trompeter was very patient with us, students, interrupting himself many times to respond to our questions.

View Full Album

Today's presentation came as a practical complement to the Object Oriented Software Construction(OOSC) course, who introduced us with concepts as

With all these in mind, I'm very happy that I took part to this presentation. I left with a very nice package of information who I hope will help me in my career.

Post from: Radu Poenaru's Weblog

SCRUM Presentation

Position: Assistant Researcher ( WHK or Wissenschaftliche Hilfskraft )

Starting 1. March 2010 I work in Informatik 3 Department of Rheinische Friedrich-Wilhelms-Universität in Bonn.

My master is a joint effort between Uni Bonn and RWTH Aachen. During my master, I had the pleasure to be part in the Agile Lab, where I encountered two Research Associates, Pascal Bihler and Mark von Zeschau. They are true developers, result driven people and fair judges of our activity. During this lab, which was intensive, we had 3 weeks as developers in an almost real company environment. From 9 to 18, if you know what I mean.

The experience that I had we very nice and as soon as I could, I discussed with them about joining their development team. Now I have the pleasure of developing a project that will affect all students that will study in this department.

The project is an upgrade to the existing system and will be developed in Ruby on Rails and have a Postgres database, allowing students to have a better application experience. The basis of it are an interactive and dynamic application who has several workflows, involving both possible future students and professors into finding the best candidates for this fine university.

My responsibilities are:

• development in Ruby code on Rails platform
• database migrations / upgrades
• installing / configuring gems
• CSS / interface design
• JQuery JavaScript client side interaction
• testing of the application

This is one more important task who caries with it big responsibilities, but I’m feeling very good about it!

Post from: Radu Poenaru's Weblog

UniBonn

In the Autumn of 2008 I joined the Media Informatics Master program, saying goodbye to Alensa Online team. It is part of the Bonn-Aachen International Center for Information Technology (B-IT) and was created through the collaboration of prestigious German institutions:

• University of Bonn,
• RWTH Aachen University,
• University of Applied Sciences Bonn Rhein-Sieg,
• Fraunhofer Institute Centre Birlinghoven Castle IZB

Supported by the B-IT Foundation and complementary state resources, B-IT offers highly selective International Master Programs in Applied IT, as well as the summer/winter schools for qualified computer science students.
Most courses take place in the beautiful B-IT building next to the former office of the German Chancellor on the banks of the River Rhine in Bonn.

The University of Bonn has almost 200 years of history, over 38.000 students from 130 countries, with an excellent research record and an excellent graduate education have made one of the ten largest universities in Germany.
In the context of more than one hundred first degree programs, the university engages in a broad range of international co-operations in research and teaching.

Founded in 1868, RWTH Aachen University is Germany’s top-ranked University of Technology and one of Germany’s nine Elite Universities. Of its 30,000 students, over 4,000 are international, including 900 students from the Asian-Pacific region. In addition to 65 first degree programs, RWTH offers more than 20 graduate programs in Science and Engineering.

Within the Fraunhofer Society of Applied Research, the four institutes in Birlinghoven Castle represent a quarter of the largest IT research organization in Europe. Over 500 post-graduate researchers investigate Autonomous Intelligent Systems, Applied Information Technology, Media Communications, Algorithms and Scientific Computing in a world-wide network of industry and research partners.

Post from: Radu Poenaru's Weblog

Media Informatics Master

Each method presented has its strengths and weaknesses. None of these is the perfect positioning system, yet they all can collaborate in order to give the estimated position of a user.

GPS, the veteran of the group, has a plethora of satellites at its disposal, offering almost anywhere in the world a precision in meters. The devices which implement this technology are small enough to be inserted even in phones, smart enough to do their job or even more by tracking many satellites in the same time and eating less power, affording the usage of this service for hours in a row. But it needs clear sight to the sky in order to see at least 3 satellites and needs quite a long time in this busy era to get a clear position and be able to pinpoint the location on a map.

Its child, the aGPS helps by relying not only on satellites but also on GSM towers, locating and triangulating them too. Knowing their location, the power of the emitted signal, the user can be easily triangulated. Especially useful in crowded cities, where many GSM antennas are installed removes the need for a clear sky. Thus, it allows even in places surrounded by tall buildings to have a good enough precision while locating the position on the map.

The GSM positioning system continues the movement of the positioning technologies from the sky to ground bases by replacing completely the satellites from the picture. In developed countries there are a lot of GSM towers in urban areas. This is added to the fact that this technology doesn’t eat more power in phones. Since the phone knows by default how to measure and get the tower’s id, there is just a software issue to get the ids, match them to a table with geographical positions and triangulate based on the strength of signal the user’s position. But if you’re in a remote area, like in mountains, where there are few emitters the quality of location falls dramatically.

Wifi, on the other hand, is a newborn technology created out of the people need to communicate. Internet access is getting cheaper and cheaper, being for some business a nice feature to offer. Especially the large fast foods chains offer free wireless Internet access, but also people with enough bandwidth offer this for free. And given the fact that in the big cities these hotspots are countless, some smart guys invented a positioning system based on tracking these hotspots location, offering sometimes a comparable precision in comparison with the classic – the GPS system.

Bottom line, no method is perfect – GPS needs clear sky, aGPS improves this but still needs some satellites to be seen, GSM works like a charm if you have lots of antennas but falls dramatically if you’re in a remote place and WiFi positioning is good in cities, but absolutely lacks in remote zones. Only the composition of all can cover all the situations encountered in a normal life – crowded city when going to work and big, empty spaces when going to mountains to relax.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009(besides the images whom are taken from internet)

Post from: Radu Poenaru's Weblog

GPS vs aGPS vs WiFi vs GSM localization

GPS is the oldest one from the frameworks available to the large audience. It isn’t the first positioning system, but it is the one with the most success and longevity. It started as a military project in 1957. Because of the cold war, once the Russians sent to space the first man-made satellite, a team of scientists started monitoring its radio transmissions. The crucial discovery was that, because of the Doppler Effect, the signal transmitted frequency increases as the satellite approached, and lowers as it continued moved away from them. This added to the fact that they knew their exact location on the globe, the logical conclusion was that one could pinpoint where the satellite was along its orbit by measuring the Doppler distortion.

Since then lots of GPS signal emitting satellites were launched, now the entire surface of the Earth being covered by them. Since 1983, it became also available to civilians, but with lower precision (but still 50 m were quite good for that time) and higher times for getting the current position.

The mechanism of its functioning is simple: you need three satellites to get your precise position in the device line of sight, unobstructed for entire period of measurement, or four if you want also the elevation. The device receives high precision clock signals (atomic clock precision) in order to measure the delay of the wave between the satellites and earth. Then, using triangulation, the location can be pinpointed on the Earth surface by doing some math calculus. The entire process takes few minutes in a device start and less if the device is readjusting the location.

Since its creation, it was used in all domains: aviation for getting to the correct location, help and rescue for climbers and excursionists which missed their path in mountains, sea navigation and now more and more for city navigation. Since the receivers became so miniaturized that they can be easily fit into smart phones, one can use it to get to a newly recommended cafe or theatre without having to carry with it the map of the city.

The recording devices that use GPS can be split into three categories:

1. Data loggers – log data as it arrives and here we can include almost all devices with user interface, no matter that this device is a cell phone or a standalone device. They simply receive the GPS signal, record it and show it to the user.

2. Data pushers – the kind of devices using for tracking logistic fleet in realtime- they read the GPS data but instead of only show it to the user, they also send it via GSM connections or radio to a central location where it is processed. Then the data is analyzed and the merchandise path to the client can be optimized.

3. Data pullers – almost the same as the pushers, but instead of sending by their own at specific intervals data to the central location, these ones can be queried as needed. One of the most important usages is placing one of these devices inside of a valuable device and if stolen it can send its position once queried for it.

The main drawback of this technology is the fact that it requires clear line of sight to at least three satellites. In crowded urban areas or in mountains, this is a luxury. New technologies help minimizing these facts, like Assisted GPS which relies also on GSM towers to get its location done.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

GPS – Global positioning system

What is SCRUM ?

• one of Agile processes
• use incremental framework for developing complex software
• managing new products
• considered more like a framework in which you can employ various processes and techniques
• Key principle: during a project the customers can change their minds

Manages complex processes by:

• Transparency
  • The outcome of the product should be visible to the manager who is managing the outcomes. Also each process that affect the outcome of the product also should been visible to the managers.
• Inspection
  • Various aspects of the process must be frequently inspected regularly so that quality of work and peoples can be seen.
• Adaptation
  • If the inspection process find outs some process are outside the scope of the product or the outcomes will be unacceptable, then the inspector should response quickly and adjusts the process or data being used in the process.

The partners in this process are:

• Product Owner (Also known as chickens)
  • is responsible for the communicating version of the product.
• Scrum Master
  • Scrum manager provide cooperation between the product owner and team.
• Team (Also known as pigs)
  • It’s the team which performs work or sprint- usually there are many teams working on their sprints and each team consist of 5 to 9 cross-functional members.

Main SCRUM terms:

1. The Sprint
   • Sprint is one iteration. Project is dived into small workable sprints which take 2 to 4 week durations, no change to the sprint backlog
2. The Backlog
   • list of requirement from product owner based on their priorities – after every sprint, backlogs are updated.
3. The Sprint Backlog
   • the information how this sprint going to be implemented- process/features are broken down in to small tasks (6 to 8 hours) for teams.
4. The Time Boxing
   • Everything in scrum is time-boxed – It’s about release planning meeting, sprint planning meeting, sprint review and daily scrum meetings.
5. The Daily Meeting/Scrum
   • also called as "the daily standup“ – 15 minutes and all peoples are welcome to join but only the teams (pigs) are allowed to speak. This meeting has only 3 questions to answer
     • What you done yesterday?
     • What you will do today?
     • Do you have issues which are stopping you doing this job?

This is a good example of pattern that started from Software industry going towards the other industries – as opposed to Toyota Production System:

• first applied to software development
• but then successfully used in big industries
• now it used for developing any kind of product.
• the best part of SCRUM as compared to other agile process that it introduces the idea of real world progress of a project not just the best guess on unknown information.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

SCRUM

Waterfall model: Predictive model Optimized for a single purpose Hard to change	eXtreme Programming Reusability Easy to change direction But no idea of next 6 months

Because the software industry is so different than any other, the development model used prior of creating agile methodology was taken from the engineering disciplines, such as civil or mechanical engineering. Those disciplines put a lot of emphasis on planning before you build because the resources are very expensive and cannot be wasted because of bad synchronization or different physical characteristics like calibers, by example. The planning style is a predictive method that focuses on planning the future in detail. A team that uses these predictive techniques can report precisely what features and tasks are scheduled, both their order and length, for the entire time span of the development process. Predictive teams are very difficult to redirect after the client needs. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. These teams will often institute a change control board to ensure that only the most valuable changes are considered.

Opposed to this, the software as industry relies more on reusability and on site modifications. If a programmer finds a piece of code, of course respecting the intellectual property, can easily adapt it to his project. This approach is called adaptive, because these methods focus on adapting quickly to changing realities – no customer knows from the start exactly what he needs from the start. When the needs of a project change, an adaptive team changes the specifications as well. But this comes with a drawback; because an adaptive team will not be able to describe exactly what will happen in the future, it will precisely know only the current step, the next one depending on the user feedback. Thus, adaptive team knows exactly what tasks are being done next iteration, has an idea about the overall project, but only which features are planned for next month. But if asked about a future release, let’s say six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Post from: Radu Poenaru's Weblog

Agile vs Waterfall

This methodology and set of principles has the root in the company with the same name. After the Second World War, the Japan and its companies were almost ruined both physical and financial. To recover the economy, they had to rethink all the processes of production in order to maximize their efficiency. This was required because not only that they lack financial resources, but even the loans that they could do as a country came with big price. In Toyota Company, a smart man called Taiichi Ohno, created a new way to build cars, focusing on creating as many quality products possible with limited amount of resources.

The three principles that guided the rebirth of Toyota and other Japanese companies were:

1. Build only what is needed – literally, they strived to build only products for which they knew that a customer exists. There was no room for additional expenses with storage and building stocks of merchandises, thus only the products quickly convertible in money survived. Also the quality of them assured that they were solvable.

2. Eliminate anything that doesn’t add value – meaning that the product should be really useful to the customer, but also more usable than the one of the competition – assuring that the entire production is sold fast, thus improving also the flow of money in the Japan’s almost ruined economy.

3. Stop if something goes wrong – this is almost a sum of above principles, ensuring once again that only quality products are built. In any process there can be faults, but if stopped when they are minor, by the first worker who noticed the defect, a lot of time and resources can be saved. This is the base principle of zero-defect production, based on a quick feedback of wrong action rather than the late confirmation that an error occurred somewhere along a long line of production.

Besides respecting and caring for budget and products, the Toyota Production System also settled in work environments a set of values, creating a philosophy of work, which:

· respects those engaged in the work

· strives for full utilization of workers’ capabilities

· places authority and responsibility for the work with those doing it, enabling any worker to stop the entire line of production if he knew about a defect.

These principles thrived in Japan, as we all know now, after more than 50 years, bringing it to the top of the biggest economies in the world. Almost all companies soon adopted these principles who were tested by Toyota, becoming the usual way to conduct a business in this country. Very surprising, they weren’t very appreciated in other areas until 1980. These ideas were so well implemented in Japan’s industry, that their almost destroyed industry became the main producer of cars, expanding throughout the world. Even more, during the oil crisis in 1975, they quickly adjust their production to new demands that prove again that Ohno’s principles aren’t obsolete and don’t depend only on the theory behind, but more on the people that implements it.

The Toyota Production System entered into the largest economy, USA, late in 1980 as a tiny idea and later in 1990 they actually started to think seriously about it. The pioneers in this area were James Womack, Daniel Jones and Daniel Roos in the book “The Machine that Changed the World” published in 1990 and by Womack and Jones in the sequel “Lean Thinking” in 1996. They coined the term “Lean Thinking”, depicting a set of five principles, more general and not limited to industry, but to all enterprises independent of field of activity, as follows:

· Specify value

· Identify the value stream – line up activities which contribute value, eliminate those which add no value

· Create the conditions for value to flow smoothly through the stream

· Have the customer pull value from the stream

· Pursue perfection – work on improving the responsiveness of the production system to the customer demand for value

These principles didn’t remain only as ideas, but were quickly adopted by the economy and also fundament a new base for research, in the newly founded Lean Enterprise Research Centre in Wales, England, where it became an instrument of researching, documenting and spreading the lean techniques for improving the work processes.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile roots: Toyota Production System

Because the software industry is so different than any other, the development model used prior of creating agile methodology was taken from the engineering disciplines, such as civil or mechanical engineering. Those disciplines put a lot of emphasis on planning before you build because the resources are very expensive and cannot be wasted because of bad synchronization or different physical characteristics like calibers, by example. The planning style is a predictive method that focuses on planning the future in detail. A team that uses these predictive techniques can report precisely what features and tasks are scheduled, both their order and length, for the entire time span of the development process. Predictive teams are very difficult to redirect after the client needs. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. These teams will often institute a change control board to ensure that only the most valuable changes are considered.

Opposed to this, the software as industry relies more on reusability and on site modifications. If a programmer finds a piece of code, of course respecting the intellectual property, can easily adapt it to his project. This approach is called adaptive, because these methods focus on adapting quickly to changing realities – no customer knows from the start exactly what he needs from the start. When the needs of a project change, an adaptive team changes the specifications as well. But this comes with a drawback; because an adaptive team will not be able to describe exactly what will happen in the future, it will precisely know only the current step, the next one depending on the user feedback. Thus, adaptive team knows exactly what tasks are being done next iteration, has an idea about the overall project, but only which features are planned for next month. But if asked about a future release, let’s say six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Agile methods are a family of development processes, not a single approach to software development. It represents the ways of creating software in a lighter, faster, more people-centric way. The base of this is the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. The Agile Manifesto states that:

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

As methodology, agile development tries to push the development process to the user intended direction, providing many opportunities to assess the direction of a project throughout its lifecycle. This is achieved through iterations of work and at whom end teams must present a finished piece of code, usually a piece of shippable code. Because of this repetition of small chunks of work, as well as the functional product they yield, agile methodology can be described as “iterative” and “incremental.” As opposite, in waterfall approach, development teams have only one chance to get right each aspect of a project. Even more, in an agile paradigm, each and every one stage of development like requirements, design just to mention two of them, is continually revisited throughout the project lifecycle. Because of the short periods between reevaluations, usually couple of weeks, when the team stops and re-evaluates the direction of a project, there’s always time to redirect it in the correct direction.

The results approach to development greatly reduces both software product development costs and time to reach the market. In other methodologies, there’s a dead time associated with creating complex specifications while development team is in a code writing pause. Agile teams, on the other hand, can gather requirements at the same time they’re implementing them, so this process can’t really impede a team from making progress. And because a team’s work cycle is limited to few weeks, it gives stakeholders recurring opportunities to recalibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product.

This combination of features is an attractive option for stakeholders and developers alike. In the end, the development agile methodology preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile – techniques, principles and methodology

The roots of agile programming as we know it can be traced back to 2001. At Snowbird ski resort in the Wasatch Mountains of Utah, a group of seventeen people met have fun, but also to find common ground on a issue that was too much discussed but no result can be achieved. They were the leaders of different currents of improving software creation techniques. They were adepts of Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming and other agile techniques, joined together by the need for an alternative to documentation driven, heavyweight software development processes.

All enumerated methodologies of software creation have the common ground of recalibrating themselves and their result, the code, will be crafter to the user’s desire by asking for input on each stage of project evolution. These recalibrations occur after the user evaluates the product, creates a feedback and sets the next iteration goals. This is also known as sprint or iteration. The sprint is organized into three parts: code creation, user review and setting new goals. At the end of every sprint, the team presents a functional module or piece of software to the user responsible with this for review. This emphasis is on creating a shippable product and also ensures that the software engineers from that team don’t get overwhelmed with a huge amount of requirements. The sprint has a specific length and this can either be set in the first place or can be adjusted later, depending on the team members personal skills or the load with tasks.

Because sprints repeat and the resulting code continually grows in functionality, this style of programming – Agile – is described as “iterative” and “incremental.” Comparing with the waterfall model, the development teams have just a single shot at getting each part of a project right. Usually, the longer and complex the project is, the farther will be the product to desired functionalities. This is happening not because of bad programmers, nor bad specifications, but because the lack of feedback. Fortunately, the Agile style not only asks, but enforces the process of getting the final user or Product Owner feedback.

With the advantage that teams can gather requirements while coding, the process of creating, maintaining and rewriting them is greatly reduced. Thus the customer will not be bored too much with them and fewer errors can be slipped into this process – bored people are more prone to errors. The agile team can focus on smaller tasks, delivering quality and almost bug-free and also having all the time the good feeling of making progress. While agile teams develop within the short, repeatable work cycles, the owners or users have all the time the opportunity to look at the results, test them and ensure that the product being created really matches the customers’ need. Bottom line, we can conclude that agile programming helps companies build products their customers want.

Note: This is an excerpt from my work during Agile Lab and Seminar in Fall 2009

Post from: Radu Poenaru's Weblog

Agile Lab – Coining the Agile techniques