Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Where I work, we have small teams of 2 - 5 people. As a dev lead, what are some things that you've implemented which makes your team stand out from the others? Meaning, it makes the others teams say, "that's cool" or "why didn't we think of that". Just some thinking out of the box that made your team extremely efficient.
Automated unit testing and an automated build system (like CruiseControl)
Hawaiian shirt day
Why compete with other teams, the company goal should be a common one.
We roughly have two teams (one working on the 'off the shelf' product and one working for tailor made solutions). But we are used to help each other alot. And in my opinion that is the way it should be.
First and foremost -- we get things done on time that meet the done criteria. That's the best thing to do, in my opinion :)
We're currently doing unit and functional test automated with CC.NET. QA loves us for it. But, I'm looking for things such as that.
Do in-company presentations on general topics that the other teams might be interested in, but are not directly related to their work (otherwise they are supposed to know more than you about those issues).
Volunteer to do inside projects that benefit everyone. (e.g. Stylecop introduction into the codebase, geek lunch every week, and similar)
We standardize only the build process. We don't make our SKILLED developers use skills that are dictated to them. We let them code however they want, with an editor and command line, with an IDE, with a hammer and chisel if they want. They are only constrained by the build process. Everyone is subject to the same build, in our case an ant script.
Developers like and perform in our group because of the freedom. Other groups who constrain their developers can't understand how we do it.
Write good code?
Edit: Of course this is totally wrong, the actual answer should be:
Write bad code.
I dont agree that its a company Goal. Because finally each person is looking for his or her own self.
Its important for a team to stand out. Reason being manyfold.
To stand out the team must be able to present themselves and the team lead has to take the responsibility. Its not enough to develop good code these days but also to be able to present it
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I came to a successful project with 4 years old, it is already in the production.
The problem is that, the project is not documented anymore, it depends on 2 senior developers only, they know the system, they test, they handle change of requests..
I need to know what is the best practice, or what are the main steps that I have to do in order to document all the modules starting from high level design through component analysis & design, code comments, till the configuration management.
The traditional project management processes don't give me a clear idea of how to take the control back of a an old project.
Thanks.
Senior developers will easilly get bothered if you make them write docummentation all day long so you may lose them at the end.
I would hire a technical writer / junior developer if I were you and give him or her this as a first task. I would also make him or her work closelly with the senior guys, without taking too much from their time (like aggregating questions and have a one hour session dailly or something like that).
It will probably hurt in the beginning but if properly executed should prove a good choice at the end.
Note: The level of cooperation between your senior guys and the new guy that will be doing the documentation may vary depending on some internal "political" things like if the developers feel threatened by the fact that you are trying to make them less critical to the project, how overwhealming the new guy / gal is to them and so on. So answer those questions before going for it.
Once again - it is my personal opinion on the given topic and its success will definatelly depend on various factors. So you should decide if it is a good way to go or not.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I understand that it is better to discover requirements through iterative approaches in Agile, however I often hear of people rejecting projects on the basis that they are given up-front requirements.
Why is this the case? Why can't up-front requirements just be taken as-is, e.g. just added to a product backlog and then prioritized and implemented?
There's nothing wrong with up-front requirements. In fact it helps to know where you're heading before you set sail!
Agile is a lot about being able to be adaptable, so that should requirements change you're not locked into something you don't want.
The kind of up front requirements that would cause a developer to think twice about a project, would be those which indicate that the client are likely to be a nightmare to work with:
an obsession with one particular, unsuitable technology or presentation style
insisting on 'security' with glaringly obvious vulnerabilities
In an agile project, it's good to show a client the current state of the partially working system at an early stage, and get feedback, using this information to help design the subsequent parts of the system. If a client is too fixed on ideas of the final product then they might not be able to give useful feedback at this stage, and the final product may be not as good as it could have been.
This something that can be quite problematic with Agile. Some teams will use it as an excuse to not have a plan as they want to be 'adaptable'. Requirements can help to focus on the software architecture, which is something else that is not always given much focus in some Agile teams. It is points like these that lead me to believe that Agile should just be principles but not a methodology. Digital Animal wrote an interesting article about how Agile can be used in such a way that it stops being effective. For some teams, it is better to learn from what is great about Agile and use it to build a methodology that works for them. http://digitalanimal.com/blog/slaying-the-agile-dragon-the-game-of-thrones-methodology/?AT=CZcb6f
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
there are a lot of articles/books etc about PM for medium or big projects. All articles which I found describes how to manage a project with at least few people involved.
In my case that is totally different, so this is my specific case:
I have a small team (4-6 developers) and we do small short-term projects. Usually one or sometimes two persons per project. Project's lifetime is about 1-2 month in general (but can be 6 months in case of customer related issues). All projects are customer related, quite often there are some breaks in the projects because of lack documentation from customer or lack of hardware etc, so one person quite often handle 2-3 projects with different priorities at the time.
My question is: can any "popular" modern methodology be tailored to suite this types of tasks? What could you recommend (methodology/pm tools).
May be someone can give a link to an article about this type of software pm?
Cheers!
In my opinion, any project management tool could be adapted to your team and you should first choose what type of project management methodology you want to follow. Personally i think Kanban could be a good fit as there are no specific deadlines or cut off for projects, just tasks. It also allows you to prioritize tasks and carry out several projects at once.
This is the methodology we use and we do have similar uncertainties when it comes to the length of the projects. The tool we have been using is Eylean, it allows us to follow the methodology and have the updated status of the tasks at all times.
I'm a fan of Crystal Clear, which is Cockburn's method focused on smaller team work. http://alistair.cockburn.us/Crystal+Clear+distilled
Any methodology can be scaled, provided you don't fall for the dogma and consider it to be the "Best" or "Only" way, or that you need to follow all the principles completely.
That said, I'm a big fan of Extreme Programming myself.
However, in practice, on our projects, we "officially " use a Waterfall methodology, but within each phase our methods are more in line with Agile methodologies, and our official stance is that each PM will use whatever tools he or she needs, so long as the project is moving along, we are meeting our deadlines, and most importantly, the customer is getting what they need when they expect it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Which is a good Project Managment Method to Develop a Website?
XP? The Waterfall Model?
Anything but waterfall....
But keep in mind that saying you are agile and being really agile are two different things.
For agile to really work over an extended period one has to also be doing several technical things well.
http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx
http://davybrion.com/blog/2010/02/youll-never-get-sustainable-progress-for-free/
Agile/XP would be best.
Waterfall would be the worst choice in my opinion.
It depends on who the customer is. If you are your own customer, then definately Agile.
If your aren't your own customer then you will have to negotiate with your customer on your development method. If your customer wants a fixed bid project and a hard deadline, then you will be best served by the waterfall method.
If your customer is willing to be an active participant in the development process and doesn't have a hard deadline and fixed budget then you could do Agile/XP.
It always depends on the type of the website you are developing, how many developers you got, what is the timeline, expectation for delivery time. But definitely Agile or prototype-iterative method will work fine for website development. To complete the development in different phases, and enhancing in the chucks, as an when identifying the strong and weak areas.
As well you can check the factors like target audience, maximum used sectors of the site and prioritize the development of those pieces first.
Always consider to go with standard framework, that will make life easier in long run with the future developments.
I find that waterfall fits some web site projects fairly well. Get the requirements, wireframe a design, do the graphic design, convert the graphic designs to HTML/CSS/JS, then fill out the content of the site. Client signs off at each stage. If the site is large the last stage ("fill out content") is probably more work than all the preceding ones and you'll want to use iterative methodologies for it, not waterfall.
Waterfall tends to not fit web applications very well. Those are software, treat them as such.
Use waterfall! But:
Set duration of the project to 1 month.
Then repeat this project until customer is happy!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am the sole software developer in a company and I answer directly to the owner of the company. We also use the services of an outside developer. The owner isn't a developer but 'wrote software in qbasic' many years ago. He has reasonable abilities to spec projects. The outside developer doesn't answer directly to me, and my boss is really a micro-manager and wants to keep it that way.
The outside developer likes to use layers of abstraction (frameworks and wrapper classes), but has implemented them when I was stuck on months-long projects. When I return, the boss now wonders why it is so time consuming for me to do maintenance on projects (including one that I initial wrote from scratch).
I'm unhappy reverse engineering his code and I'm having trouble articulating the fact that I must learn a complete different interface from code that looks alot different than what I wrote in the first place. At the same time, the outside developer looks like a hero. Suggestions on how to articulate this to a technical/yet non-technical boss and how to put a lid on this happening in the future?
At the risk of sounding patronising, be careful that it is not just your perception of what you think your boss is thinking, which may be quite far from the reality.
Your boss may be wanting you to explain the situation not because he does not trust you, doubts your competency, or wishes to belittle you; but rather to understand where the difficulties are so that he can make an informed business decision on whether it is worth you reverse engineering this code- or perhaps be better to leave it as is and move on, on different aspects of the project.
Being honest and explaining that you have limited experience with these frameworks/wrapper classes may "buy" you time to not only learn these frameworks (which will hopefully benefit you greatly in the future), but may also mean that you are appearing to embracing and extend upon the other developers code, which is good team spirit if nothing else.
At very least, ask your boss to ask you if there are aspects of your explanation that he needs further clarification on. Keeping nice clear lines of communication will help everybody move forward faster.
Hope that helps!
Gav
I don't know if you can get away with this with your boss.. I could with mine, but not everyone can.
First, this has to be done respectfully, and the suggestion I'm about to give should be within the scope of a longer discussion. When it comes to the point of having to explain the difficulty of working with this developer's code...
Type up a paragraph in English, have someone type up the same sentence in some language your boss does not know. (Chinese, Spanish, Klingon, whatever.) Give your boss a (language) - to - English dictionary and explain that while you are technically capable of translating this outside developer's code into something useful, it takes time, just like it would take him time to translate from (language) to English using the dictionary.
Perhaps this would work best in the context of trying to establish standards for working with outside agents and potential new hires.