2010 gallery finished

I’ve published all photographs belonging to the 2010 gallery. This basically contains the best images I’ve taken in the year 2010. This is my third year digital photography and post-processing, and in my opinion is much better than the previous one, but don’t spare any comments, I’d appreciate it…

Digital photography and processing specialist (v2)

Just a week ago I wrote about taking a specialization course in digital photography and processing, and how I was excited to attend it. Well today, I’m just a bit less excited, reason: I can’t publish my photographs taken during the course.

Unfortunately, due to rules of the course I’m not able to publish my own photographs taken during this course, but on the other hand they are able to publish my photographs for the purpose of marketing their course and college.

Not unexpected, but not fair at all.

Don’t get me wrong, I still love this course, my colleagues, and I’m very satisfied by the experience and the knowledge I’m gaining. I personally don’t care at all if they will be using my photos for their marketing or such purposes, as long as I can use them for my…

Also I’ve removed the SDFO 2011 project from the projects list for obvious reasons.

Digital photography and processing specialist

Well, I hope to become one, anyway. I’ve started a specialization course a week ago, and every day I go/work/listen, I learn more and more. I’ve also created a project, titled SDFO 2011, where I’ll soon be posting photographs taken while attending the classes and workshops.

Unfortunately, due to rules of the course I’m not able to publish my own photographs taken during this course…

SCRUM – putting a value on features, and other

I already wrote how overjoyed I was about using SCRUM, and the joy and the enthusiasm just keeps growing. After a few iterations on my latest (Srum-runned project), I’ve discovered a few things different than my previous work methods.

  • importance on putting a value on features
  • breaking down “complicated” features to more simple ones
  • the obvious scope increase after some “clarifications”

Putting a value on features

All features are not all as hard and as complicated as others, some are easier, and other are harder. Some are “unknown”, and other known, so estimations are practically impossible to define unless we break up all tasks to simple features. So burnup/burndown charts of finished features finally make sense. Usually if the tasks are listed and progress is shown in a burnup/burndown chart, the actual work done and work remaining on the chart have nothing to do with the actual progress, usually due to “not clarified” or “misunderstood” client requests and features that have not yet been started.

Breaking down complicated features to more simple ones

I’ve read a “rule” for estimations is never to estimate anything as a single task if the estimate is longer than 2 days. I absolutely agree with this. I’ve seen features estimated to take 20 days or 50 days. I consider this estimations to be lazy and risky, and this is often done to the lack of specifications or clear client requests. Cure for this would be to (even if you do not have clear client requests or specifications) write the list of features as you understood, estimate them and offer that those features will “cost” that many days/points/money. This brings another issue to this whole story.

Obvious scope increase after “clarifications”

Sure, I could misunderstand the client request, or specification, but I did promise to finish the estimated tasks in that period at that price, and if that’s wrong, it’s my problem, but if the scope increases after “clarifications”, it should be a normal thing to:

  • increase the period in which the final product will be finished
  • increase the price
  • if this clarified feature must be finished in the current iteration, the client can:
    • select a feature (weighing same amount of points) that will be excluded from this iteration
    • understand that it cannot be done, finally understanding the importance of clear specifications we’re all talking about

Finally, clients are not stupid or disrespectful of our work as we often feel. Working with SCRUM has helped me demystify the whole request/specification/estimate/development process. Earning me reduced pressure, more respect and trust from the client, and more pleasure in working on the project for both of us.