Meet me at 4developers conference!

15 03 2014

Warsaw, 7th of April 2014, the 4developers conference will take place. Last year edition was full of outstanding speeches and workshops, therefore I am really honored to be the speaker in this year’s edition!

jestem_prelegentem

Together with Łukasz Roth, who inspired and initiated our talk, we’ll be talking about the way how the interaction designer can collaborate with software developers within the Scrum team to build impressive app that meets user’s needs, is good looking and developed in an Agile way.

I am really excited to take part in this event with Łukasz as the speakers, as well as to be the auditor on other sessions and meet all those people attending the event!

Advertisements




Why TDD is hard?

7 04 2012

Test Driven Development is not about testing – it’s about the design. It is worth to remember that the idea of preparing tests first is difficult if You are preapring… tests. It is much easier when You see it as a design requirements. After that, You test if design requirements are met by software. Not only test the if the software works correctly itself.

Tests are prepared first, then the software is written. The goal is to design software in detail so that test cases check if software meets requirements.

This is new way of thinking about software that is in common with Agile methodology. Software is created from the users’ point of view. First You define (in tests) how software has to look like and work, then just implement it so that all the test cases are fulfilled. There is no doubt that this is the right approach.

The problem is that writing the tests, developer does not write software itself, but give his time to other tasks. The clue is to believe that this will save time and resources in future – simply by limiting the amount of bugs that would consume developer’s time if not discovered in early phase with TDD.

It is not easy to write tests that will reveal all bugs, but spending more time on particular part of software code increases its quality itself.  I still did not managed skill of writing test ahead of software, but I am doing my best!

Do you like my blog?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!





Scrum User Stories

31 03 2012

First thing that should be done before Scrum project launch is defining user stories. These can be compared to well known use cases, however they are not the same. This article is worth reading first, if You are new with Scrum.

Use Case versus User Story

Use case is general term specifying area in which product will be used. For example a car can be used in one case in company for a salesman transportation tool or – in another case – at home in family’s every day life. Wiki article section describes in simple manner.
User stories defines details of certain use case from the users point of view. They are based on the following template:

As a <product user> I want <what> so that <users benefit>

The goal is to look at the product from the users perspective and deliver products that suits their needs. Sample user story may look like:

As a salesman I want car to be equipped with GPS so that I can easily set my direction”

You can define as much user stories as You wish – it depends on project complexity.

I. N. V. E. S. T. in User stories

Well prepared user stories should follow the INVEST idea. Its theory is well described here (begin with slide 12). Further in text You will find some practical clues.

User story should fit sprint

The biggest user story should be small enough to implement it during one sprint. It is possible to build small stories although it requires a bit of work. During sprint itself the user story can be divided into small tasks and distributed in self organizing team.

Definition of done

Each user story needs a criteria of completeness. This is the moment when nothing more has to be done to fulfil it (for example: salesman can reach his goal thanks to GPS in his car). The team should implement functionality having definition of done in mind. Team should not be predictive and add new things that overrides the done definition. These will be added in next user stories.

User story’s complexity and priority

Priority depends on business requirements and/or technical constraints and probably there will be no problem with defining it.

Complexity is a bit more difficult to evaluate. This process begins with assessment of one user story that is easiest to estimate (basing on team experience). The latter user stories are compared to stories already assessed. Team decides if tasks connected with it are more complex or not, and how much. It is easier to compare unknown task to the known one and assess it, than assess unknown task from scratch.

Complexity unit

There is no complexity unit :) You just give it some value without a unit. Nor days neither hours are used. If user story has complexity 8, and another one seems to be much more complex You give it complexity 40. There is no need to measure it in days or hours. You just see that one task is 5 times more complex than another.

Planning poker

Complexity values, given to the user stories, are taken from the Planning Poker subset:

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (unknown)

It is easy to define complexity accurately if it is small. If it is bigger – it is difficult and not needed. It makes sense to say that something is 1,5 meter long in opposite to say that something is 1000,5 meters long. This 0,5 meter is not significant in latter case.
Planning poker has simple rules: each team member chooses one card from his set and estimates task on his own. Then each member shows his card and agree on complexity value after short discussion.

Product backlog is a set of user stories

Functionalities that come from user stories should be put in a product backlog. They should be ordered according to priorities and have complexity assessed. Team chooses user stories that will be handled in upcoming sprint.

Common mistakes

User stories are written for user (not for Product Owner, Developer or anyone else). Each user story corresponds to benefit to user. Read some valuable clues here.

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!





Best Android TDD tutorials

17 03 2012

There is not very much help on android Test Driven Development on the Internet. However I can recommend some tutorials listed below and desribed with details further in text. Most of examples covers the temperature converter which is surely very poor example of Android application… And definitely not the real life case of the killer app…

1. YouTube podcast just to relax and listen at the very beginning

2. Diego Torres lecture (the best so far)

3. Android Application Testing from Packt – worth giving a try if the two above are not enough

Reasons for my recommendations:

1. In order jus to listen as an introduction it is worth to spend 5 minutes on this YouTube podcast. There is no technical details mentioned, just basics and assumptions on TDD. Really good to listen to have some high – level information about what You are going to learn and use.

2. All the necessary basics are covered by Diego Torres lectures. Some theoretical introduction and practical examples of UI and logic testing. This is of course not everything that is needed to do TDD in Android, but it’s the best starting point. There is no details about ActivityUnitTestCase, which is also important to use in Android App testing.

3. Book requires much more time and concentration to read so it is recommended only if two above sorces are not enough (they aren’t in my case). Is it worth reading? As I heven’t found nothing better – it seems to be. It is not the best one. Still searching…

If there are more tutorials hidden on the Internet – please let me know! :)

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!





Improving team communication with Scrum

21 01 2012

Scrum is a framework (a set of rules) that can improve (software) creation process in area of project management. It introduces rules, the team has to follow. These rules makes sense for me, this is why I think this is worth sharing.
Way of thinking introduced by Scrum is valuable not only in IT but also in other areas, including everyday life (although it is not as simple as IT). Here is a Scrum Guide that is short and simple – worth reading.

Scrum uses short steps
The idea is to implement new functionalities and have potentially shippable product at the end of each step (working demo). Step should last no longer than 4 weeks and is called Sprint. Each Sprint aims to implement chosen functionalities listed in a Project Backlog – a list of tasks required in a project with priority and complexity for each of them.

Scrum is agile.
It means that it follows the Agile manifest and allows project team to dynamically change the scope of project according to the market and/or customer requirements. After each Sprint,the product backlog is adjusted, so the priorities or tasks can be changed. This is extremely important in R&Ds where reacting on a market changes is crucial.

Scrum improves communication.
Scrum requires a set of meetings to be scheduled. Before each Sprint there is a sprint planning meeting, that should last for about 8 hours for a 4 weeks long sprint. At the end or sprint the sprint summary meeting shall be held.
However the best part of scrum methodology are daily scrums – 15 minutes long meetings held everyday by a project team. Each of team member answers shortly three questions:
1. What he did yesterday?
2. What is he going to do today?
3. Are there any obstacles that interrupts his work?
Thanks to daily scrum, the whole team is aware of status and tasks in progress all the time, is able to react fast to remove obstacles as they appear and adjust working pace. And last, but not least – they can provide and receive feedback from other team members.

Planning sprint
How much the team can do during a sprint? It is assesed basing on historical sprints achievements. Amount of work (which relates to task complexity in a project backlog) is measured in a unitless unit :) Let’s say that the team handled to do 15 units during last sprint. Then probably it is able to do the same in future sprints.

How to assess task complexity?
By measuring the task You already know how complex is (for example 5 units) and comparing it to the new task. Then You have to say something like ‘this task is more complex, so its complexity would be 10 units’. Scrum is about basing on a history and experience.

Scrum roles
Are very well defined and described in a Scrum Guide. Thanks to separation of duties the Scrum can succeed – this is crucial.

Threads
You have to trust your team members. It is easy to fail if You believe that the scrum is introduced just to control You and check how do You perform. If You think so, then probably You don’t trust in Your team’s good will or Your team truly doesn’t have a good will, which is the worse case.

Myths
‘introducing Scrum requires fighting with company’s resistance’. I don’t believe it :) why the company would resist? Just be optimistic.

Scrum is most effective only when fully implemented. However taking only the best parts from it is also an improvement. In my opinion such parts are Daily Scrums and way the task complexity is assessed. Best part of scrum is fostering communication and fast reaction on market changes. These makes it surely worth trying.

Did I help you?
I manage this blog and share my knowledge for free sacrificing my time. If you appreciate it and find this information helpful, please consider making a donation in order to keep this page alive and improve quality

Donate Button with Credit Cards

Thank You!








%d bloggers like this: