Спритний для окремого розробника

Як хтось реалізує концепції Agile процесу як соло-розробник? Agile здається корисним для швидшого розробки програм, але також здається дуже орієнтованим на команду ...

• Роблячи тестові розробки
• Розвиваючись у малих спринтах
• Маючи багато контактів із замовником

Я пам’ятаю, як читав тезу про ковбойський розвиток, що є важливим Agile для розробників соло, але я не можу згадати, де я його знайшов.

Далі до відповіді від klez (всі хороші пропозиції) я пропоную наступне:

• Збереження пробілу товару Блокування
  продукту - це в основному список усіх елементів, які ви збираєтесь виконати на певному етапі цього продукту.
• Обслуговування спартангового спалаху та продукту. Спринтарське
  вигорання починається зі списку всіх завдань, які ви вирішили виконати в цьому спринті (підмножина відставання вашого продукту, яка має бути завершена протягом певного періоду часу - наприклад, 2 тижні) разом з кошторис необхідної роботи. Коли ви відмічаєте речі, ви відзначаєте їх як закінчені; тим самим зменшуючи (або спалюючи) решту роботи для цього спринту.
  Аналогічно, випал продукту відслідковує решту роботи на весь відставання продукту
• Прийняття понять відносної оцінки та швидкості
  Відносна оцінка - це техніка оцінки, яка використовує інші завдання (або розповіді) як керівництво. Наприклад, якщо ви знаєте, що завдання A легше, ніж завдання B і приблизно вдвічі складніше, ніж завдання C, ви переконаєтесь, що "точки" для завдання A були правильними щодо цих очікувань.
  Акцент робиться не на тому, щоб правильно відгадати обсяг необхідної роботи, а дотримуватись оцінок, що відповідають одна одній.
  Швидкість - це міра, скільки "балів" ви зробите в спринті. Якщо ваша відносна оцінка забезпечує узгодженість, ця швидкість може бути використана для оцінки завдань, які ви, ймовірно, зможете виконати в майбутніх спринтах. Зауважте, що ця швидкість повинна постійно переглядатися.

• Обмежте незавершену роботу (окрім тайм-боксу). Навіть якщо ви використовуєте ітераційний метод (на відміну від Канбана), скажімо, ваша швидкість становить 8 балів за ітерацію. Не починайте працювати відразу на всіх 8. Обмеження WIP будь-якою кількістю історій чи точок сюжету нормально.
• Провести автоматизовані тести прийняття для всіх ваших історій користувача. Автоматизуйте стільки, скільки зможете загалом.
• Помилка в тому, що історії користувачів занадто малі. Як правило, складіть співвідношення найбільшого до найменшого сюжету 3: 1 . Якщо ви недооцінюєте історію в Scrum, і вона виявляється занадто великою, багато розробників можуть переплутати її, щоб повернути її на шлях. Але вам не вистачає людей.
• Якщо в контексті команди звичайного розміру ви б вагалися, чи розділити шип на історію користувача - в сольному чи малій команді, зробіть шип без вагань. Це допомагає зберегти історії менше і передбачуванішими.
• Ретроспектива в цілому важлива в умовах гнучкості, тому Канбан (це був би Персональний Канбан) набирає тут додаткових балів, оскільки його ретроспективний процес більш керований даними. Важко грати в потрійні нікелі, коли у тебе недостатньо людей.

Ці речі стосуються, мабуть, як сольних, так і малих команд (2 або 3 розробники).

ДОДАТИ: Десь після того, як я написав цю відповідь, я знайшов цю конференцію і був дуже вражений: Особистий Канбан: Оптимізація індивідуального кодера

• Або працювати в чітко визначених спринтах, або свідомо обирати підхід Канбана. Не випадково опинившись в Канбані
• Помилки перше, функції друге.
• Все ж залишайте фокус на вартості та особливостях. (YAGNI за золото)
• Ретроспектива так само цінна. І так само важливо, вносити зміни в процесах невеликими шматками. Не вирішуйте, що сьогодні ви почнете запускати TDD, Mock та IoC одним знімком, якщо у вас справді немає зовнішніх функцій для доставки банкоматів. Приносьте по одному.

Зрештою, я по-справжньому визначаю Agile як "робити те, що має сенс для вашої команди та замовника, і не дотримуватися старої практики, тому що вони траплялися так, як працювали в минулому".

Agile працює так само добре, як для людей, як і для команд. Йдеться про пошук процесу, який працює для вас, і дозволяє вам адаптуватися до мінливих обставин, як тільки ваш проект вже розпочався. Йдеться також про регулярну доставку цінності для свого клієнта, незалежно від того, чи програмне забезпечення насправді "закінчено".

Агільні процеси є дуже ітераційними. Робота виконується в коротких TimeBoxes / спринтах / циклах / ітерацій. Деякі дизайнерські роботи можуть знадобитися попереду, але їх можна відремонтувати, коли ви дізнаєтесь більше про те, що саме вам потрібно зробити. Тестування блоків є основою майже всіх методів розробки Agile, що дає вам вказівку на те, чи працює ваше програмне забезпечення, і якщо доповнення / зміни до Вашого програмного забезпечення порушать існуючу базу коду.

Якщо ви дотримуєтесь BDD / TDD, дозвольте своїм вимогам змінюватися вітром, і ви можете відповідно налаштувати свої пріоритети функції, якщо ви будуєте всю свою систему і запускаєте всі тести часто, і якщо ви доставляєте робочий код в кінці кожного спринту , ти вже Agile.

Ого. Я б спробував утримати друга на гачку, якого я міг би зателефонувати, коли потрапив у біду, - і поговорити через проблему кодування. Ви знаєте, що я маю на увазі ... просто акт пояснення проблеми вголос приносить рішення моїй думці 90% часу.