Archive

Posts Tagged ‘Agile’

What customer wants. To be close or to be well served….

November 24, 2011 3 comments

The main factor of a success of every business is ability to serve customer quickly and efficiently.
Agile methodology, which is very popular now in IT project management, says that the customer must be as close as possible to the team. That helps him to be focused on the project, support team as a subject matter expert.

However, try to imagine yourself as a customer.

  • Would you like to be bothered with a bunch of questions everyday instead of spending time with sponsors, prospect investors or working on some other important business deals? NO
  • Wouldn’t you like just to get a frequent status with information about the progress, short presentation what was done, risks and how a vendor is going to deal with them? And to interfere only if you feel it’s needed.I would like to be that customer.

I usually outsource a work if I’m not a professional in a field or I just don’t have enough time or a desire to accomplish it.
In any case I don’t want to spend much time with a vendor and I usually expect getting a wise pieces of advice.

So why do they say that it’s important to keep the customer as close as possible? Because it’s less risky for the vendor. The vendor is not required to think a lot about the a work they do, it’s not required to do a deep analysis, it’s just less pressure on the vendor. This is good. But is it really good for the customer?

No.

He must spend his time for explaining, researching, making decisions.

You as a good vendor must research a field, provide pieces of advice, make decisions which are the best for the customer’s needs, send a status to let the customer know how are you doing.

Based on my own experience, I know, that if you can save customers time on making everyday or even more important decisions, you will achieve a success in your business.

Let them feel relief because you are close and you are a professional. Don’t do this in opposite way :).

Advertisements

Шлях до Agile. Спрінти та релізи.

April 21, 2011 Leave a comment

Ми працюємо над проектом, де у замовника релізи 3-4 рази в рік. Зазвичай досить важко обговорити ввесь функціонал на пів року вперед. Тому потрібен коротший часовий проміжок для ефективної роботи. Так ми і зробили – почали робити 2 ітерації на реліз. Кожна 1.5 – 2 місяці. Розробили список із 20-25 фіч, проставили пріоритети і вперед.

Але згодом я зрозумів, що команді достатньо важко сконцентруватися за закінченні високо пріоритетних фіч. Зазвичай, коли над фічею працює двоє людей (н.д. клієнт – сервер), і одна людина вже закінчила, а інша ще не почала, то фіча так і лишається незавершеною.
Побачивши це, було вирішено наступне – ітерацію розділити на два спрінти. Це були внутрішні спрінти, без доставки до замовника. Кожен – тривалістю 3 тижні.  Це дозволило команді спочатку сконцентруватися на фічах, які мали найвищий пріоритет. А потім в наступному спринті закінчити інші, менш пріоритетні фічі.

Так і сталося. Практично всі критичні фічі були завершені та відтестовані в першому спрінті . А ті, які не були завершені, були перенесені на наступний.

Зараз ми закінчуємо другий спрінт – все йде по плану. Скоро здаємо ітерацію замовнику. Вперше все спокійно, без авралу…….

Здається ми знайшли золоту середину……

Шлях до Agile. Daily scrum

December 22, 2010 Leave a comment

Уже декілька років я керую розробкою програмного забезпечення. А почалось все з того, що я прийшов  на роботу не вчасно.  Тоді і почув – ти будеш ПМ. Ну думаю, а чому б не спробувати. Все таки з посади ПМ набагато легше воювати за якість, аніж з посади інженера з перевірки/забезпезпечення якості.

А далі розкажу про те як я (разом з командою) вводив практики які належать до когорти «Гнучких».

Так от:

Перше, що я вирішив змінити то була система обліку таксів, багів та вимог. Особливо вимог.  До цього системою обліку вимог завжди був  документ MSWord, що, як ведеться, залишався у версії Draft  ну або максимум 1.0.

Зупинився я на Team Foundation Server, як систему для менеджменту проектних атефактів.  Причини:

  • То був новий продукт на ринку (TFS2005)
  • Були знайомі, що уже мали досвід роботи з ним

І зажили ми «харашо»…….

Нєа…..

Все є: вимоги, таски, баги, лінки між ними, в все одно  люди працюють розсинхронізовано, ніхно не знає чим займається його сусід, тай і не цікаво їх чим сусід займається. Час від часу проводили мітинги, але там в основному говорять двоє: оптиміст і критик 🙂 , іншим пофіг – сидиш собі на кріслі і нікого не рухаєш, махнув головою, що все ясно і довольний.

Це була для мене серйозна проблема: не можу зацікавити людей, не можу               донести інформацію, команда «неправильна»…….

Як виявилося людям цікаво, коли говорять вони (а особливо коли хваляться) і коли їх слухають. Тільки є одни нюанс – потрібно персонально спитати. (Ваня, а що ти вчора зробив? Чи є якісь проблеми? Нема 🙂  ?)

Як виявилося є можливість робити швидкі статус «мітинги» а-ля «планьорка» кожен день і обговорювати на них два тривіальні питання:

1.       Що ти зробив вчора  (наголос на доконаності дії)

2.       Що ти зробиш сьогодні (наголос на доконаності дії)

Кожен член команди коротко відповідає на ці два прості питання.  Ну і мітинг проводиться стоячи  – щоб не заснути :). В світі Agile а точніше Scrum – це daily scrum.

Що це дає:

  • Таким чином людина націлюється на результат.
  • Інші знають чим займається товариш.
  • У ПМа є загальне уявлення де проект буде завтра.

Правда ми додали ще одне питання:

3.       Які є проблеми?

Таким чином команда може допомогти людині вирішити проблему одразу.  Це дуже доречно для нових людей, які бояться  підійти до «бородатого старожила команди» з дурним запитанням.

Отак з пробами та помилками ми отримали Daily Scrum.  (Scrum  я тут вжив бо це зараз модно 🙂 )

Далі буде……