• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
  • Tim Holloway
  • Carey Brown
  • salvin francis

A personal agile-like method: request for some feedback

Posts: 5
Scala Netbeans IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I often fail to correctly estimate my deadlines during the programming, which leads to poorly organized workflow.
Therefore, today I have developed an algorithm of my development process I'm going to use.
It is influenced heavily by the Agile methodology, but since I’m not working in a team, its impossible for me to apply it. Nor do I have any time or desire to learn precisely about Agile, so I have just borrowed their philosophy.

If you have time, I would appreciate any feedback on possible drawbacks and improvements to it, since I don't want to screw up badly due to stupid planning mistakes

The main aims of the process:
  • Quick result delivery. Every week (or so) I must have something to show to the client.
  • Learning-orientation. I should take into account that I’ll need to learn lots of things during the practice by itself.
  • Efficiency and simplicity. Spend as few time and effort as possible (but not fewer!)

  • The process itself involves the development by iterations. One iteration is a week or so in length.
    Before the project starts, I outline all the “strategic” aspects about it: its “global” design, possible directions we might need to scale at, possible changes that could be requested. I also learn everything needed to begin the project (say, the domain of the application).
    Then, the actual iterations start. One iteration is as follows:
  • At the beginning of an iteration, a goal that needs to be done is established. The goal, upon achievement, should lead to a product that already works. Of course, its functionality is limited, but I’m still able to present it to the client.
  • After the goal estimation, there’s the learning phase. I select the tools I’ll be using according to a certain criteria (they must be well documented, supported by the community etc) and learn the things about them that are necessary to start.
    This phase is optional (I may already know everything I need) and its length is at most a half of the iteration.
  • After the learning phase, there’s the doing phase. First, I plan the design of the piece of the functionality I want to develop, then I write the specifications for it (possibly in the form of tests in a BDD style). Then I develop the actual piece of software. Here, I take into account possible fails due to the usage of the new tools (that I've just learned). So if I'm using any new tool, I'll estimate the task to be 3x times as time-consuming. And If I'm not, I'll estimate it 2x as time-consuming.

  • During the iterations, optimization of the work is used heavily:
  • Everything that can be automated, must be automated.
  • Especial attention to the tests
  • All more-or-less meaningful ideas should be written down - because this way they are more clear
  • The text from (3) should “work”: if it is a specification, it must be an executable test; if it is just an idea, you must show it to someone to evaluate
  • No multitasking
  • Other optimization ideas are constantly looked for and adopted on the way.

  • What do you think about such a process?
    Thank you for your time
    Posts: 4671
    IntelliJ IDE Clojure Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Sounds like a pretty familiar "agile" style way of working. Nothing particularly new here. That isn't a criticism.

    We each have our own way of organising ourselves when working in teams or alone. The best way for you to find out if your process works is to try it out for yourself.
    Today you are you, that is turer than true. There is no one alive who is youer than you! - Seuss. Tiny ad:
    create, convert, edit or print DOC and DOCX in Java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!