Tag Info

Hot answers tagged

37

In my 20 years of experience, it is better to have code ownership rotate responsibilities amongst designers or at least have a pair of owners. Single feature ownership has the following issues, several of which you mentioned: it tends to pigeon hole designers and limit their growth opportunities it puts all the eggs in one basket so if someone is hit by a ...


13

Feature ownership is inevitable, and done well can be a good thing. It help builds mastery and allows autonomy - two of the generally recognized pillars of engagement. It makes it clear who has the accountability for that code, and aids in delegation, communication, and otherwise getting shit done. But you're not talking about that. You're talking about ...


5

Firstly, a ratio of 10:2 is bad. From experience, a ratio of 3:1 or 4:1 developers to testers works well. You'll likely need at least one more tester therefore, otherwise the testing backlog will grow and either never get cleared, or you're cut corners somewhere. If you test tasks in the next sprint, you are implementing mini-waterfall or "scrumfall" as you ...


5

This is fairly common, if not typical. To answer what are several questions: What should be the right approach to track activities in such scenarios? Will features get done without QA but with defects? How can I track the efforts seamlessly? Should testing be part of "Done Definition"? What are the pitfalls if it is not? I would take an overall ...


4

Yes, testing absolutely should be part of the definition of "Done". Without question. From a purely agile standpoint, the right approach is for everyone on the team to contribute toward writing tests. The tester would be the one coordinating the effort, but it is the responsibility of the entire team to make sure the software is properly tested.


1

While the question, as posed, has broad scope, the core issues seem to be: ...Scrum assumes that there is no 'requirements freeze'... ...embedded system due to tight coupling with hardware need upfront specification... Scrum aims to produce high quality increments of a deliverable solution. It does not aim to minimise re-work or minimize time to ...


1

Does the software team has any influence on the hardware specs? Or is it purely the other way around (hardware team dictates low-level software interface)? In the latter case, a HAL (hardware abstraction layer) person must sit with hardware team to write the low-level software interface; GUI team can work at their own pace, possibly using Scrum or any ...


1

I don't have personal direct experience in embedded systems - but I do understand waterfall and agile and the differences between the two, as I am sure you do too. I have also discussed this issue - of applying Agile in industries such as embedded software development, semiconductor design/ development, etc. with friends who work in those industries - so ...


1

Scrum is not concerned with requirements freezing or not. Scrum works equally well if you start with 100 stories in your backlog that never change, or 5 stories with more being added/changed all the time. Scrum is supposed to be an iterative process and it requires a totally different mindset than more traditional waterfall models. Technically with Scrum ...


1

One of the main principals of Agile Development is customer being part of the team. It takes both parties to adopt Agile, so: STEP 1 Get the customer on your side before proceeding. Agile is not about your team, it's about collaboration between YOUR TEAM and CUSTOMER. Secondly, Agile is a methodology, it's not perfect, it's not a panacea, it's merely ...


1

If you are faced with the work needing to be re-done, you re-do it. Re-doing the implementation of a product backlog item does not necessarily require any user story to be re-written. The motivation to re-do the implementation may not have had anything to do with a change in the user story. Re-doing some implementation also does not necessarily require a ...



Only top voted, non community-wiki answers of a minimum length are eligible