PMI ACP intrebarea 9: Agile constraints

Which one of the following is NOT a constraint in applying Agile practices effectively?

(A)      Distributed teams with junior team members
(B)      Management and customer commitments to Agile
(C)      Assignment on multiple projects simultaneously
(D)      Limited customer availability

Intrebarea este simpla dar necesita putina atentie. Trebuie sa te gandesti la constrangeri in aplicarea tehnicilor Agile in mod eficient. Asta nu inseamna ca tehnicile nu pot fi aplicate. Raspunsul este (B) pentru ca, in regulile jocului, managementul si clientii nu comit ... 

Why (B): If management and customers are committed to agile, then agile will have better chances of success

Why NOT (A): Distributed teams have to face the challenge of communication and with junior team members, further lack sufficient experience to get over the communication hurdle
Why NOT (C): Working on too many things will not make one effective or efficient
Why NOT (D): Without customer support, agile practices will fail

PMI ACP intrebarea 8: agile failure

Some organizations practicing Agile sincerely have succeeded beyond their wildest dreams.  But for the others, initial successes don’t seem to be sustained in the long run.  All of the following reasons could explain this situation, EXCEPT:

(A)      Agile is initiated as a grass roots movement at the developer level.  Customers and management may not be on board
(B)      Agile is seen as a silver bullet, a quick and easy fix to complexity issues prevalent in software development, leading to failed expectations
(C)      Teams and organizations embrace change gracefully, since Agile believes that the only constant is ‘change’
(D)      Agile maybe misapplied in organizations with lack of team support or where the code base is too complex and unmaintainable

Ei zic asa:

Question is lamenting the fact that agile successes are NOT translated in the long run and there are three options which justify reasons to this failure.  Therefore, we need to identify one option which is a weaker argument to the "failure" cause.

Why (C): Argues for agile success and not failure
Why NOT (A): If customers and management are not supporting, agile will not work
Why NOT (B): Agile is not a "one size fits all" solution, and hence the failure
Why NOT (D): If not properly applied or lacks team support, agile will still fail!

Referinta: Becoming Agile: …in an imperfect world, Greg Smith & Ahmed Sidky, page xvii (foreword)

Intrebare capcana dupa parerea mea. Trebuie citita cartea.    

PMI ACP intrebarea 7: iteration cycle

You are mid-way through your third 2-week iteration.  Due to changing business conditions, the clients have started requesting changes many times a day.  This has thrown you and your team off balance.  What could you do to tame this confusion and still provide value to your clients?

(A)      Post all requests that come in for discussion until the next iteration planning
(B)      Accept those changes that are high priority and work it in along with your current iteration
(C)      Cancel the current iteration and work on a new iteration incorporating the requested changes
(D)      Reduce your 2-week iteration to a 2-day iteration

Why (D): By reducing the iteration cycle, priorities can be much more dynamically handled without losing out anything.  This is the best possible solution  

Why NOT (A): Clients can’t wait that long

Why NOT (B): “Along with current iteration” implies we are taking on more work than committed, which is not possible to accomplish

Why NOT (C): Drastic measure, which doesn’t account for priorities in the current iteration 

Reference: The Art of Agile Development - James Shore & Shane Warden, page 242  

Raspunsul pare evident? Nu chiar? Trebuie sa citesc in carte la pagina 242.

PMI ACP intrebarea 6: timeboxed release plan

In a time boxed release plan, the release date is defined in advance.  If so, what is NOT defined in this type of release plan?

(A)      Scope
(B)      Schedule
(C)      Cost
(D)      Quality 

Ei zic asa:

Why (A): In time boxing, specific features are not defined, since whatever can be accomplished in that time period will be done.  

Why NOT (B): Schedule is already defined in advance here

Why NOT (C), Why NOT (D): Whether we adopt time-boxed or scope-boxed releases, the cost and quality will not change. So this is not a parameter to consider

Referinta: The Art of Agile Development - James Shore & Shane Warden, page 212

Am gasit urmatorul link: http://www.jamesshore.com/Agile-Book/release_planning.html

Aici se spune clar: "There are two basic types of plans: scopeboxed plans and timeboxed plans". Prin definitie scopul nu este definit pentru timeboxed plan ... altfel s-ar fi numit scopeboxed plan!!!

PMI ACP intrebarea 5: Agile Manifesto

 Which of these Agile Manifesto elements need to be replaced?

(A)      Responding to change over following a plan

(B)      Customer collaboration over conflict management

(C)      Working software over comprehensive documentation

(D)      Individuals and interactions over processes and tools

Intrebarea se refera la Manifestul pentru dezvoltarea agila de software: http://agilemanifesto.org/

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Sfat: a se invata pe dinafara!

De observat ca intrebarea e formulata interesat: "need to be replaced".

Raspuns corect: (B)

PMI ACP intrebarea 4: XP practices

Si una simpla:

Agile methods consist of individual elements called practices.  Which of these is NOT a practice followed in XP?

(A)      Using version control for code management
(B)      Setting coding standards for the team to follow
(C)      Test first development in coding
(D)      Weekly code integration

E bine de citit http://en.wikipedia.org/wiki/Extreme_programming_practices.

"Version control" este parte din "Continuous integration", deci reaspunsul corect nu este (A). "Coding standard" este evident o practica XP, deci cade si (B). (C) este de fapt "Test driven development". Deci (D) este raspunsul cautat, raspuns evident deoarece integrarea codului are loc frecvent. Ma intreb oare ce s-ar intampla daca s-ar face saptamanal ... Prin urmare cuvantul "weekly" ne indica raspunsul.

PMI ACP intrebarea 3: Agile e metoda sau nu? E ARTA!

Si intrebarea 3:

Which of these is not a method?

(A)      Lean
(B)      Scrum
(C)      Agile
(D)      XP

Aici ajungem la alt post http://agile-romania.blogspot.de/2011/01/metoda-metodologie-sau-proces-cum.html unde filosofam daca Scrum este metoda, metodologie sau proces.

Ei zic asa:

Why (C): Is a philosophy or principles, not a method.
Why NOT (A), Why NOT (B), Why NOT (D): All these are methods or practices

Referinta: The Art of Agile Development - James Shore & Shane Warden, chap 2, page 9

Eu as putea adauga ca Agile este mai mult decat o filosofie, este ARTA! Nu degeaba intrebarea are o referinta catre cartea "The Art of Agile Development".

PMI ACP intrebarea 2: ban la ban trage

Si sa trecem mai departe la intrebarea 2:

A project was considered as challenged since it went over budget and beyond schedule when it was completed for a total cost of $3 million.  But the clients eventually claimed it to be a success.  Which one of the following reasons could potentially justify their claims?

(A)      The business was affected seriously since budget re-allocation had to be performed to fund the project to completion
(B)      The clients ended up spending an extra $2 million on this project
(C)      The project was estimated to save the client organization 20 man-years worth of man power
(D)      A review report after 12 months indicated that the client saved $11 million

O mica observatie:

challenged = contestat

challenging = provocator

Chiar simpatica intrebarea! Am rezolvat-o usor dupa logica urmatoare: avem in enunt bani, bani trebuie sa avem si in raspuns. Deci singurul raspuns corect nu poate fi decat D).

Ei zic asa:
Why (D): This is stating the fact, that has already occurred
Why NOT (A): Actually stating what the question says and is not adding anything to the client's claim to success
Why NOT (B): Indirectly stated in the question (over budget)
Why NOT (C): This looks promising, but a closer look makes it clear that this is only an “estimate”, with no guarantee of this happening

Dau si o referinta: The Art of Agile Development - James Shore & Shane Warden, chap 1, page 4

PMI ACP intrebarea 1: from project management perspective

Mi-a trecut prin cap sa incerc sa ma certific PMI ACP. Groaznic! Hai sa va demonstrez!

Pana una alta voi lua intrebari gasite pe Internet si voi incerca sa le comentez.

Traditional criteria for project success include meeting time, budget and specifications.  From a project management perspective, a project meeting these criteria may be considered a success, but may still fail in the end.  Which of these may be a good reason?

(A)      They fail to appeal to the intended users
(B)      They fail to add much value to the business
(C)      Project management success does not translate to business success
(D)      They fail to satisfy the customers needs

Asta e genul de intrebare pe care o iubesc. Ma uit la toate cele patru raspunsuri posibile si la prima vedere nu pot exclude nici macar unul. Daca se reciteste cu atentie intrebarea se observa un mic detaliu care iti poate scapa la prima vedere: "from a project management perspective".

Deci sa vedem cum argumenteaza ei raspunsurile:

(A)      They fail to appeal to the intended users 

Why NOT (A): Project success cannot be determined by individual likes / dislikes

Avem un proiect care esuaza din cauza ca nu prezinta interes pentru utilizatorii carora le-a fost destinat. Pentru mine e un bun motiv de insucces, deci raspuns posibil. Gresit! Nu trebuie sa gandim decat din punct de vedere al managementului de proiect. Poate ca proiectul a avut noroc, a facut in scaldatoare in faza de initiere, si, din intamplare, desi a fost un produs adresat manelistililor de 20-25 ani, a avut un succes imens in randul iubilorilor de opera, categoria de varsta 45-50 de ani.

(C)      Project management success does not translate to business success

Why NOT (C): The issue here is not about project management success

Bun! Proiectul nu are succes in business dar NU NE INTERESEAZA! Operatia a reusit, pacientul a murit! Ce daca pacientul a murit?

D)      They fail to satisfy the customers needs

Why NOT (D): It is possible that even though the customer is satisfied, the project may fail to add value to the business. 

Odata ce te-ai hotarat sa elimini raspunsul (C), e foarte usor de eliminat si raspunsul acesta.

(B)      They fail to add much value to the business Why (B): Without value, a project cannot be considered a success even if we consider that it came on schedule, within scope and budget 

Ati vazut unde era cheia? Cuvintele cheie sunt: add value to the business. Probabil ca pe undeva, printr-o carte ce nu poate fi citita decat de manageri, scrie clar: Traditional criteria for project success include meeting time, budget, specifications, value added to the business. Simplu, nu? Va rog insistent sa considerati ca a satisface nevoile clientilor nu are nici o legatura cu valoarea adaugata business-ului :D!