Lubo Drobny

CODE is clean self-documenting communicates the programmer's intentions well designed/structured  ERRORS are handled consistent and transparent way LOGS are appropriate on appropriate level CODE ANALYZER reports no new issues reports satisfactory coverage CODE REVIEW is done CI is green = code is committed to appropriate branches + builds are OK + all unit tests are passing + all integration tests are passing CD is green = build are integrated & deployed OK at staging environments + all regression tests are passing QA initial tests are OK do not report any defects test automation is planned if makes sense PO accepted the story

When is user story ready for a sprint? I think that team should prepare in advance these points: Title - short summary of the story  PO: business requirements (schematic, not novel, priority order) = what & why & when to do? UI: wire-frames or sketches of new UI/UX and flows = how to do it on UI? Dev: architecture & design impact (dependencies, cfg, DB changes, migration, new libs ...) + suggested technical solution = how to solve it on backed and code it? what is impacted? could solution generate technical debt? are we aware of taking some technical short-cuts? CI & devOps impact (Jenkins, VMs, Sonar, Vagrant, Ansible ...) do we need change on CI/CD or envs? QA: acceptance criteria (could be part of DoD) + environments definition to validate PO: clear and understandable DoD (bullets) - fixed for a sprint duration Estimation in story points Links to discoveries (wiki page) or related stories or bugs Fix versions: branches where to commit or merge...

Implementation of Agile (SCRUM) in company requires setup of few meetings to achieve benefits of this methodology. It could be very different across various companies and this is my perspective after 7 years experience with Agile. Daily stand-up goal: build team awareness about the progress of each story in the sprint, detect impediments and identify potential actions to remove them; reassess priorities to be sure that we are on right road with focus on ticket flow who: team moderator: SM length: 15 minutes, every day - it must be the heart-beat of the team, everybody should contribute and understands that this makes sense - the same time and place every day, - quick as possible: 'pam-pam-pam' - sprint board (backlog and story we talking about) must be visible for everybody - only one attendee talk in one time; SM should kill side talks - team members should pick tickets voluntary (self organization) - SM is discussing stories from top priority to lower ones and ...

How many devops do you need to change light-bulb? - None. It is one shot manual job, they do not want to do it. How many java developers do you need to change light-bulb? - 100. One is doing a job, rest are just dependencies. How many consultants do you need to change light-bulb? - Well, It depends ... IQ is not lower by aging - it is just slower.

Would you like to start with Scrum in your team? These are few hints from my experience how to make this process smooth, iterative & incremental: get commitment from the management & team define reason: why would you like to do Scrum? what problems it should solve for you? start with simple Kanban in one team: it is easier, you just need to manage 3 lists: backlog (todo), work in progress and done  focus on right priorities of backlog - person who defines the priorities will be 'product owner' setup quick way how to track work in progress and indicate 'impediments' -> daily stand-up; max 15 minutes meeting every day - moderator of the meeting will be 'scrum master', he will be also responsible for solving the 'impediments' focus on dependencies between the tasks to avoid 'impediments' start to put 'discoveries' into the backlog to pre-analyze tasks; discoveries should be done by architect or analyst what is the busi...

When I was developing my practice project for high-school graduation exam I did a mistake 15 minutes before end of dedicated time. I somehow deleted my source code. It was horrible and I knew that I did not have any time to rewrite it from a scratch. Fortunately I realized that my source code editor was automatically doing backups and that saved me. I was lucky that time and I learnt my lesson that software factory cannot be chaos but it should be CHAOS: C ontinues  H elpful  A utomated  O rganized and  S mart. And I can tell that after 21 years I use more sophisticated software factory in my team which follows that principle: IDE for development:  allows fast writing/debugging/profiling of the code, documentation and configuration; the project setup must be generic so developers should be able to use any IDE without project setup change: Eclipse Source code repository:  provides effective & safe storing of the code, documentation and confi...

Such a simple question: is it done? And these are very common answers: Yes, but I need to finish documentation. Yes, code is ready, however I have to add some junits. Yes, but I need to fix some bug I have found this morning. ... Admit that something is not done looks hard for us and it is very common that we are trying to make things look better. Therefore we have started using of Done-Done, which simply means that it is really done and there is no further work to do on the subject. In other words I can confirm that I do not need to spend any effort on the task. So, is it this post done? Yes, but I need to check spelling...