Other Anyone know an small App one developer paradigm without overhead?

[Alejandro Moyano]

Hi! Im alex i was working on 2 projects, FlaskRocket2 (b4X-python framework) and RadicalTicket an app to sell thickets, both using Scrum, the first one focused on comunity driver features took sense, the second developed on a team took too but after covid-2 we must drop it.

Now i'm started to work with a teacher (my test user) on an app to make easier remote async classes, without the pain of moodle or any LMS that most teachers dislike. But when i started with scrum was not good for an unknow product then i switched to an waterfall by PMV kind, making:

1. Requirements
2. Making Goal use cases diagrams
3. Deleting non essential UC
4. Making an simple description of the use case, the data that should be used and the goal of user
5. Making paper wireframes of the interfaces
6. Create the mockups with all the graphical design (prettier and easy use is the main goal)
7. Creating the relationship entity diagram
8. Using my framework code generator to generate the B4X ORM trow micro-services
9. Staring to develop on B4X
10. Black box testing
11. User testing
12. And next starting with deleted UC or new requirements..

Is a good iterative paradigm but haves a lot of overhead, seems that i will able to release version every 2-3 months and some releases may be deleted, as they validate or not the live requirement; seems that a full version may fall on a year/two to really start to receive money.

I have an old ERP make on VB who took me 2 years of full waterfall, i can said that this kind of development is time consuming for a product that may or may not be subject to sell, as my crappy ERP.

To all guys who have commercial apps, which kind of paradigm use to analyze and figure user requirements? Do u do solo development? Do have your own?

PS: Excuses my English, is not my main language and i do the best.

 

[Mashiane]

Hi! Im alex i was working on 2 projects, FlaskRocket2 (b4X-python framework) and RadicalTicket an app to sell thickets, both using Scrum, the first one focused on comunity driver features took sense, the second developed on a team took too but after covid-2 we must drop it.

Now i'm started to work with a teacher (my test user) on an app to make easier remote async classes, without the pain of moodle or any LMS that most teachers dislike. But when i started with scrum was not good for an unknow product then i switched to an waterfall by PMV kind, making:

1. Requirements
2. Making Goal use cases diagrams
3. Deleting non essential UC
4. Making an simple description of the use case, the data that should be used and the goal of user
5. Making paper wireframes of the interfaces
6. Create the mockups with all the graphical design (prettier and easy use is the main goal)
7. Creating the relationship entity diagram
8. Using my framework code generator to generate the B4X ORM trow micro-services
9. Staring to develop on B4X
10. Black box testing
11. User testing
12. And next starting with deleted UC or new requirements..

Is a good iterative paradigm but haves a lot of overhead, seems that i will able to release version every 2-3 months and some releases may be deleted, as they validate or not the live requirement; seems that a full version may fall on a year/two to really start to receive money.

I have an old ERP make on VB who took me 2 years of full waterfall, i can said that this kind of development is time consuming for a product that may or may not be subject to sell, as my crappy ERP.

To all guys who have commercial apps, which kind of paradigm use to analyze and figure user requirements? Do u do solo development? Do have your own?

PS: Excuses my English, is not my main language and i do the best.

Interesting. You might try casecomplete. I ran across it some few years back. It's a commercial product and might do some of the things you talk about.

All the best.

 

[MicroDrie]

As you explained yourself, the waterfall method has a long lead time. So what I'm wondering is, when does the user come into the picture? Because you define the interfaces to build them later with B4X. Yes and then I think how likely is it that you will find all standard B4X solutions that matches all your designed User Interfaces?

My understanding of SCRUM roughly translates into putting the user more centrally. What it actually comes down to is that you listen to what he wants, start building something what you think that the user wants, and then show the user a first test version fairly quickly so that he or she gets an impression of what it will be and thus has the opportunity to influence the project end result. You can then quickly start with combine a number of standard B4X solutions into an intermediate version, after which you release the user. The user can then realize that he has set the good or less good requirements and adjust the realization goals with short implementation times. In fact, it means that it continuously reduces the difference between the user(s) expectation(s) and your realized program.

If it is not exactly clear or the user cannot formally describe what he wants, or you want to be able to respond quickly to the "progressive" insight, then I think SCRUM is a good creative approach (that's why you see SCRUM at Spotify, for example being used). If a program is to be used in a very formal environment, you run the risk that user influence may be at odds with the realization of the formal rules. So with SCRUM it is either a lot of quickly released releases with a small adjustment each time with a new option versus waiting a long time for a first release and then waiting a long time for a new modified version with a lot of changes (with the associated risk of a lot of bugs) where it is unclear to me whether the user ultimately has a program gets what he expected or because the promised interface ultimately turned out to be impossible or difficult to realize.

Whichever beautiful development environment you choose, there is always an unwritten rule: The user is always right in his or her assessment of the realized program (time).

 

[EnriqueGonzalez]

Please don't necrobump threads