Як оцінювати великі завдання

Існує безліч способів оцінити власні історії. Ми використовуємо власну методологію, щоб оцінити і опрацювати завдання перед тим, як писати код. Як ми до цього дійшли і чому наш підхід краще, ніж Planing Poker, читайте під катом.

image

Читати далі →

Області гнучкості

Переклад статті Evan Leybourn «Domain of Agility» виконаний Лілією Алексєєвої (Agile-євангеліст, Ощадбанк) з дозволу автора.

Agile не означає Scrum, а Agility не можна звести тільки до Agile.

Протягом кількох останніх місяців я намагався сформувати просту модель, яка допомогла б розкрити поняття Agility і взаємодія між складовими його елементами. Тепер я хочу представити вам результат цієї роботи — три різні форми гнучкості (Agility) — бізнесу, технічну та процесну. На мій погляд тільки наявність усіх трьох елементів дозволяє нам створити Agile-організацію.


Читати далі →

Ще одна версія налаштування TFS під командну роботу

Структура публікації
  • Трохи про те – чому так?
  • Схема роботи команд розробки під яку робиться налаштування
  • Налаштування XML-ек
  • Збереження XML-ек
  • Налаштування TFS через інтерфейс

Використовувалася TFS 2015, однак багато справедливо і для більш ранніх версій.

Читати далі →

Гнучка методологія розробки "Scrum"

Я продовжую роботу над дисертацією з проектного менеджменту. Сьогодні ми коротко розглянемо Scrum, розглянемо типові помилки, що призводять до проблем. Даний пост не претендує на повноту, він є оглядовим і адресується тим, хто ще не знайомий з методологією, або знайомий лише частково (наприклад, працює в модифікованому Scrum).

В даний час, Scrum є однією з найбільш популярних методологій розробки ПЗ. Згідно з визначенням, Scrum — це каркас розробки, з використанням якого люди можуть вирішувати з'являються проблеми, при цьому продуктивно і виробляючи продукти найвищої значущості (з точки зору клієнта — прим. Автора) [1].

Це говорить про те, що в Scrum неможливо знайти відповіді на всі запитання та вказівки до дії у всіх ситуаціях (наприклад, в офіційному описі Scrum лише зазначена необхідність оцінки часу, необхідного на виконання роботи, але не уточнюється вид оцінки. Тобто це може бути і planning poker й інший спосіб оцінки). Таким чином, саме найменування топіка не вірно :)

Коли говорять про методології Scrum, найчастіше мають на увазі гнучку методологію розробки ПО, побудовану на основі правил і практик Scrum, так що цілком може виявитися, що ваш Scrum крутіше мого Scrum, а також бути від нього так само далеким, як ВАЗ 7-ка від BMW 7-ї серії :)

Авторами Scrum заявлені наступні особливості:
-Легкий (англ. Lightweight)
-Зрозумілий, доступний
-Складний в освоєнні
(практично взаємовиключні параграфи)

image
Читати далі →

Бізнес vs програмна інженерія

Десь я чув, що в психотерапії існує наступна методика роботи з пацієнтом — пацієнту пропонують сісти і написати у вільній, «потокової» формі все, що накипіло, хвилює, розбурхує свідомість і, відбиваючись на підсвідомості, не дає спати ночами. Стосовно цього є хороше, ніжно пестить слух слово — фрирайтинг.

Отже, чому я вирішив написати — коли стикаєшся з повною зневагою до проектування як такого, зневагою до якості і дотримання хоч який-небудь методології розробки, завжди дивуєшся. Коли стикаєшся з цим раз за разом, про це вже хочеться написати.


Читати далі →

Сім разів відміряй, один раз відріж: як не заплутатися в метриках продукту, процесу і щастя команди

    Сьогодні моя мета — коротко розповісти про підходи data-informed продуктового менеджменту, який я сповідую і спробувати зацікавити вас у використанні його базових інструментів у ваших продуктах.
 
Короткий дисклеймер — я прийшла в продуктову розробку з проектного менеджменту в аутсорс. Для мене стало несподіванкою, що в той час як продуктовим метрик приділяється пильна увага, процесні та командні часто незаслужено йдуть на задній план.
 
Для себе я сформулювала, що вимірювання успішності продукту складається з трьох блоків:
 
 - Щастя користувачів;
 - Успішність (якісна і кількісна) ітерацій і релізів;
 - Щастя команди.
 
Читати далі →

Як керувати командою - історія одного успіху

    Привіт Хабр!
 
В процесі читання статті від Milfgard про те, як винувато людей, у мене стався когнітивний дисонанс. Мені чомусь завжди здавалося, що у нього в компанії панує дух свободи і творчості, ан ні, з шафи на нас знову визирає привид штрафів за запізнення.
Під катом вас чекає невелика подорож в протилежну точку зору.
 
Disclaimer: Стаття не претендує на повноту або істину в останній інстанції. Автор теж ні на що не претендує, а просто ділиться своїми спостереженнями, як є.
 
Читати далі →

Методологія Kanban

Добрий день!
 
Одним з моїх професійних інтересів, як координатора команди тестувальників, є методології розробки програмного забезпечення. В даний час все більшу популярність здобувають так звані Agile-методології, особливо Scrum і Kanban. На «разпіаренних» термінах грають недобросовісні «тренери», семінари та сертифікації («сертифікований Scrum-майстер», «сертифікований Product owner» і т.д.) ростуть як на дріжджах.
 
Читати далі →

Вивчення TDD через інтенсивну практику

       Примітка від перекладача : мій досвід знайомства з розробкою через тестування багато в чому схожий з тим, що описує автор (хоча і почався на кілька років пізніше). Я починав вивчати TDD самостійно, на роботі, виправляючи баги і створюючи нові модулі з нуля. Ефект від застосування TDD справив на мене настільки сильне враження, що породив бажання ділитися вмінням застосовувати цю техніку з іншими. Я також проводив Code Retreat-и всередині і поза своєї компанії. І я бачу ті ж проблеми у своїх тренінгах — дуже складно взяти і «впихнути» розуміння суті TDD в чужі голови.
 
Тому в даній статті я бачу свіжий погляд на проблему, який, можливо, дасть новий поштовх у вивченні TDD мені і моїм колегам. Думаю, вона стане в нагоді і іншим зацікавленим розробкою через тестування. Буду радий побачити Ваші коментарі.

 
Я використовую TDD як інструмент для вивчення і викладання основ модульного дизайну, але мушу зауважити, що ефективність навчання сильно залежить від дисципліни студентів. Я хочу робити свою справу все краще і краще, і тому постійно шукаю нові способи планувати критичні кроки 1 у викладанні TDD. Думаю, я знайшов МІКРОТЕХНІКА, яка допомагає в цій справі, і хочу негайно поділитися їй з вами.
 
 

TL; DR?

Багато прихильників TDD рекомендують підхід під назвою «інтенсивна практика», але я здогадуюсь, що у Вас не буде можливості витрачати багато робочого часу на практику. Я раджу людям «застосовувати TDD усвідомлено», але до цих пір не знав хорошого способу досить доступно пояснити зміст цих слів, що знижувало цінність мого ради. Ви можете почати застосовувати обидва підходи (інтенсивний і усвідомлений) одночасно, якщо почнете виправляти баги через тести. Навіть якщо Ви досі не вмієте проектувати софт на експертному рівні, то, принаймні, Ви вже можете вчитися як експерт. І виправлення багів через тести дасть Вам природну і не надто ризиковану можливість робити це. У Вас буде можливість практикуватися в TDD усередині і усвідомлено. Якщо у Вас є можливість виправляти баги на роботі поодинці, то Ви можете використовувати ці практики, не привертаючи зайвої уваги, яке зазвичай виникає при розмовах про «інтенсивної практиці». Просто говорите всім, що Ви виправляєте баги. Це всім сподобається.
 
Вам всього лише треба почати з написання тесту, який буде падати до тих пір, доки Ви не виправите баг. Якщо Вам потрібно більше подробиць, перш ніж почати, продовжуйте читання.
 
 
Читати далі →

Біг і розробка продуктів

  Що може бути спільного між бігом і розробкою програмного забезпечення? На перший погляд, нічого особливого. Спітнілий і стрункий бігун абсолютно несхожий на пухкого, зігнутого сколіозом програміста. Розробникам не аплодують стадіони і ніхто не видає їм прапор країни для почесного кола по офісу після випущеного релізу. І, тим не менше, між бігом і розробкою багато спільного.
 
Нещодавно я прочитав одну важку книгу — Surfaces and Essences . Дуглас Хофштадтера відтягнувся по повній і зробив так, що після перших 50 сторінок читати книгу просто не хочеться. Я буквально змушував себе освоювати пару десятків сторінок на тиждень, поки не дійшов до останньої третини книги — і там все стало дуже круто.
 
Книга про те, як люди мислять. А мислять вони аналогіями. Хофштадтера і Сандер досить переконливо доводять на мільйоні прикладів, як працюють аналогії і чого можна з їх допомогою досягти.
 
У мене народилася проста ідея — взяти одну область знань, проаналізувати її і застосувати до іншої галузі знань. Я вибрав біг.
 
Спойлер: Читайте далі, щоб дізнатися, чому
 
 
 
 
Читати далі →