Day 6.

A new week and we're standing up in the morning again. Ah the stand-up meeting, remembering what you did on friday can be a struggle sometimes, especially with a busy weekend.

With the static views of the tasks being done we are now trying to create some dynamic fields to make it a little 'snazzy' for our users. This is proving to be a much bigger challenge and more time consuming  than initially predicted. But then again, it's more unique, which makes for a great learning opportunity.

The tasks are slowly, but surely inching their way to completion, with some more problematic ones rearing their ugly heads at us and giving us a hard time.

Day 5

We had our first sprint stand-up today! This was new for everyone on the .Net team, but as the concept was simple and communication good, we had no issues with it.

With the first sprint planning being quite thin on user stories, we struggled with choosing tasks that didn't depend on the previous tasks or were ready to be taken on. With limited tasks and unlimited brainpower, we settled on coding in pairs with one person coding and the other observing and vice versa.

The day itself was quite productive, but hasty errors proved to be tough to crack, as the first commit made dealt with a similar issue as the last commit.

One does not simply git push

At the end of the day we voiced our concerns about the bootcamp, the milieu, the people or anything we could think of. All of the feedback was positive and everyone was content.

I for one was exhausted when the week ended, with my mind buzzing with new information.

Day 4. Software architecture and our first lines of code

First thing in the morning our mentor Markus gave us a quick overview of software architecture and demonstrated them with some practical code. He made some good points about code reusability being dangerous when the need comes to alter the codebase. And warned against leaving vulnerabilities in your accessible layer.

Our first sprint planning was a joyful endeavour as we were getting so close to starting to write some code and starting to fulfill the plans made for the last 4 days. With some back-and-forth with the client we managed to create 12 user stories. Assigning story points was a fun and slightly odd experience as during the first sprint planning meeting the story points value is still wildly inaccurate. In the end we decided to take 10 user stories into our first sprint.

After some confusion about splitting up the user stories we managed to get our first stories and tasks on the scrum board. This meant we could take a task and start developement! Right? Well almost, we still had to create the underlying data model. So we split into teams and half of us started work on the view and half of us on the model. It was strange working with multiple people on the same problem as there was more explaining and questions, time will tell what will come of this.

In the evening we had a pub event with our bootcamp team. So this was us arriving there.

We filled out 3 tables in a cozy bar called Kivi Paber Käärid. The mood was relaxed and it was nice to chat to the employees of Helmes without the subject being about the bootcamp. We taught our foreign teammates some Estonian classics such as counting to 12, teaching them how to pick up girls. All in all a great evening!

Day 3!

Agile development and Scrum

The day started with creating vision for the UI based on the information gathered in the client meeting yesterday. Armed with our notes we started hashing our the fields and views to our best ability.

With a baseline design done we were joined by our helpful clients and analysis team, who helped us phrase high level business requirements. In order to do this we had to define a series of points, that would end up helping us form an elevator statement and business goals and their metrics.

The task was not easy

First off we  determined who would benefit the most from our application and they would be our client. Secondly we identified the need, for which they needed to use our application. Then we had to have a great product name for our creation and classed it into a product category. A big aspect was the list the key benefits, that our solution would provide. And to finish off we described what would be unlike the current process e.g. make the process less time consuming and create less errors.

Discussion is key

Don't forget to document your decisions 

Make sure the whole team is on the same page

Afternoon began with a seminar about agile development and Scrum. It was a free-form lecture conducted by Raul Annus, the head of development in Helmes. We started of the lecture with the question why agile development is needed and what makes software development so difficult. In the end we managed to word in our own words a few points :

• Environment changes fast
• Very many dependencies
• Software is only a representation, not the real thing itself
• Software disrupts the business process

In conclusion we ended at the realisation, that there is never a perfect analysis of the problem and that making something faultless is limited by us being human and making mistakes. In agile you have to make a small usable product and actually test it within the business process as a whole. But in order to build something useful you still need to align the strategic business goals and the business needs, only the features have the luxury of not being right 100% of the time.

After a small break we had a meeting with our stakeholders and intruduced our UI to them. Showing a mock-up of the UI got the team leads creative juices flowing and we got a good idea of what the UI would look like in a perfect world. 

Day 2!

The dread of meeting with the client

The preparation

Day 2 started with an analysis seminar, where a Helmes analyst Kaisa gave us some tips on what to do when meeting with the client. Some notable advice was to keep it simple, produce a MVP and don't promise things you can't deliver.

After the seminar we had our analysis mentor helped us to create a questionnaire to maximize the time we had with the client. The questions used the following guidelines:

• WHO (who is the client?)
• WHY (why are we doing this?)
• WHEN (what are the timelimits?)
• HOW (platform?, existing code?, analysis process setup, communication?)
• WHAT (the actual business requirements and functionality of the system, what is the actual need of the client)
• PROBLEMS (what would be their priority: minimum viable problem)

Constructing the questions was no easy task as we had not worked with clients before so coming up with the business process questions was an unfamiliar activity.

Photoshoot

Before meeting the client we gave a photographer the wonderful opportunity to make some software developers smile. 

As seen on the photo below everyone enjoyed themselves and the photographer didn't have a hard time at all!

The meeting

The meeting with the client started with everyone introducing  themselves and their role in the project. With the introductions over we hunkered down with our questions and started trying to get the information we needed from the client. Our initial plan was to ask about the high level idea of how the current business process worked and what the problem with it was. Having asked the question we were barraged with information about what the problem is and how the new system should fix it. This may have been due to me asking the question we had previously written down more palatable. There's a lesson in this, make your questions clear and concise and perhaps take your clients background into account as the client was knowledgeable about the system and it's requirements. Thanks to a great scribe we managed to get a lot of information about the specification. 

The second surprise came when about 1/3 of the way into the meeting I realized I had completely misunderstood the problem. You see, I thought we were to make a system that creates and saves contracts. This was due to my poor understanding of the project brief given to us earlier. Actually we were creating a system that added some metadata to the contracts to make them accessible. With a flustered face I kept calm and carried on.

After the meeting our mentor said the data we had gathered was good and the meeting went very well. We systematized our notes and headed home for the day.

1. day! Introductions and workstation set-up.

Introductions

The bootcampers with Helmes staff

On the first day at the Helmes Bootcamp we met the two teams in the bootcamp and the bootcamp team, who will help us on this exciting journey. We had a introductory meeting and saw and met all the people  who will be directly interacting with us. The mood was light and everyone was friendly. We also got an overview of the core values of Helmes with the uplifting slogan of "We want to be the best software services firm in the world.". True enough, the inquisitive mind of the bootcampers wanted to know, how being the best is measured and the answer is by employee happiness, client happiness and efficiency.

The aim of the bootcamp will be to offer an intensive software development training, see what Scrum is in practice and to complete a full software development process. The evaluation criteria for the bootcamp is surprising compared to the aim with 30% of the evaluation coming from the result of team work. Helmes really seems to value interoffice relations. Achieving business goals will determine final evaluation by 25%, following Scrum principles 20% and code quality and successful sprints attribute 15% and 10% respectively. So coding proficiency is not the most important aspect by a long shot.

The teams and projects

This year there were 2 teams taking part in bootcamp: a Java team and a .Net team.
Projects for this year were Licences allocation and Applications Accesses and Contract Register. The Licences allocation and Applications Accesses focused on managing licences that are distributed within Helmes and aimed to help managers free up unused licences. This project was assigned to the Java team. Contract Register aimed to add a new module to an existing application, that would help Team Leaders manage contracts. A clever person would assume this was the assignment for the .Net team and they would be right!

The setup

After the introduction of the projects it was time to set up the workstations and attempt to get our first commits to the development repository. After installing all the prerequisite software the .Net team ran into a problem with connecting to the development database and we were unable to verify that the base application worked. Java team did not have this problem and they were off to the races, learning about git commands that they had not used before. While the Helmes staff debugged the problem with the connection we got some tips from our mentors and I personally learned, that more often than not, if you don't build logging into your application as you build it, you will never add it afterwards.

That was it for day 1!

20. päev

Lõpudemo
Mõlemad meeskonnad esitlesid kõike seda, mida nad valmis said 4. nädala jooksul. Arendati valmis minimal viable product (MVP) projektist, mis läheb reaalselt kasutusse. Rakenduste tellijad jäid tehtud tööga väga rahule.

PHP meeskonna lõpudemo

.NET meeskonna lõpudemo

Lõputseremoonia

Lõputseremoonial anti meeskondadele üldiselt tagasisidet ning tehti kokkuvõtte möödunud arendusnädalatest.

Väga paljud Helmese töötajad aitasid Bootcampi korraldada - ka neid tänati lõputseremoonial.

Iga osaleja sai tunnistuse, et nad on Helmes kuu ajase intensiivse tarkvaraarenduse koolituse läbinud.

Tagasiside

Osalejad andsid korraldajatele tagasisidet, et mida nad oleksid tahtnud teistmoodi teha.

Ühine lõuna
Bootcamp algas samamoodi nagu lõppes - ühise lõunasöögiga.

19.päev

Sprint demo 
Viimane sprint lõppes sprint demoga.
Avaliku esinemise nipid
Kuna osalistel on tulemas kõige olulisem avaliku esinemine Bootcampis - lõpudemo. Lõpudemole on kutsutud kogu Helmes Eesti töötajaskond. Kuna oodata on suurt kuulajaskonda, siis räägiti Bootcampi osalejatele põhilistes avaliku esinemise elementidest ning kuidas vältida tüüpvigu avalikus esinemises.
Ettevalmistus lõpudemoks
Kui sprinti demod on väga kindla formaadiga: demotakse konkreetsel neid asju, mis sprinti planeerimisel sai kokku lepitud. Lõpudemol on aga osalistel väga vabad käed. Selle eesmärk on demoda kõike seda, kui suure tööga osalised kogu Bootcampi jooksul hakkama said. Mõlemad meeskonnad said valmis töötava rakenduse, mida hakatakse Helmeses kasutama.
Video treening
Osalised tegid läbi lõpudemo kaamera ees. Kui demo tehtud, siis vaadati kõik koos demo lindistust. See analüüsiti läbi ja tehti järeldused, kuidas saaks veel paremini.
Lõpupidu
Osalised ja mentorid läks õhtul kõik koos kokkama. Tehti tippkoka juhendamisel endale super maitsvad road. Räägiti juttu ja nauditi viimast ühist õhtut koos.