Tag Info

New answers tagged

0

Trello is good as a kind of software version of a Kanban board, it can be helpful for single person projects but you get most of the benefit from it when you have a team of developers, managers, etc. working on a single project. Working in a profession context I would say even on your own you need to be using at the very least: Source control I would ...


1

There have been plenty of proposals for improving the programming paradigm. The hottest buzzwords now seem to be agile programming and object-oriented. Or are they? Both have faded substantially compared to what they were just five years ago. You can be fairly confident that whatever methodology put in place is trying to accomplish the same end result: ...


2

One way of looking at velocity is to think of it as "the amount of work that can be completed in a given amount of time". Assuming that fixing technical debt is actual work, it should be counted. You must remember that velocity is just a tool to help you work better. If adding technical debt to you velocity helps you, do it. If it doesn't, don't. The only ...


4

Velocity is defined as "number of units of work completed in a certain interval". To implement a unit of work, you typically have an existing part of software and add some new code and/or change some existing code. When the existing part of software contains a lot of technical debt, and you have to deal with it to implement a change, one would expect to need ...


6

A Direct Answer Other answers make good 'meta-points' about adopting better practices but, just to give you some directly relevant guidance, here's a rough ordering of the best practices I'd suggest your team (or any team) adopt (first): Source control Issue tracking (project and task management) Automated builds1 Automated deployments 1 A very much ...


9

Source control. You did not mention it, hopefully because it's already in place, but, in case it's not, start there. Source control has the biggest bang-for-buck, except in rare circunstances pathologically in need of something else. And you can start alone if no one initially buys in.


4

I'm going to go against the grain and say: find a new job after spending some time at this one to build your resume a little. Aim for a year or so. Although many things are "buzzwords," issues like a complete lack of unit testing are intractable for a single developer, and chances are that if the programmers working there have no desire for testing, you'll ...


6

Find a flaw. Fix a flaw. Show the fix. Let's take normalisation* first. And indeed, I'd suggest you take it first, because lack of normalisation is likely to result in actual buggy data that couldn't exist otherwise, whereas the rest are cases where best-practice could likely help but it's harder to say "Bug A was caused by not following policy X". If you ...


16

I hope you have not presented the issues to your coworkers as you did to us in your post. THAT would be professional suicide. The first issue is that you are trying to teach technologies and methods that even you do not have experience with to a group of programmers that, maybe are a little outdated, but get the job "done". The possibilities of that ...


12

You should start with the book Working Effectively with Legacy Code by Michael Feathers. From the book's introduction, "It's about taking a tangled, opaque, convoluted system and slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system." He mostly starts with automated testing, so that you can ...


5

Look around the team that you're a part of. Can you see any evidence that test driven development or database normalization will improve the quality of the software you're writing or make people more productive? Have you tried speaking to one of the development supervisors about it, or the head of development? A really informal chat would be a good start. ...


38

Many companies are stuck like this; you might even be surprised to find that some of your developer colleagues are self-taught and became developers with no formal background whatsoever. These developers are often better at their jobs, since they will be the ones that are driven to learn new skills and succeed instead of simply doing the job. Unfortunately ...


71

Java? Modern?! You've failed at the first hurdle. If you want to be truly modern and avoid "professional suicide" then you must be writing Rust code. Of course, next week, it'll all change and you'll have to learn something even newer to keep up! Or, you could accept that no amount of buzzword technologies or methodologies or frameworks or any other du ...


159

It sounds to me like you are putting the cart before the horse. What is the major problem your team is facing and which technologies would help fix it? For example, if there are lots of bugs, particularly regression-type bugs, then unit testing may be a starting point. If your team is lacking time, perhaps a framework may help (medium to long term). If ...


3

The word "research" is indeed being overused in agile. The word can be broken down into: learning, or reading documentation, or learning-from-trying. This is just "learning". This is not meant to belittle the time needed for learning. It can take a long time, e.g. weeks to months, but the learning process should be considered and included into the time ...


2

Ken Rubin answered this at a training workshop for us. His advice was to either use a research spike or to use a story task for the training. In your case, you know what product that you are using, and you just need to account for the learning curve. I would recommend a learning task. I remember during the class someone asked if we could just create a story ...


1

As a consultant, my teams similarly have members with specializations. We need to achieve high quality as quickly as possible in order to best meet our clients needs and our organization's profit margins. It is entirely valid to have team members that are specialized for optimum performance. HOWEVER: This does not mean cross-training should not occur. We ...


0

Silos are bad for a number of reasons. Bus factor was already mentioned. When you have narrow specialization you pay the price of hand off and integration as well. I like the idea of "not doing anything" for you as a manager - that's the wise advice, however, there things you still need to pay attention to. Priority. This seems to almost always escape ...


0

First, I think that the use of the term "bug" is a bit off. There are some questions here on Programmers about this (1, 2, 3). Generally, the word "bug" refers to a defect in code. The software does not do what we expect - it crashes, it produces incorrect results, or something along those lines. I prefer to use the word "defect", and this other answer ...


1

My experience; Although there is a 'bug/defect' object in RTC (the collaboration tool used to capture user-stories in my workplace) for the most part my associates tag everything as a general 'task', regardless of whether it can be considered a bug (or group of bugs) or a non-bug task. We do have a Trac-style tool to keep track of the discovery and ...


0

Depending on the level of specialization you might consider some type of implementation of pair-programming. If somebody is under-utilized during a sprint, don't worry about velocity, and have them pair up with somebody who is being utilized in an area of expertise that they aren't familiar with. The obvious benefit of this being that members of your team ...


2

The important thing is to develop an open, transparent and trusting relationship with the client. The customer needs to understand what your challenges - and cost - are to work in the manner you are being forced to work in. At the same time, you need to understand why is it that the client cannot deliver in a predictable manner. Once there is appreciation ...


6

Where I work, we have a lot of silos of knowledge. Not good. The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it. Except of course that it leads to this sort of scenario or the ever ...


4

To some extent, there's nothing you can do if your teams are that specialized. And if you're asking from the viewpoint of a manager, there's nothing you should do, either. This is a problem for the team itself to solve. A point to remember is that scrum tries to optimize the team, not the individual. It's perfectly fine (from a scrum perspective) for an ...


4

Scrum doesn't really care about the type. A Feature, story, bug, thing, item, use-case... Anything can live on the product backlog. So it doesn't really matter what you call them. The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be ...


2

Well... this happens all the time, and going agile is not going to fix the issue, rather you could get the web service definitions / contracts finalized. At this point you could actually start to build your system with mocking of the client web service using some tool like SOAPUI. Once the customer service is up and running, you can actually test it. Of ...


0

80% of my team is remote, so our normal communication is remote. For this situation I find that an electronic board always seems better than a physical board for us. In fact I don't now how we would effectively do a physical board (I have done plenty of physical boards in the past when most people are also physically present). One camera that all of us ...


0

Use both. But you need the physical board first. The electronic system should be for detailed docs and attachments you want to associate with a task. Not managing the process. I would say the physical board is best for running the scrum, the electronic board is best for running the backlog


0

I don't think an electronic board is a necessity for distributed teams. There are techniques like having pairing people up into buddys across locations which can help the teams feel more connected. That is not to say that a virtual story board is never the correct solution. Having both is sometimes valid as well. As always, it depends... If you do ...


3

Who is the audience for the burndown chart? The second method, where you take credit after the completion of a story, is more in line with the ideas behind Scrum. There are several questions here on Programmers about dealing with incomplete stories (1, 2, 3, 4, and others). A story, not a task, represents something of value to the user. If you take a step ...


0

Personally i prefer the first way. It gives you a better sense of progress and the "work" done. Also many times the division into "User stories" is somewhat arbitrary. I prefer to see how much work was scheduled into the current sprint and how much was actually done. But it doesn't matter. Each team should choose what suites them best. That's one of the ...


0

I think what you are looking for is extreme programming. Most of the times if we are unable to complete the work in a given release The triangle of time / scope / cost allows you to increase one if you reduce another, not just force all three to be better, this results in the hidden fourth variable taking a hit i.e. quality. additional teams are ...


5

Is this acceptable in agile scrum? Define "acceptable". In some environments, it's fine. In most, it is prohibitively problematic. That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to ...



Top 50 recent answers are included