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.
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just ...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO Silicon Valley 2019 will cover all of these tools, with the most comprehensive program and with 222 rockstar speakers throughout our industry presenting 22 Keynotes and General Sessions, 250 Breakout Sessions along 10 Tracks, as well as our ...
Big Switch's mission is to disrupt the status quo of networking with order of magnitude improvements in network e ciency, intelligence and agility by delivering Next-Generation Data Center Networking. We enable data center transformation and accelerate business velocity by delive...
Your job is mostly boring. Many of the IT operations tasks you perform on a day-to-day basis are repetitive and dull. Utilizing automation can improve your work life, automating away the drudgery and embracing the passion for technology that got you started in the first place. In...
Technological progress can be expressed as layers of abstraction - higher layers are built on top of lower layers treating them as abstract black boxes with known interfaces. A serverless approach represents an inflection point that entirely separates the runtime layer from the u...