For my experience, that is more than twenty years in IT, and since beginning did try do some sort of Agile (beginning in 1991), when the project wasn’t big and one mix with Waterfall when with Enterprise solutions. Today by experience I’d know that is quite possible develop Enterprise solutions using Agile though a lot of things has changes since when. Especially with IDEs that 15-20 years ago where nearly inexistent, my preferred editor was the NE the good and old Norton Editor in DOS and into Unix and Xenix (if you do remember this last one, you should be considered a Dinosaur from IT, just like me!).
Must have more items to thing about it, though those ones for me are like the basics ones and will explain each one here. I know that some people may will say, “Aaaahhhh the number one isn’t true, the number X isn’t too, or even that this guy doesn’t understand about Agile”, however the truth is that I’d never have delivered one project with delays and the conclusion you should be take for yourself.
One thing for sure I’m not. I’m note that guy who want use EJB X, or Spring and bloat the system with patterns when isn’t needed. I like to talk technical language, though when talking with Juniors, is better you do use some examples with some sort of analogy that they will understand quite better. Be technical is good for who can understand, for those ones that are just starting, is one little bit scaring you be too technical. I think that they should have time to get there, and the first thing in one project that they need to know is, ‘know’ what they have to implement, and that they have one team leader that will be a team leader in fact. Teaching and explaining things when they need, they must feel that you are like a friend, that they can ask you anything about the project, language, patterns or correlated things without fear to be ridiculous. Doing this for sure they will have one better production and will close the gap about the system and those technologies involved.
You for sure should manage the code creation and have some patterns or conventions about it, and let your team familiarized with it as soon as the project starts. Comments exist and make then use it, explanations are never enough. This will help a lot when someone have to enhance or update the system.
If enhancing/updating or even maintaining one old system, to just create new classes and methods when strictly necessary, even that the code is the real bad quality. If you have time to re-write it, cool do it, if not, keep with the strict that is delivery the system working well. Doesn’t creating unnecessary classes and methods believe or not make the production go fast and doesn’t change the system structure, even being a bas one. Because, may be the next one to ‘touch’ in the system, will be the creator or someone that has to read follow all steps that you did to understand it and if you starting changing it, for sure the system will become a Frankstein and for sure will be harder to maintain.
One thing that I always put as top priorities are those two ROI and Quality, that means delivery good code and working of course, and that match with what the client expect and that has paid for.
Now for you that doesn’t have enough experience making run one Agile project I do enumerated a few things that should help you.
1 . Just juniors will never able to work with/implement it.
Nothing against them though if you are the only Senior in the project, be ready to do a lot of extra hours and have to re-write a lot of code, not all juniors are equals, but most of then take long time to delivery something. So if you want make it go right since beginning mix at least one rate of 1 to 1, that means one with experience and one junior. If you can’t do that, don’t put the project and yourself in risk, go for some sort of mix, or something that is there before, keep one backup that can help you when you do need at most. Most of juniors must be guided, due this they love RUP and any Waterfall, because take off their hands the responsibility.
2 . Only years and having worked in several projects will give you the expertise to make run one successful Agile project, the same way one senior struts developer will never be a good system architect.
This means that rush to be something that you are not ready to be, will just make you frustrated, saying that Agile does not work, like I’d saw a lot in several places on internet. If you don’t have any expertise with it, try create pilot projects, easy things to implement and try keep some sort of back up in whatever methodology was there before. With time you will be able to start spotting the issues and the potentials source of problems and delivery have solutions for it. Usually even reading a lot you will struggle in your first projects. If at anytime you don’t feel secure, raise the flag and call for help, it’s better you be honest with yourself and with is paying you than wast time, money and probably lost your job. This also means that if someone ask you something that you don’t know, keep the head up and say that you will research about it and soon will let he/she know about it.
3 . The team must have the 'I can do it' attitude and be a experienced and organized team (this is one of the most hard to put together).
This is a must in Agile projects, if any person of your team is showing you be one little bit lazy with lack of this attitude, talk with him a few times, though don’t expend too much time if you feel that he/she doesn’t want to change, take he/she off from the project fast. You can see this for the meetings, usually in the beginning of the project I do those very short meeting every day, after some time when they are familiarized with each other, I do go for one maximum of 3 meeting weekly, though most of projects one or two weekly are more than enough.
4 . Just follow what the book does not help if you don't have a good experience.
I think that doesn’t need explain too much this right. If you don’t have enough experience and just try follow one book, you are putting a lot of things in risk, and one these include you, that depending of where you are trying implement it, you can kill your career before even started.
5 . Does not exist one standard way to make run Agile projects though just conventions, good practices, nor formula.
As do wrote here before, your experience and being successful in find the potential problems that will make you run with success one Agile project.
6 . Use TDD with average team, will not help, you'll need a good team.
Try follow it, if not TDD, test a lot your system in all possible ways, fail gracefully if inevitable, pay a lot attention with those nulls pointer exceptions, test those business rules up to exhaustion,don’t be lazy and try ask for some team mate test your code, when you do test other code. Check the data’s, create Unit tests, for everything that you had created and if possible one that will perform all tasks one full process. Try keep more realistic possible those data’s that will help you spot any issue easier than with auto generated data’s. After has tested for data’s do loading test and performance tests. Those ones will give you one good idea of how many connections your system can handle, the maximum before fail, and memory used.
7 . Need have access to the people that have the knowledge about what is being developed, no access means lack of information and fail.
Without access to those ones that have the knowledge about what is being developed is waste time with Agile, don’t do it, because you will create one system that just get close, or not of what your client need and with quite less documentation, that means if he/she want make those changes to make the system match with what they expect, will be quite hard, and even you not being there anymore they will blame you for sure. My opinion is… “Always leave leaving the door open for you”. No ones can have the next day as granted right!
8 . At last one person of your team must have expertise in all project phases, like from make the interviews up to deploy in production environment, and know most of configurations for the environment to be used, just code does not help.
This is very important, if you don’t have this expertise don’t do it or find someone that can really help you when you need. Remember Murphy’s Law… “If something might go wrong… it will go wrong”, and probably this will happen when you less expected.
Because this, isn’t so easy implement agile in medium to big projects and it's expensive for the company have several good guys working with it, and means that after project done, they will need keep a few just to enhance the system after, or to do the maintenance.
Before start one project you should know at least these points before to decide for what methodology you should go.
Of course there are successful histories in all methodologies, though doesn't mean that it will work all the time, and one very important tip for you. If you fail, please keep the head in place, keep calm, and do the analysis of what went wrong and why, to do not repeat it next time.
These are a few tips that I’d use very often and hope that it help you when you’d need it.
No comments:
Post a Comment