yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
When the agile movement re-cast the roles of the SDLC they did so with small projects as the baseline of their experience. A typical minimal SDLC method includes subject matter experts (those who execute the current workflow activities), a Project Manager, a Business Analyst, a Software Architect, UX specialists, Developers, DBAs, and Testers. A Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. The typical SDLC method responsibilities for activities, and the skills needed to get them done, went from 8 roles down to 3. For small projects that is great, but as the industry is learning the hard way, for bigger projects it just doesn't cut it.
The product owner role received a lot of responsibilities. This means they also are expected to have a lot of skills. By no fault of their own, this is not usually the case. Along with the lack of skills, I also usually see them floundering for the authority needed to be effective. I do not understand why there are so many people that believe changing a person's job title will somehow magically give them the skills needed to do the job.
The activities needed to build software successfully didn't change when agile was explicitly introduced to software development. Agile has implicitly always been a goal of software development projects. The activities required to successfully build software were just moved around, redefined to give them a new context, renamed, and in some cases ignored. If the team adopting Scrum is dysfunctional, they remain as dysfunctional as they were before attempting to use Scrum. Their skills and experience didn't change by moving the team to a new method of managing the project.
The product owner was usually a project manager, subject matter expert, or business analyst in their previous non-agile life. This book does a great job of covering what a product owner is, what they are expected to know, and what they are supposed to accomplish. I have listed the chapters below to give you an idea of what is covered.
Breakthrough! Being Agile — The Product Owner as a Change Agent Improved insight - The Point for Effective Communication --Leading through conflict — the product owner as a mediator --Leading Change and Winning Collaboration - A Mode! Owning the business case Unlocking usable user stores- solving business problems --Interview --Job Shadowing --Brainstorming and Alternatives Reliably working with the Team — Building Trust Focusing on interfaces: development-Business Understand the domain Thinking Acceptance Criteria - When is the Project Over? Scaling Agile — the product owner perspective Scaling Agile — the bigger picture of life cycles --Linear or Phased Approaches ----Waterfall ----V Model --Incremental Development Approach ----Staged Delivery --Iterative Approaches ----Spiral ----Rationale Unified Process --Agile Approaches ----Rapid Application Development ----DSDM ----Extreme Programming Perspective of the big picture- the basics of JIT, Lean Pull, Local Optimization in a MPRCS - Agile is not alone Free Glimpse: Secrets of powerful teams - Revealing ideas of NLP and the use of words
I really like the way the author puts Scrum into perspective. He says 'Waterfall is a methodology, the principal approach of which is linear. Agile is an approach and Scrum is a method. Comparing agile and waterfall is like comparing apples and oranges in more than one aspect.
I have said before that there are way too many books, and way too much information available on agile these days. I'll be the first to admit, that every time I see an agile book coming out the first thing I think is how could they possibly still be milking agile. I also must admit, that many of the new books coming out on agile are now reflective of experience, and not based entirely on theory. That was what you used to find in the agile library, all theory and no experience.
Architecture, lifecycle phases, documentation, and specialized skill sets for certain roles throughout the process have made their way back into the agile world on projects that are larger than a 3 to 5 person team can handle. Thank goodness any good agile book you pick up today will either include these topics as absolutely essential, or you can throw it in the garbage.
I really liked seeing the author introduce Waterfall, V Model, Staged Delivery, Spiral, Rationale Unified Process, Rapid Application Development, DSDM, and Extreme Programming.
I found the advice in this book to be dead on for helping the product owner understand their role and then helping them succeed at filling it. The book is less than 125 pages, so it is a short read, full of practical and relevant advice, with absolutely no filler.
I highly recommend this book to all those moving towards an agile approach, but especially those moving towards an agile method that includes the product owner role.
Thanks to the plethora of communication and messaging apps available to the average user, unified communications (UC) is becoming more important than ever before. UC is a set of products and services designed to give employees a uniform communications experience, integrating different ...
Cloud providers like AWS have proven to be a viable option for running mainframe application workloads. The most effective method to exploit the value of Unisys mainframe applications and data is a transformative migration to modern systems frameworks in AWS, reusing as much of the ori...
Having a well-rounded brand strategy helps you identify the marketing channels you must focus on, and defines every aspect of how your business is viewed by your customers.
Marketing and advertising is an integral component of every business. The US Small Business Administration reco...
When you work with React app, it normally needs some data from the server to store it for immediate use (e.g., show it on the page). If the app works with some complex relational database the work than may be a bit challenging. In this article I am going to describe the issues with org...
Technology integration is complex and an evergreen business challenge for IT teams. Enterprises setup manual & point to point connections to exchange data from business partners. However, data disruptions emerge when the business IT systems expand and prevents organizations from sharin...