Про менеджерах, розробниках і скрам

  Давно хотів систематизувати свій погляд на методології розробки ПЗ, на взаємодію менеджера і програміста (функціонального тімліда і тімліда розробки), але все не попадалася точка опори, відштовхнувшись від якої, можна поміркувати. І ось ця точка опори з'явилася. Колега прислав посилання на маніфест (RU ), який, як видається, легко опановує незміцнілими умами допомогою своєї категоричності та ненормативної лексики.
 
 
Должен признать, я понимаю, о чем так сумбурно говорят авторы.

Від методології SCRUM я відмовився, як тільки став тімліда розробки. Спочатку, коли проект тільки починався і я був розробником, щоденні скрам були в новинку і деяким чином допомагали в самоорганізації. Колишній тімліда проводив кожні два тижні ретроспективи, на яких ми обговорювали плюси і мінуси (все, як годиться). На скрам я навіть хвилювався, тому що озвучував конкретні терміни, в які планую вкластися з поточним завданням. І ще більше хвилювався, якщо не укладаюся.
 
У міру занурення в проект і розширення компетенцій, стало так: cмотри на годинник і думаєш: «Знову скрам, треба щось говорити». Було видно, що колеги думають аналогічно. На початку робочого дня, коли голова ще свіжа і чиста, як ранкова роса, мені найменше хотілося відволікатися на розмови і потім знову виникають в код. Ретроспективи зазвичай проводилися в другій половині дня і представляли собою вільне обговорення спільно пережитого, без прийняття яких-небудь рішень. Аналогічно: спочатку вони створювали видимість згуртування колективу, але потім стали для мене просто приводом розім'ятися і розслабити очі.
 
Ставши скрам-майстром, я все частіше думав: навіщо ця говорильня, коли витратити час можна більш продуктивно? Більше того — я дізнався про практиках, при яких ранковий scrum триває півгодини і супроводжується малюванням на фліпчарті.
 
 
Что там каждое утро можно рисовать? Для чего? Я не понимаю. Видимо, аналогичными вопросами задавались и авторы "манифеста".

Будучи пребагато вдячним колишньому тімліда за те, що він впровадив взагалі хоч якусь методологію розробки, яка свого часу дуже допомогла, я також вдячний йому за те, що можу зараз відчувати цю різницю — між наявністю методології та її відсутністю. Ставши тімліда розробки, я перестав проводити скрам і ретроспективи. Це не заважає мені контролювати весь процес розробки і в будь-який момент знати, чим займаються колеги, чи є у них проблеми.
 
Якщо говорити про взаємодію розробників з менеджерами, то ефективність, на мій погляд, досягається при сукупності деяких умов. Перше , як не банально, прийняття факту, що «ми — команда». Сприйняття розробником менеджера як замовника, так само як сприйняття менеджером розробника як виконавця вказівок — помилкові. Друге : «кожен займається своєю справою». Менеджер не повинен вміти програмувати, він повинен розуміти, що хоче бізнес, правильно розподіляти пріоритети і оцінювати терміни, так само як розробник не повинен спілкуватися з замовником. Третє — «мінімум слів, максимум справи». Без пояснень.
 
Так, я згоден з авторами в тому, що потрібно дотримувати баланс між виробництвом і адмініструванням. Але не менш важливо виявляти повагу до колег і контролювати емоції.
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.